Accorder aux pods l’accès aux ressources AWS en fonction des balises - Amazon EKS

Aidez à améliorer cette page

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

Accorder aux pods l’accès aux ressources AWS en fonction des balises

Le contrôle d’accès par attributs (ABAC) accorde des droits aux utilisateurs grâce à des politiques qui combinent des attributs. L’identité du pod EKS associe 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 pouvant fonctionner sur tous les comptes de service en autorisant l’accès aux ressources AWS en fonction des balises correspondantes. En ajoutant la prise en charge des balises de session de rôle, vous pouvez renforcer la sécurité entre les clusters et les charges de travail au sein des clusters, tout en réutilisant les mêmes rôles et politiques IAM.

Exemple de politique avec balises

Vous trouverez ci-dessous un exemple de politique IAM qui accorde les autorisations s3:GetObject lorsque l’objet correspondant est balisé 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

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

Activer les balises de session

Les balises de session sont automatiquement activées avec l’identité du pod EKS. Aucune action n’est requise de votre part. Par défaut, l’identité du pod EKS 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}.

  • eks-cluster-arn

  • eks-cluster-name

  • kubernetes-namespace

  • kubernetes-service-account

  • kubernetes-pod-name

  • kubernetes-pod-uid

Désactiver les balises de session

AWS compresse les stratégies de session en ligne, les ARN de stratégies gérées et les balises de session dans un format binaire, qui possède une limite distincte. Si vous recevez une erreur PackedPolicyTooLarge 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 l’identité du pod EKS. Pour désactiver ces balises de session, veuillez suivre les étapes suivantes :

  1. Ouvrez la console Amazon EKS.

  2. Dans le panneau de navigation gauche, sélectionnez Clusters, puis sélectionnez le nom du cluster que vous voulez modifier.

  3. Choisissez l'onglet Access.

  4. Dans Associations d’identité du pod, choisissez l’ID d’association que vous souhaitez modifier dans ID d’association, puis choisissez Modifier.

  5. Sous Balises de session, choisissez Désactiver les balises de session.

  6. Sélectionnez Enregistrer les modifications.

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

L’identité du pod EKS ne peut pas ajouter de balises personnalisées supplémentaires à l’action AssumeRole qu’il effectue. Cependant, les balises que vous appliquez au rôle ${aws:PrincipalTag/ IAM sont toujours disponibles dans le même format : ${aws:PrincipalTag/MyCustomTag} suivi de la clé, par exemple .

Note

Les balises ajoutées à la session via la demande sts:AssumeRole sont prioritaires en cas de conflit. Par exemple, supposons que :

  • Amazon EKS ajoute une clé eks-cluster-name et une valeur my-cluster à la session lorsque EKS assume le rôle client et

  • Vous ajoutez une balise eks-cluster-name au rôle IAM avec la valeur my-own-cluster.

Dans ce cas, la première a priorité et la valeur de la balise eks-cluster-name sera my-cluster.