Attribuer un rôle IAM à un compte de service Kubernetes - Amazon EKS

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.

Attribuer un rôle IAM à un compte de service Kubernetes

Cette rubrique explique comment configurer un compte de service Kubernetes pour qu'il assume un rôle de gestion des AWS identités et des accès (IAM) avec EKS Pod Identity. Tous les pods configurés pour utiliser le compte de service peuvent ensuite accéder à tout AWS service auquel le rôle est autorisé à accéder.

Pour créer une association EKS Pod Identity, il n'y a qu'une seule étape : vous créez l'association dans EKS via la AWS Management Console AWS CLI AWS CloudFormation et d'autres outils. AWS SDKs Il n'existe aucune donnée ou métadonnée concernant les associations au sein du cluster dans les objets Kubernetes et vous n'ajoutez aucune annotation aux comptes de service.

  • Un cluster existant. Si vous n'en avez pas, vous pouvez en créer un en suivant l'un des guides présentés dansMise en route avec Amazon EKS.

  • Le principal IAM qui crée l’association doit avoir le iam:PassRole.

  • La dernière version de la AWS CLI installée et configurée sur votre appareil ou AWS CloudShell. Vous pouvez vérifier votre version actuelle avec aws --version | cut -d / -f2 | cut -d ' ' -f1. Les gestionnaires de packages tels que yum Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. apt-get Pour installer la dernière version, consultez la section Installation et configuration rapide avec aws configure dans le Guide de l'utilisateur de l'interface de ligne de AWS commande. La version de la AWS CLI installée dans le AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section Installation de la AWS CLI dans votre répertoire de base dans le guide de AWS CloudShell l'utilisateur.

  • L'outil de ligne de commande kubectl est installé sur votre appareil ou AWS CloudShell. La version peut être identique ou supérieure à une version mineure antérieure ou ultérieure à la version Kubernetes de votre cluster. Par exemple, si la version de votre cluster est 1.29, vous pouvez utiliser la version kubectl 1.28, 1.29 ou 1.30. Pour installer ou mettre à niveau kubectl, veuillez consulter Configurez kubectl et eksctl.

  • Un fichier existant kubectl config qui contient la configuration de votre cluster. Pour créer un fichier kubectl config, consultez Connect kubectl à un cluster EKS en créant un fichier kubeconfig.

