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. # Rôles IAM pour les comptes de service **Astuce** `eksctl`prend en charge la configuration d'autorisations détaillées pour les applications EKS exécutant des applications via [EKS Pod](pod-identity-associations.md) Identity Associations Amazon EKS prend en charge [ici](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) [Roles for Service Accounts (IRSA)], qui permet aux opérateurs de clusters de mapper les rôles AWS IAM aux comptes de service Kubernetes. Cela permet une gestion précise des autorisations pour les applications qui s'exécutent sur EKS et utilisent d'autres services AWS. Il peut s'agir d'applications utilisant S3, tout autre service de données (RDS, MQ, STS, DynamoDB) ou des composants Kubernetes tels que le contrôleur AWS Load Balancer ou ExternalDNS. Vous pouvez facilement créer des paires de rôles IAM et de comptes de service avec`eksctl`. **Note** Si vous avez utilisé [des rôles d'instance](iam-policies.md) et que vous envisagez d'utiliser IRSA à la place, vous ne devez pas mélanger les deux. ## Comment ça marche Il fonctionne via le fournisseur IAM OpenID Connect (OIDC) exposé par EKS, et les rôles IAM doivent être construits en référence au fournisseur IAM OIDC (spécifique à un cluster EKS donné) et en référence au compte de service Kubernetes auquel il sera lié. Une fois qu'un rôle IAM est créé, un compte de service doit inclure l'ARN de ce rôle sous forme d'annotation (`eks.amazonaws.com/role-arn`). Par défaut, le compte de service sera créé ou mis à jour pour inclure l'annotation du rôle. Cela peut être désactivé à l'aide du drapeau`--role-only`. Dans EKS, il existe un [contrôleur d'admission](https://github.com/aws/amazon-eks-pod-identity-webhook/) qui injecte les informations d'identification de session AWS dans les pods respectivement des rôles en fonction de l'annotation sur le compte de service utilisé par le pod. Les informations d'identification seront exposées par les variables `AWS_ROLE_ARN` d'`AWS_WEB_IDENTITY_TOKEN_FILE`environnement &. Étant donné qu'une version récente du SDK AWS est utilisée (voir [ici](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) pour plus de détails sur la version exacte), l'application utilisera ces informations d'identification. `eksctl`Le nom de la ressource est *iamserviceaccount*, qui représente une paire de rôle IAM et de compte de service. ## Utilisation depuis la CLI **Note** Les rôles IAM pour les comptes de service nécessitent la version 1.13 ou supérieure de Kubernetes. Le fournisseur IAM OIDC n'est pas activé par défaut, vous pouvez utiliser la commande suivante pour l'activer ou utiliser le fichier de configuration (voir ci-dessous) : ``` eksctl utils associate-iam-oidc-provider --cluster= ``` Une fois que le fournisseur IAM OIDC est associé au cluster, pour créer un rôle IAM lié à un compte de service, exécutez : ``` eksctl create iamserviceaccount --cluster= --name= --namespace= --attach-policy-arn= ``` **Note** Vous pouvez spécifier `--attach-policy-arn` plusieurs fois l'utilisation de plusieurs politiques. Plus précisément, vous pouvez créer un compte de service avec un accès en lecture seule à S3 en exécutant : ``` eksctl create iamserviceaccount --cluster= --name=s3-read-only --attach-policy-arn=arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess ``` Par défaut, il sera créé dans l'espace de `default` noms, mais vous pouvez spécifier n'importe quel autre espace de noms, par exemple : ``` eksctl create iamserviceaccount --cluster= --name=s3-read-only --namespace=s3-app --attach-policy-arn=arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess ``` **Note** Si l'espace de noms n'existe pas déjà, il sera créé. Si vous avez déjà créé un compte de service dans le cluster (sans rôle IAM), vous devrez utiliser le `--override-existing-serviceaccounts` drapeau. Le balisage personnalisé peut également être appliqué au rôle IAM en spécifiant : `--tags` ``` eksctl create iamserviceaccount --cluster= --name= --tags "Owner=John Doe,Team=Some Team" ``` CloudFormation générera un nom de rôle incluant une chaîne aléatoire. Si vous préférez un nom de rôle prédéterminé, vous pouvez spécifier `--role-name` : ``` eksctl create iamserviceaccount --cluster= --name= --role-name "custom-role-name" ``` Lorsque le compte de service est créé et géré par un autre outil, tel que Helm, utilisez-le `--role-only` pour éviter les conflits. L'autre outil est alors chargé de gérer l'annotation ARN du rôle. Notez que cela n'`--override-existing-serviceaccounts`a aucun effet sur les comptes`roleOnly`/`--role-only`service, le rôle sera toujours créé. ``` eksctl create iamserviceaccount --cluster= --name= --role-only --role-name= ``` Lorsque vous avez un rôle existant que vous souhaitez utiliser avec un compte de service, vous pouvez fournir le `--attach-role-arn` drapeau au lieu de fournir les politiques. Pour garantir que le rôle ne peut être assumé que par le compte de service spécifié, vous devez définir un document de politique de relation [ici](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions)]. ``` eksctl create iamserviceaccount --cluster= --name= --attach-role-arn= ``` Pour mettre à jour les autorisations des rôles d'un compte de service, vous pouvez exécuter`eksctl update iamserviceaccount`. **Note** `eksctl delete iamserviceaccount`supprime Kubernetes `ServiceAccounts` même s'ils n'ont pas été créés par. `eksctl` ## Utilisation avec des fichiers de configuration Pour gérer à `iamserviceaccounts` l'aide du fichier de configuration, vous devrez définir `iam.withOIDC: true` et répertorier le compte sous lequel vous souhaitez accéder`iam.serviceAccount`. *Toutes les commandes sont prises en charge`--config-file`, vous pouvez gérer les *comptes iamservicede* la même manière que les groupes de nœuds.* La `eksctl create iamserviceaccount` commande prend en charge `--include` et `--exclude` signale (voir [cette section](general-nodegroups.md#node-include) pour plus de détails sur leur fonctionnement). Et la `eksctl delete iamserviceaccount` commande le prend également `--only-missing` en charge, vous pouvez donc effectuer des suppressions de la même manière que les groupes de nœuds. **Note** Les comptes de service IAM sont limités à un espace de noms, c'est-à-dire que deux comptes de service portant le même nom peuvent exister dans des espaces de noms différents. Ainsi, pour définir de manière unique un compte de service dans le cadre de `--exclude` drapeaux`--include`, vous devez transmettre la chaîne de nom au `namespace/name` format. P. ex. ``` eksctl create iamserviceaccount --config-file= --include backend-apps/s3-reader ``` L'option d'activation `wellKnownPolicies` est incluse pour utiliser IRSA dans des cas d'utilisation bien connus tels que `cluster-autoscaler` et`cert-manager`, en tant que raccourci pour les listes de politiques. Les politiques connues prises en charge et les autres propriétés de `serviceAccounts` sont documentées dans [le schéma de configuration](https://geoffcline.github.io/eksctl-schema-demo/#iam-serviceAccounts). Vous utilisez l'exemple de configuration suivant avec `eksctl create cluster` : ``` # An example of ClusterConfig with IAMServiceAccounts: --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: cluster-13 region: us-west-2 iam: withOIDC: true serviceAccounts: - metadata: name: s3-reader # if no namespace is set, "default" will be used; # the namespace will be created if it doesn't exist already namespace: backend-apps labels: {aws-usage: "application"} attachPolicyARNs: - "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess" tags: Owner: "John Doe" Team: "Some Team" - metadata: name: cache-access namespace: backend-apps labels: {aws-usage: "application"} attachPolicyARNs: - "arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess" - "arn:aws:iam::aws:policy/AmazonElastiCacheFullAccess" - metadata: name: cluster-autoscaler namespace: kube-system labels: {aws-usage: "cluster-ops"} wellKnownPolicies: autoScaler: true roleName: eksctl-cluster-autoscaler-role roleOnly: true - metadata: name: some-app namespace: default attachRoleARN: arn:aws:iam::123:role/already-created-role-for-app nodeGroups: - name: "ng-1" tags: # EC2 tags required for cluster-autoscaler auto-discovery k8s.io/cluster-autoscaler/enabled: "true" k8s.io/cluster-autoscaler/cluster-13: "owned" desiredCapacity: 1 ``` Si vous créez un cluster sans définir ces champs, vous pouvez utiliser les commandes suivantes pour activer tout ce dont vous avez besoin : ``` eksctl utils associate-iam-oidc-provider --config-file= eksctl create iamserviceaccount --config-file= ``` ## Informations supplémentaires + [Présentation de rôles IAM précis pour les comptes de service](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) + [Guide de l'utilisateur EKS - Rôles IAM pour les comptes de service](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) + [Mappage des utilisateurs et des rôles IAM avec les rôles Kubernetes RBAC](iam-identity-mappings.md)