Accordez aux Pods l'accès aux ressources {aws} en fonction de balises

Le contrôle d'accès basé sur les attributs (ABAC) accorde des droits aux utilisateurs par le biais de politiques qui combinent les attributs entre eux. EKS Pod Identity attache des balises aux informations d'identification temporaires de chaque pod avec des attributs tels que le nom du cluster, l'espace de noms et le nom du compte de service. Ces balises de session de rôle permettent aux administrateurs de créer un rôle unique qui peut fonctionner avec tous les comptes de service en autorisant l'accès aux AWS ressources en fonction des balises correspondantes. En ajoutant la prise en charge des balises de session de rôle, les clients peuvent appliquer des frontières de sécurité plus strictes entre les clusters et les charges de travail au sein des clusters, tout en réutilisant les mêmes rôles IAM et politiques IAM.

Par exemple, la politique suivante autorise l’action s3:GetObject si l’objet est étiqueté avec le nom du cluster EKS.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectTagging"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}"
                }
            }
        }
    ]
}

Liste des balises de session ajoutées par l’identité du pod EKS

La liste suivante contient toutes les clés des balises qui sont ajoutées à la demande AssumeRole effectuée par Amazon EKS. Pour utiliser ces balises dans les politiques, utilisez ${aws:PrincipalTag/ suivi de la clé, par exemple ${aws:PrincipalTag/kubernetes-namespace}.

Balises inter-comptes

Toutes les balises de session ajoutées par l’identité du pod EKS sont transitives ; les clés et les valeurs des balises sont transmises à toutes les actions AssumeRole que vos charges de travail utilisent pour changer de rôle dans un autre compte. Vous pouvez utiliser ces balises dans les politiques d’autres comptes pour limiter l’accès dans des scénarios intercomptes. Pour plus d’informations, consultez Chaînage des rôles avec des balises de session dans le Guide de l’utilisateur IAM.

Balises personnalisées

EKS Pod Identity ne peut pas ajouter de balises personnalisées supplémentaires à l'AssumeRoleaction qu'il exécute. Cependant, les balises que vous appliquez au rôle IAM sont toujours disponibles sous le même format : ${aws:PrincipalTag/ suivi de la clé, par exemple ${aws:PrincipalTag/MyCustomTag}.