Création d'une association Pod Identity (AWS console)

  1. Ouvrez la console Amazon EKS.

  2. Dans le panneau de navigation de gauche, sélectionnez Clusters, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire l’agent d’identité du pod EKS.

  3. Choisissez l’onglet Access.

  4. Dans Associations d’identité du pod, sélectionnez Créer.

  5. Pour Rôle IAM, sélectionnez le rôle IAM avec les autorisations dont a besoin la charge de travail.

    Note

    La liste ne contient que les rôles qui ont la politique d’approbation suivante qui permet à l’identité du pod EKS de les utiliser.

    { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowEksAuthToAssumeRoleForPodIdentity", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] }

    sts:AssumeRole— EKS Pod AssumeRole Identity assume le rôle IAM avant de transmettre les informations d'identification temporaires à vos pods.

    sts:TagSession— EKS Pod Identity est utilisé TagSession pour inclure des balises de session dans les demandes adressées à AWS STS.

    Vous pouvez utiliser ces balises dans les clés de condition de la politique de confiance pour limiter les comptes de service, les espaces de noms et les clusters autorisés à utiliser ce rôle.

    Pour obtenir la liste des clés de condition Amazon EKS, consultez la rubrique Conditions définies par Amazon Elastic Kubernetes Service de la Référence de l'autorisation de service. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez la rubrique Actions définies par Amazon Elastic Kubernetes Service.

  6. Pour l'espace de noms Kubernetes, sélectionnez l'espace de noms Kubernetes qui contient le compte de service et la charge de travail. Vous pouvez éventuellement spécifier un espace de noms par un nom qui n'existe pas dans le cluster.

  7. Pour le compte de service Kubernetes, sélectionnez le compte de service Kubernetes à utiliser. Le manifeste de votre charge de travail Kubernetes doit spécifier ce compte de service. Vous pouvez éventuellement spécifier un compte de service par un nom qui n'existe pas dans le cluster.

  8. (Facultatif) Pour Balises, choisissez Ajouter une balise pour ajouter des métadonnées dans une paire clé et valeur. Ces balises sont appliquées à l’association et peuvent être utilisées dans les politiques IAM.

    Vous pouvez répéter cette étape pour ajouter plusieurs balises.

  9. Sélectionnez Create (Créer).

Création d'une association Pod Identity (AWS CLI)

  1. Si vous souhaitez associer une politique IAM existante à votre rôle IAM, passez à l'étape suivante.

    Créez une politique IAM. Vous pouvez créer votre propre politique ou copier une politique AWS gérée qui accorde déjà certaines des autorisations dont vous avez besoin et la personnaliser en fonction de vos besoins spécifiques. Pour plus d’informations, consultez Création de politiques IAM dans le Guide de l’utilisateur IAM.

    1. Créez un fichier qui inclut les autorisations pour les AWS services auxquels vous souhaitez que vos pods accèdent. Pour obtenir la liste de toutes les actions pour tous les AWS services, consultez la référence d'autorisation des services.

      Vous pouvez exécuter la commande suivante pour créer un exemple de fichier de politique autorisant l'accès en lecture seule à un compartiment Amazon S3. Vous pouvez éventuellement stocker des informations de configuration ou un script de démarrage dans ce compartiment, et les conteneurs de votre Pod peuvent lire le fichier depuis le compartiment et le charger dans votre application. Si vous souhaitez créer cet exemple de politique, copiez le contenu suivant sur votre appareil. my-pod-secrets-bucketRemplacez-le par le nom de votre compartiment et exécutez la commande.

      cat >my-policy.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws: s3:::my-pod-secrets-bucket" } ] } EOF
    2. Créez la politique IAM.

      aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
  2. Créez un rôle IAM et associez-le à un compte de service Kubernetes.

    1. Si vous possédez déjà un compte de service Kubernetes et que vous souhaitez assumer un rôle IAM, vous pouvez ignorer cette étape.

      Créez un compte de service Kubernetes. Copiez les contenus suivants sur votre appareil. my-service-accountRemplacez-le par le nom de votre choix et default par un autre espace de noms, si nécessaire. Si vous modifiezdefault, l'espace de noms doit déjà exister.

      cat >my-service-account.yaml <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: my-service-account namespace: default EOF kubectl apply -f my-service-account.yaml

      Exécutez la commande suivante.

      kubectl apply -f my-service-account.yaml
    2. Exécutez la commande suivante pour créer un fichier de stratégie d'approbation pour le rôle IAM.

      cat >trust-relationship.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowEksAuthToAssumeRoleForPodIdentity", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } EOF
    3. Créez le rôle. Remplacez my-role avec un nom pour votre rôle IAM, et my-role-description avec une description de votre rôle.

      aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
    4. Liez une politique IAM à votre rôle. Remplacez my-role par le nom de votre rôle IAM et my-policy par le nom d'une politique existante que vous avez créée.

      aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws: iam::111122223333:policy/my-policy
      Note

      Contrairement aux rôles IAM pour les comptes de service, EKS Pod Identity n'utilise pas d'annotation sur le compte de service.

    5. Exécutez la commande suivante pour créer l’association. my-clusterRemplacez-le par le nom du cluster, remplacez-le my-service-account par le nom de votre choix et default par un autre espace de noms, si nécessaire.

      aws eks create-pod-identity-association --cluster-name my-cluster --role-arn arn:aws: iam::111122223333:role/my-role --namespace default --service-account my-service-account

      L'exemple qui suit illustre un résultat.

      { "association": { "clusterName": "my-cluster", "namespace": "default", "serviceAccount": "my-service-account", "roleArn": "arn:aws: iam::111122223333:role/my-role", "associationArn": "arn:aws::111122223333:podidentityassociation/my-cluster/a-abcdefghijklmnop1", "associationId": "a-abcdefghijklmnop1", "tags": {}, "createdAt": 1700862734.922, "modifiedAt": 1700862734.922 } }
      Note

      Vous pouvez spécifier un espace de noms et un compte de service par un nom qui n'existe pas dans le cluster. Vous devez créer l’espace de noms, le compte de service et la charge de travail qui utilise le compte de service pour que l’association de l’identité du pod EKS fonctionne.

Confirmer la configuration

  1. Vérifiez que la politique de confiance du rôle IAM est correctement configurée.

    aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument

    L'exemple qui suit illustre un résultat.

    { "Version": "2012-10-17", "Statement": [ { "Sid": "Allow EKS Auth service to assume this role for Pod Identities", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] }
  2. Vérifiez que la stratégie que vous avez associée à votre rôle lors d'une étape précédente est associée au rôle.

    aws iam list-attached-role-policies --role-name my-role --query AttachedPolicies[].PolicyArn --output text

    L'exemple qui suit illustre un résultat.

    arn:aws: iam::111122223333:policy/my-policy
  3. Définissez une variable pour stocker l'Amazon Resource Name (ARN) de la stratégie que vous souhaitez utiliser. my-policyRemplacez-le par le nom de la politique pour laquelle vous souhaitez confirmer les autorisations.

    export policy_arn=arn:aws: iam::111122223333:policy/my-policy
  4. Affichez la version par défaut de la stratégie.

    aws iam get-policy --policy-arn $policy_arn

    L'exemple qui suit illustre un résultat.

    { "Policy": { "PolicyName": "my-policy", "PolicyId": "EXAMPLEBIOWGLDEXAMPLE", "Arn": "arn:aws: iam::111122223333:policy/my-policy", "Path": "/", "DefaultVersionId": "v1", [...] } }
  5. Consultez le contenu de la politique pour vous assurer qu'elle inclut toutes les autorisations dont votre Pod a besoin. Si nécessaire, remplacez 1 la commande suivante par la version renvoyée dans la sortie précédente.

    aws iam get-policy-version --policy-arn $policy_arn --version-id v1

    L'exemple qui suit illustre un résultat.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws: s3:::my-pod-secrets-bucket" } ] }

    Si vous avez créé l'exemple de stratégie lors d'une étape précédente, le résultat est le même. Si vous avez créé une politique différente, le example contenu est différent.

Étapes suivantes

Configurer les pods pour accéder aux AWS services avec des comptes de service