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. # Associations d'identité EKS Pod AWS EKS a introduit un nouveau mécanisme amélioré appelé Pod Identity Association permettant aux administrateurs de clusters de configurer les applications Kubernetes afin de recevoir les autorisations IAM requises pour se connecter aux services AWS en dehors du cluster. Pod Identity Association tire parti de l'IRSA, mais le rend configurable directement via l'API EKS, éliminant ainsi le besoin d'utiliser l'API IAM. Par conséquent, les rôles IAM n'ont plus besoin de faire référence à un [fournisseur OIDC](iamserviceaccounts.md#iam-how-works) et ne seront donc plus liés à un seul cluster. Cela signifie que les rôles IAM peuvent désormais être utilisés sur plusieurs clusters EKS sans qu'il soit nécessaire de mettre à jour la politique de confiance des rôles à chaque fois qu'un nouveau cluster est créé. Cela élimine à son tour le besoin de duplication des rôles et simplifie complètement le processus d'automatisation de l'IRSA. ## Conditions préalables Dans les coulisses, la mise en œuvre des associations d'identité des pods consiste à exécuter un agent en tant que daemonset sur les nœuds de travail. Pour exécuter l'agent prérequis sur le cluster, EKS fournit un nouveau module complémentaire appelé EKS Pod Identity Agent. Par conséquent, la création d'associations d'identité de pod (en général et avec`eksctl`) nécessite que l'`eks-pod-identity-agent`addon soit préinstallé sur le cluster. Cet addon peut être créé de la même manière que n'importe quel autre addon compatible. `eksctl` ``` eksctl create addon --cluster my-cluster --name eks-pod-identity-agent ``` En outre, si vous utilisez un rôle IAM préexistant lors de la création d'une association d'identité de pod, vous devez configurer le rôle pour qu'il fasse confiance au nouveau principal de service EKS ()`pods.eks.amazonaws.com`. Vous trouverez ci-dessous un exemple de politique de confiance IAM : ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` Si, au contraire, vous ne fournissez pas l'ARN d'un rôle existant à la commande create, `eksctl` vous en créerez un en arrière-plan et configurerez la politique de confiance ci-dessus. ## Création d'associations d'identité de pods Pour manipuler les associations d'identité des pods, `eksctl` a ajouté un nouveau champ sous`iam.podIdentityAssociations`, par ex. ``` iam: podIdentityAssociations: - namespace: #required serviceAccountName: #required createServiceAccount: true #optional, default is false roleARN: #required if none of permissionPolicyARNs, permissionPolicy and wellKnownPolicies is specified. Also, cannot be used together with any of the three other referenced fields. roleName: #optional, generated automatically if not provided, ignored if roleARN is provided permissionPolicy: {} #optional permissionPolicyARNs: [] #optional wellKnownPolicies: {} #optional permissionsBoundaryARN: #optional tags: {} #optional ``` Pour un exemple complet, reportez-vous à [pod-identity-associations.yaml.](https://github.com/eksctl-io/eksctl/blob/main/examples/39-pod-identity-association.yaml) **Note** Hormis celui `permissionPolicy` qui est utilisé comme document de politique intégré, tous les autres champs ont un équivalent d'indicateur CLI. La création d'associations d'identité de pods peut être réalisée de la manière suivante. Lors de la création du cluster, en spécifiant les associations d'identité de pod souhaitées dans le fichier de configuration et en exécutant : ``` eksctl create cluster -f config.yaml ``` Après la création du cluster, en utilisant soit un fichier de configuration, par exemple ``` eksctl create podidentityassociation -f config.yaml ``` OU en utilisant des drapeaux CLI, par exemple ``` eksctl create podidentityassociation \ --cluster my-cluster \ --namespace default \ --service-account-name s3-reader \ --permission-policy-arns="arn:aws:iam::111122223333:policy/permission-policy-1, arn:aws:iam::111122223333:policy/permission-policy-2" \ --well-known-policies="autoScaler,externalDNS" \ --permissions-boundary-arn arn:aws:iam::111122223333:policy/permissions-boundary ``` **Note** Un seul rôle IAM peut être associé à un compte de service à la fois. Par conséquent, toute tentative de création d'une deuxième association d'identité de pod pour le même compte de service entraînera une erreur. ## Récupération des associations d'identité des pods Pour récupérer toutes les associations d'identité des pods pour un cluster donné, exécutez l'une des commandes suivantes : ``` eksctl get podidentityassociation -f config.yaml ``` OU ``` eksctl get podidentityassociation --cluster my-cluster ``` De plus, pour récupérer uniquement les associations d'identité des pods dans un espace de noms donné, utilisez le `--namespace` drapeau, par exemple ``` eksctl get podidentityassociation --cluster my-cluster --namespace default ``` Enfin, pour récupérer une seule association, correspondant à un certain compte de service K8s, incluez également la `--service-account-name` commande ci-dessus, c'est-à-dire ``` eksctl get podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader ``` ## Mettre à jour les associations d'identité des pods Pour mettre à jour le rôle IAM d'une ou de plusieurs associations d'identité de pod, transmettez la nouvelle `roleARN(s)` au fichier de configuration, par exemple ``` iam: podIdentityAssociations: - namespace: default serviceAccountName: s3-reader roleARN: new-role-arn-1 - namespace: dev serviceAccountName: app-cache-access roleARN: new-role-arn-2 ``` et lancez : ``` eksctl update podidentityassociation -f config.yaml ``` OU (pour mettre à jour une seule association) transmettez les nouveaux indicateurs `--role-arn` via la CLI : ``` eksctl update podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader --role-arn new-role-arn ``` ## Supprimer les associations d'identité des pods Pour supprimer une ou plusieurs associations d'identité de pod, transmettez-les `namespace(s)` `serviceAccountName(s)` au fichier de configuration, par exemple ``` iam: podIdentityAssociations: - namespace: default serviceAccountName: s3-reader - namespace: dev serviceAccountName: app-cache-access ``` et lancez : ``` eksctl delete podidentityassociation -f config.yaml ``` OU (pour supprimer une seule association) transmettez les indicateurs `--namespace` et `--service-account-name` via la CLI : ``` eksctl delete podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader ``` ## Support des modules complémentaires EKS pour les associations d'identité des pods Les modules complémentaires EKS permettent également de recevoir des autorisations IAM via EKS Pod Identity Associations. Le fichier de configuration expose trois champs qui permettent de les configurer :`addon.podIdentityAssociations`, `addonsConfig.autoApplyPodIdentityAssociations` et`addon.useDefaultPodIdentityAssociations`. Vous pouvez soit configurer explicitement les associations d'identité d'espace souhaitées, en utilisant`addon.podIdentityAssociations`, soit résoudre (et appliquer) `eksctl` automatiquement la configuration d'identité d'espace recommandée, en utilisant l'un `addonsConfig.autoApplyPodIdentityAssociations` ou l'autre des deux`addon.useDefaultPodIdentityAssociations`. **Note** Les modules complémentaires EKS ne prendront pas tous en charge les associations d'identité des pods au lancement. Dans ce cas, les autorisations IAM requises continueront d'être fournies à l'aide des paramètres [IRSA](addons.md#addons-create). ### Création d'addons avec des autorisations IAM Lorsque vous créez un addon nécessitant des autorisations IAM, `eksctl` vous devez d'abord vérifier si les associations d'identité du pod ou les paramètres IRSA sont explicitement configurés dans le fichier de configuration, et si c'est le cas, utiliser l'un d'entre eux pour configurer les autorisations pour l'addon. Par exemple ``` addons: - name: vpc-cni podIdentityAssociations: - serviceAccountName: aws-node permissionPolicyARNs: ["arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"] ``` et courez ``` eksctl create addon -f config.yaml 2024-05-13 15:38:58 [ℹ] pod identity associations are set for "vpc-cni" addon; will use these to configure required IAM permissions ``` **Note** La définition simultanée de l'identité du pod et de l'IRSA n'est pas autorisée et entraînera une erreur de validation. Pour les modules complémentaires EKS qui prennent en charge les identités `eksctl` des pods, offre la possibilité de configurer automatiquement les autorisations IAM recommandées, lors de la création de l'addon. Cela peut être réalisé `addonsConfig.autoApplyPodIdentityAssociations: true` en configurant simplement le fichier de configuration. par exemple ``` addonsConfig: autoApplyPodIdentityAssociations: true # bear in mind that if either pod identity or IRSA configuration is explicitly set in the config file, # or if the addon does not support pod identities, # addonsConfig.autoApplyPodIdentityAssociations won't have any effect. addons: - name: vpc-cni ``` et courez ``` eksctl create addon -f config.yaml 2024-05-13 15:38:58 [ℹ] "addonsConfig.autoApplyPodIdentityAssociations" is set to true; will lookup recommended pod identity configuration for "vpc-cni" addon ``` De manière équivalente, la même chose peut être faite via les drapeaux de la CLI, par exemple ``` eksctl create addon --cluster my-cluster --name vpc-cni --auto-apply-pod-identity-associations ``` Pour migrer un addon existant afin d'utiliser l'identité du pod avec les politiques IAM recommandées, utilisez ``` addons: - name: vpc-cni useDefaultPodIdentityAssociations: true ``` ``` eksctl update addon -f config.yaml ``` ### Mise à jour des addons avec des autorisations IAM Lors de la mise à jour d'un addon, la spécification `addon.PodIdentityAssociations` représentera la source unique de vérité pour l'état que l'addon devra avoir, une fois l'opération de mise à jour terminée. Dans les coulisses, différents types d'opérations sont effectués afin d'atteindre l'état souhaité, c'est-à-dire + créer des identifiants de pod présents dans le fichier de configuration, mais absents du cluster + supprimer les identifiants de pod existants qui ont été supprimés du fichier de configuration, ainsi que toutes les ressources IAM associées + mettre à jour les identités de pod existantes qui sont également présentes dans le fichier de configuration et pour lesquelles l'ensemble des autorisations IAM a changé **Note** Le cycle de vie des associations d'identité des pods détenues par EKS Add-ons est directement géré par l'API EKS Addons. Vous ne pouvez pas utiliser `eksctl update podidentityassociation` (pour mettre à jour les autorisations IAM) ou `eksctl delete podidentityassociations` (pour supprimer l'association) pour les associations utilisées avec un module complémentaire Amazon EKS. Au lieu de cela, `eksctl update addon` ou `eksctl delete addon` doit être utilisé. Voyons un exemple pour ce qui précède, en commençant par analyser la configuration initiale de l'identité du pod pour l'addon : ``` eksctl get podidentityassociation --cluster my-cluster --namespace opentelemetry-operator-system --output json [ { ... "ServiceAccountName": "adot-col-prom-metrics", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-JwrGA4mn1Ny8", # OwnerARN is populated when the pod identity lifecycle is handled by the EKS Addons API "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/b2c7bb45-4090-bf34-ec78-a2298b8643f6" }, { ... "ServiceAccountName": "adot-col-otlp-ingest", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-Xc7qVg5fgCqr", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/b2c7bb45-4090-bf34-ec78-a2298b8643f6" } ] ``` Utilisez maintenant la configuration ci-dessous : ``` addons: - name: adot podIdentityAssociations: # For the first association, the permissions policy of the role will be updated - serviceAccountName: adot-col-prom-metrics permissionPolicyARNs: #- arn:aws:iam::aws:policy/AmazonPrometheusRemoteWriteAccess - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy # The second association will be deleted, as it's been removed from the config file #- serviceAccountName: adot-col-otlp-ingest # permissionPolicyARNs: # - arn:aws:iam::aws:policy/AWSXrayWriteOnlyAccess # The third association will be created, as it's been added to the config file - serviceAccountName: adot-col-container-logs permissionPolicyARNs: - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy ``` et courez ``` eksctl update addon -f config.yaml ... # updating the permission policy for the first association 2024-05-14 13:27:43 [ℹ] updating IAM resources stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" for pod identity association "a-reaxk2uz1iknwazwj" 2024-05-14 13:27:44 [ℹ] waiting for CloudFormation changeset "eksctl-opentelemetry-operator-system-adot-col-prom-metrics-update-1715682463" for stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" 2024-05-14 13:28:47 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" 2024-05-14 13:28:47 [ℹ] updated IAM resources stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" for "a-reaxk2uz1iknwazwj" # creating the IAM role for the second association 2024-05-14 13:28:48 [ℹ] deploying stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" 2024-05-14 13:28:48 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" 2024-05-14 13:29:19 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" # updating the addon, which handles the pod identity config changes behind the scenes 2024-05-14 13:29:19 [ℹ] updating addon # deleting the IAM role for the third association 2024-05-14 13:29:19 [ℹ] deleting IAM resources for pod identity service account adot-col-otlp-ingest 2024-05-14 13:29:20 [ℹ] will delete stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" 2024-05-14 13:29:20 [ℹ] waiting for stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" to get deleted 2024-05-14 13:29:51 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" 2024-05-14 13:29:51 [ℹ] deleted IAM resources for addon adot ``` vérifiez maintenant que la configuration de l'identité du pod a été correctement mise à jour ``` eksctl get podidentityassociation --cluster my-cluster --output json [ { ... "ServiceAccountName": "adot-col-prom-metrics", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-nQAlp0KktS2A", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/1ec7bb63-8c4e-ca0a-f947-310c4b55052e" }, { ... "ServiceAccountName": "adot-col-otlp-ingest", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-1k1XhAdziGzX", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/1ec7bb63-8c4e-ca0a-f947-310c4b55052e" } ] ``` Pour supprimer toutes les associations d'identité de pod d'un addon, celui-ci `addon.PodIdentityAssociations` doit être explicitement défini sur`[]`, par exemple ``` addons: - name: vpc-cni # omitting the `podIdentityAssociations` field from the config file, # instead of explicitly setting it to [], will result in a validation error podIdentityAssociations: [] ``` et courez ``` eksctl update addon -f config.yaml ``` ### Supprimer des addons avec des autorisations IAM La suppression d'un addon supprimera également toutes les identités de pod associées à l'addon. La suppression du cluster produira le même effet pour tous les addons. Tous les rôles IAM pour les identités des pods, créés par`eksctl`, seront également supprimés. ## Migration de comptes iamservice et d'extensions existants vers des associations d'identité de pod Il existe une commande `eksctl` utils pour migrer les rôles IAM existants pour les comptes de service vers des associations d'identité de pod, c'est-à-dire ``` eksctl utils migrate-to-pod-identity --cluster my-cluster --approve ``` Dans les coulisses, la commande appliquera les étapes suivantes : + installer l'`eks-pod-identity-agent`addon s'il n'est pas déjà actif sur le cluster + identifier tous les rôles IAM associés à iamserviceaccounts + identifier tous les rôles IAM associés aux modules complémentaires EKS qui prennent en charge les associations d'identité des pods + mettre à jour la politique de confiance IAM de tous les rôles identifiés, avec une entité de confiance supplémentaire, pointant vers le nouveau principal du service EKS (et, éventuellement, supprimer la relation de confiance existante avec le fournisseur OIDC) + créer des associations d'identité de pod pour les rôles filtrés associés à iamserviceaccounts + mettre à jour les extensions EKS avec les identités des pods (l'API EKS créera les identités des pods en arrière-plan) L'exécution de la commande sans l'`--approve`indicateur produira uniquement un plan composé d'un ensemble de tâches reflétant les étapes ci-dessus, par ex. ``` [ℹ] (plan) would migrate 2 iamserviceaccount(s) and 2 addon(s) to pod identity association(s) by executing the following tasks [ℹ] (plan) 3 sequential tasks: { install eks-pod-identity-agent addon, ## tasks for migrating the addons 2 parallel sub-tasks: { 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-DDuMLoeZ8weD", migrate addon aws-ebs-csi-driver to pod identity, }, 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-xYiPFOVp1aeI", migrate addon vpc-cni to pod identity, }, }, ## tasks for migrating the iamserviceaccounts 2 parallel sub-tasks: { 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-QLXqHcq9O1AR", create pod identity association for service account "default/sa1", }, 2 sequential sub-tasks: { update trust policy for unowned role "Unowned-Role1", create pod identity association for service account "default/sa2", }, } } [ℹ] all tasks were skipped [!] no changes were applied, run again with '--approve' to apply the changes ``` La relation de confiance existante avec le fournisseur OIDC est toujours supprimée des rôles IAM associés aux modules complémentaires EKS. En outre, pour supprimer la relation de confiance existante du fournisseur OIDC dans les rôles IAM associés à iamserviceaccounts, exécutez la commande avec un indicateur, par exemple `--remove-oidc-provider-trust-relationship` ``` eksctl utils migrate-to-pod-identity --cluster my-cluster --approve --remove-oidc-provider-trust-relationship ``` ## Support d'identité multi-comptes Pod eksctl prend en charge l'accès entre [comptes EKS Pod Identity.](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) Cette fonctionnalité permet aux pods exécutés dans votre cluster EKS d'accéder aux ressources AWS depuis un autre compte AWS. ### Usage Pour créer une association d'identité de pod avec un accès entre comptes, configurez d'abord les rôles et politiques IAM autorisant l'accès d'un compte AWS source (avec le cluster) à un compte AWS cible (avec les ressources auxquelles le cluster peut accéder). Pour un exemple, consultez [« Amazon EKS Pod Identity rationalise l'accès entre comptes ».](https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-streamlines-cross-account-access/) Une fois qu'un rôle IAM est configuré dans chaque compte, utilisez eksctl pour créer les associations d'identité du pod : ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: # The cluster name and service account name should match the target # account policy's trust relationship. name: my-cluster region: us-west-2 version: "1.32" addons: - name: vpc-cni - name: coredns - name: kube-proxy - name: eks-pod-identity-agent iam: podIdentityAssociations: - namespace: default serviceAccountName: demo-app-sa createServiceAccount: true # The source role in the same account as the cluster roleARN: arn:aws:iam::1111111111:role/account-a-role # The target role in a different account targetRoleARN: arn:aws:iam::2222222222:role/account-b-role # Optional: Disable session tags disableSessionTags: false managedNodeGroups: - name: my-cluster instanceType: m6a.large privateNetworking: true minSize: 2 desiredCapacity: 2 maxSize: 3 ``` ## Autres références [Support officiel d'AWS Userdocs pour les modules complémentaires EKS pour les identités des pods](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-iam.html) [Article de blog officiel d'AWS sur les associations d'identité des pods](https://aws.amazon.com/blogs/aws/amazon-eks-pod-identity-simplifies-iam-permissions-for-applications-on-amazon-eks-clusters/) [Documents utilisateur AWS officiels pour Pod Identity Associations](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)