Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Accordez aux Pods l'accès aux AWS ressources en fonction des 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, vous pouvez appliquer des limites 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 les mêmes politiques IAM.

Exemple de politique avec balises

Vous trouverez ci-dessous un exemple de politique IAM qui accorde des s3:GetObject autorisations lorsque l'objet correspondant 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}"
                }
            }
        }
    ]
}

Activer ou désactiver les balises de session

EKS Pod Identity ajoute un ensemble prédéfini de balises de session lorsqu'il assume le rôle. Ces balises de session permettent aux administrateurs de créer un rôle unique qui peut fonctionner avec toutes les ressources en autorisant l'accès aux AWS ressources en fonction des balises correspondantes.

Activer les balises de session

Les balises de session sont automatiquement activées avec EKS Pod Identity. Aucune action n'est requise de votre part. Par défaut, EKS Pod Identity associe un ensemble de balises prédéfinies à votre session. Pour référencer ces balises dans les politiques, utilisez la syntaxe ${aws:PrincipalTag/ suivie de la clé de balise. Par exemple, ${aws:PrincipalTag/kubernetes-namespace}.

Désactiver les balises de session

AWS compresse les politiques de session intégrées, les politiques ARNs gérées et les balises de session dans un format binaire compressé doté d'une limite distincte. Si vous recevez un PackedPolicyTooLarge message d'erreur indiquant que le format binaire compressé a dépassé la limite de taille, vous pouvez essayer de réduire la taille en désactivant les balises de session ajoutées par EKS Pod Identity. Pour désactiver ces balises de session, procédez comme suit :

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. Toutefois, les balises que vous appliquez au rôle IAM sont toujours disponibles dans le même format : ${aws:PrincipalTag/ suivies de la clé, par exemple${aws:PrincipalTag/MyCustomTag}.