**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 utilisateurs IAM l'accès à Kubernetes avec un ConfigMap **Important** `aws-auth ConfigMap` est obsolète. Pour connaître la méthode recommandée pour gérer l'accès à Kubernetes APIs, consultez. [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md) L’accès à votre cluster à l’aide des [principaux IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) est activé par l’[authentificateur AWS IAM pour Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme), qui s’exécute sur le plan de contrôle Amazon EKS. L'authentificateur obtient ses informations de configuration à partir du `aws-auth` `ConfigMap`. Pour tous les paramètres `aws-auth` `ConfigMap`, consultez [Format de configuration complet](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format) sur GitHub. ## Ajout de principaux IAM à votre cluster Amazon EKS Lorsque vous créez un cluster Amazon EKS, le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) qui crée le cluster se voit automatiquement accorder des autorisations `system:masters` dans la configuration du contrôle d’accès basé sur les rôles (RBAC) du cluster dans le plan de contrôle Amazon EKS. Ce principal n’apparaît dans aucune configuration visible. Souvenez-vous donc du principal qui a créé le cluster à l’origine. Pour accorder à d’autres principaux IAM la possibilité d’interagir avec votre cluster, modifiez le `aws-auth ConfigMap` dans Kubernetes et créez un `rolebinding` ou `clusterrolebinding` Kubernetes associé au nom d’un `group` que vous spécifiez dans le `aws-auth ConfigMap`. **Note** Pour plus d’informations sur la configuration du contrôle d’accès basé sur les rôles (RBAC) de Kubernetes, consultez la section [Utilisation de l’autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes. 1. Déterminer les informations d'identification que `kubectl` utilise pour accéder à votre cluster. Sur votre ordinateur, vous pouvez voir quelles informations d'identification `kubectl` utilise avec la commande suivante. *\$1/.kube/config*Remplacez-le par le chemin de votre `kubeconfig` fichier si vous n'utilisez pas le chemin par défaut. ``` cat ~/.kube/config ``` L'exemple qui suit illustre un résultat. ``` [...] contexts: - context: cluster: my-cluster.region-code.eksctl.io user: admin@my-cluster.region-code.eksctl.io name: admin@my-cluster.region-code.eksctl.io current-context: admin@my-cluster.region-code.eksctl.io [...] ``` Dans l'exemple de sortie précédent, les informations d'identification d'un utilisateur nommé *admin* sont configurées pour un cluster nommé *my-cluster*. Si c'est l'utilisateur qui a créé le cluster, alors il a déjà accès à votre cluster. S’il ne s’agit pas de l’utilisateur qui a créé le cluster, suivez les étapes restantes pour permettre à d’autres principaux IAM d’accéder au cluster. Les [bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) recommandent d'accorder des autorisations à des rôles plutôt qu'à des utilisateurs. Vous pouvez voir quels autres principaux ont actuellement accès à votre cluster à l'aide de la commande suivante : ``` kubectl describe -n kube-system configmap/aws-auth ``` L'exemple qui suit illustre un résultat. ``` Name: aws-auth Namespace: kube-system Labels: Annotations: Data ==== mapRoles: ---- - groups: - system:bootstrappers - system:nodes rolearn: arn:aws: iam::111122223333:role/my-node-role username: system:node:{{EC2PrivateDNSName}} BinaryData ==== Events: ``` L'exemple précédent est un `aws-auth` `ConfigMap` par défaut. Seul le rôle d'instance du nœud a accès au cluster. 1. Assurez-vous de disposer de `roles` et `rolebindings` ou de `clusterroles` et `clusterrolebindings` existants auxquels vous pouvez associer des principaux IAM. Pour plus d'informations sur ces ressources, consultez [Utilisation de l'autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes. 1. Affichez vos `roles` ou `clusterroles` Kubernetes existants. Les `Roles` sont associés à un `namespace`, mais les `clusterroles` sont associés au cluster. ``` kubectl get roles -A ``` ``` kubectl get clusterroles ``` 1. Affichez les détails de tout `role` ou `clusterrole` renvoyé dans la sortie précédente et assurez-vous qu'il dispose des autorisations (`rules`) dont vous souhaitez que vos principaux IAM disposent dans votre cluster. Remplacez *role-name* par un nom de `role` renvoyé dans la sortie de la commande précédente. Remplacez *kube-system* par l'espace de noms du `role`. ``` kubectl describe role role-name -n kube-system ``` Remplacez *cluster-role-name* par un nom de `clusterrole` renvoyé dans la sortie de la commande précédente. ``` kubectl describe clusterrole cluster-role-name ``` 1. Affichez vos `rolebindings` ou `clusterrolebindings` Kubernetes existants. Les `Rolebindings` sont associés à un `namespace`, mais les `clusterrolebindings` sont associés au cluster. ``` kubectl get rolebindings -A ``` ``` kubectl get clusterrolebindings ``` 1. Affichez les détails de n'importe quel `rolebinding` ou `clusterrolebinding` et confirmez qu'il possède un `role` ou un `clusterrole` de l'étape précédente répertorié comme un `roleRef` et un nom de groupe répertorié pour `subjects`. Remplacez *role-binding-name* par un nom de `rolebinding` renvoyé dans la sortie de la commande précédente. Remplacez *kube-system* avec le `namespace` du `rolebinding`. ``` kubectl describe rolebinding role-binding-name -n kube-system ``` L'exemple qui suit illustre un résultat. ``` apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: eks-console-dashboard-restricted-access-role-binding namespace: default subjects: - kind: Group name: eks-console-dashboard-restricted-access-group apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: eks-console-dashboard-restricted-access-role apiGroup: rbac.authorization.k8s.io ``` Remplacez *cluster-role-binding-name* par un nom de `clusterrolebinding` renvoyé dans la sortie de la commande précédente. ``` kubectl describe clusterrolebinding cluster-role-binding-name ``` L'exemple qui suit illustre un résultat. ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: eks-console-dashboard-full-access-binding subjects: - kind: Group name: eks-console-dashboard-full-access-group apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: eks-console-dashboard-full-access-clusterrole apiGroup: rbac.authorization.k8s.io ``` 1. Modifiez le `aws-auth` `ConfigMap`. Vous pouvez utiliser un outil tel que `eksctl` pour mettre à jour le `ConfigMap` ou vous pouvez le mettre à jour manuellement en le modifiant. **Important** Nous vous recommandons d'utiliser `eksctl`, ou un autre outil, pour modifier le `ConfigMap`. Pour plus d'informations sur les autres outils que vous pouvez utiliser, consultez la section [Utiliser des outils pour apporter des modifications à l'aws- authConfigMap](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#use-tools-to-make-changes-to-the-aws-auth-configmap) dans les guides de bonnes pratiques Amazon EKS. Un `aws-auth` `ConfigMap` mis en forme incorrectement peut entraîner la perte de l'accès à votre cluster. + Consultez les étapes pour [modifier configmap avec eksctl](#configmap-eksctl). + Consultez les étapes pour [modifier configmap manuellement](#configmap-manual). ### Modification du ConfigMap avec eksctl 1. Vous avez besoin d'`0.215.0`une version ou d'une version ultérieure de l'outil de ligne de `eksctl` commande installée sur votre appareil ou AWS CloudShell. Pour installer ou mettre à jour `eksctl`, veuillez consulter [Installation](https://eksctl.io/installation) dans la documentation de `eksctl`. 1. Affichez les mappages actuels dans le `ConfigMap`. Remplacez *my-cluster* par le nom de votre cluster. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster. ``` eksctl get iamidentitymapping --cluster my-cluster --region=region-code ``` L'exemple qui suit illustre un résultat. ``` ARN USERNAME GROUPS ACCOUNT arn:aws: iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes ``` 1. Ajoutez un mappage pour un rôle. Remplacez *my-role* par le nom de votre rôle. Remplacez *eks-console-dashboard-full-access-group* par le nom du groupe spécifié dans votre Kubernetes `RoleBinding` ou votre objet. `ClusterRoleBinding` Remplacez *111122223333* par votre ID de compte. Vous pouvez remplacer *admin* par n'importe quel nom que vous choisissez. ``` eksctl create iamidentitymapping --cluster my-cluster --region=region-code \ --arn arn:aws: iam::111122223333:role/my-role --username admin --group eks-console-dashboard-full-access-group \ --no-duplicate-arns ``` **Important** L’ARN de rôle ne peut pas inclure de chemin d’accès tel que `role/my-team/developers/my-role`. Le format de l'ARN doit être ` arn:aws: iam::111122223333:role/my-role `. Dans cet exemple, `my-team/developers/` doit être supprimé. L'exemple qui suit illustre un résultat. ``` [...] 2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap ``` 1. Ajoutez un mappage pour un utilisateur. Les [bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) recommandent d'accorder des autorisations à des rôles plutôt qu'à des utilisateurs. Remplacez *my-user* par votre nom d'utilisateur. Remplacez *eks-console-dashboard-restricted-access-group* par le nom du groupe spécifié dans votre Kubernetes `RoleBinding` ou votre objet. `ClusterRoleBinding` Remplacez *111122223333* par votre ID de compte. Vous pouvez remplacer *my-user* par n'importe quel nom que vous choisissez. ``` eksctl create iamidentitymapping --cluster my-cluster --region=region-code \ --arn arn:aws: iam::111122223333:user/my-user --username my-user --group eks-console-dashboard-restricted-access-group \ --no-duplicate-arns ``` L'exemple qui suit illustre un résultat. ``` [...] 2022-05-09 14:53:48 [ℹ] adding identity "arn:aws: iam::111122223333:user/my-user" to auth ConfigMap ``` 1. Affichez de nouveau les mappages dans le `ConfigMap`. ``` eksctl get iamidentitymapping --cluster my-cluster --region=region-code ``` L'exemple qui suit illustre un résultat. ``` ARN USERNAME GROUPS ACCOUNT arn:aws: iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes arn:aws: iam::111122223333:role/admin my-role eks-console-dashboard-full-access-group arn:aws: iam::111122223333:user/my-user my-user eks-console-dashboard-restricted-access-group ``` ### Modification manuelle du ConfigMap 1. Ouvrez le `ConfigMap` pour le modifier. ``` kubectl edit -n kube-system configmap/aws-auth ``` **Note** Si vous recevez un message d'erreur indiquant `Error from server (NotFound): configmaps "aws-auth" not found` « », utilisez la procédure décrite dans [Appliquer l'aws-auth ConfigMap à votre cluster](#aws-auth-configmap) pour appliquer le stock. `ConfigMap` 1. Ajoutez vos principaux IAM à la `ConfigMap`. Un groupe IAM n’est pas un principal IAM et ne peut donc pas être ajouté au `ConfigMap`. + **Pour ajouter un rôle IAM (par exemple, pour les [utilisateurs fédérés](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)) :** ajoutez les détails du rôle à la section `mapRoles` du `ConfigMap`, sous `data`. Ajoutez cette section si elle n'existe pas déjà dans le fichier. Chaque entrée prend en charge les paramètres suivants : + **rolearn** : ARN du rôle IAM à ajouter. Cette valeur ne peut pas contenir de chemin. Par exemple, vous ne pouvez pas spécifier un ARN tel que ` arn:aws: iam::111122223333:role/my-team/developers/role-name `. L'ARN doit être ` arn:aws: iam::111122223333:role/role-name `. + **username** : nom d'utilisateur dans Kubernetes à mapper au rôle IAM. + **groups** : groupe ou liste des groupes Kubernetes auxquels mapper le rôle. Le groupe peut être un groupe par défaut ou un groupe spécifié dans un `clusterrolebinding` ou `rolebinding`. Pour plus d’informations, consultez [Rôles par défaut et liaisons de rôles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) dans la documentation Kubernetes. + **Pour ajouter un utilisateur IAM :** les [bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) recommandent d'accorder des autorisations à des rôles plutôt qu'à des utilisateurs. Ajoutez les détails de l'utilisateur dans la section `mapUsers` de la `ConfigMap`, sous `data`. Ajoutez cette section si elle n'existe pas déjà dans le fichier. Chaque entrée prend en charge les paramètres suivants : + **userarn** : ARN de l'utilisateur IAM à ajouter. + **username** : nom d'utilisateur dans Kubernetes à mapper à l'utilisateur IAM. + **groups** : groupe ou liste des groupes Kubernetes auxquels mapper l'utilisateur. Le groupe peut être un groupe par défaut ou un groupe spécifié dans un `clusterrolebinding` ou `rolebinding`. Pour plus d’informations, consultez [Rôles par défaut et liaisons de rôles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) dans la documentation Kubernetes. 1. Par exemple, le bloc YAML ci-dessous contient : + Une section `mapRoles` qui mappe l'instance du nœud IAM avec des groupes Kubernetes afin que les nœuds puissent s'inscrire eux-mêmes avec le cluster et le rôle IAM `my-console-viewer-role` mappé à un groupe Kubernetes pouvant afficher toutes les ressources Kubernetes pour tous les clusters. Pour obtenir la liste des autorisations de groupe IAM et Kubernetes requises pour le rôle IAM `my-console-viewer-role`, voir [Autorisations requises](view-kubernetes-resources.md#view-kubernetes-resources-permissions). + `mapUsers`Section qui fait correspondre l'utilisateur `admin` IAM du AWS compte par défaut au groupe `system:masters` Kubernetes et l'`my-user`utilisateur d'un autre AWS compte mappé à un groupe Kubernetes qui peut afficher les ressources Kubernetes pour un espace de noms spécifique. Pour obtenir la liste des autorisations de groupe IAM et Kubernetes requises pour l'utilisateur IAM `my-user`, voir [Autorisations requises](view-kubernetes-resources.md#view-kubernetes-resources-permissions). Ajoutez ou supprimez des lignes si nécessaire et remplacez toutes les valeurs d’exemple par vos propres valeurs. ``` # Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. # apiVersion: v1 data: mapRoles: | - groups: - system:bootstrappers - system:nodes rolearn: arn:aws: iam::111122223333:role/my-role username: system:node:{{EC2PrivateDNSName}} - groups: - eks-console-dashboard-full-access-group rolearn: arn:aws: iam::111122223333:role/my-console-viewer-role username: my-console-viewer-role mapUsers: | - groups: - system:masters userarn: arn:aws: iam::111122223333:user/admin username: admin - groups: - eks-console-dashboard-restricted-access-group userarn: arn:aws: iam::444455556666:user/my-user username: my-user ``` 1. Enregistrez le fichier et quittez votre éditeur de texte. ## Appliquer la `ConfigMap` `aws-auth` à votre cluster Le `aws-auth` `ConfigMap` est automatiquement créé et appliqué à votre cluster lorsque vous créez un groupe de nœuds géré ou lorsque vous créez un groupe de nœuds à l'aide de `eksctl`. Il est initialement créé pour permettre aux nœuds de rejoindre votre cluster, mais vous utilisez également cette `ConfigMap` pour ajouter un accès RBAC aux principaux IAM. Si vous avez lancé des nœuds autogérés et que vous n’avez pas appliqué le `ConfigMap` `aws-auth` à votre cluster, vous pouvez le faire à l’aide de la procédure suivante. 1. Vérifiez si vous avez déjà appliqué le `ConfigMap` `aws-auth`. ``` kubectl describe configmap -n kube-system aws-auth ``` Si vous recevez une erreur indiquant « `Error from server (NotFound): configmaps "aws-auth" not found` », appliquez le `ConfigMap` par défaut en suivant les étapes ci-dessous. 1. Téléchargez, modifiez et appliquez le plan de configuration de l' AWS authentificateur. 1. Téléchargez la mappe de configuration. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml ``` 1. Dans le fichier `aws-auth-cm.yaml`, remplacez `rolearn` par l'Amazon Resource Name (ARN) du rôle IAM associé par vos nœuds. Pour ce faire, utilisez un éditeur de texte ou remplacez *my-node-instance-role* et exécutez la commande suivante : ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` Ne modifiez aucune autre ligne de ce fichier. **Important** L’ARN de rôle ne peut pas inclure de chemin d’accès tel que `role/my-team/developers/my-role`. Le format de l'ARN doit être ` arn:aws: iam::111122223333:role/my-role `. Dans cet exemple, `my-team/developers/` doit être supprimé. Vous pouvez inspecter les sorties de la AWS CloudFormation pile pour vos groupes de nœuds et rechercher les valeurs suivantes : + **InstanceRoleARN** — Pour les groupes de nœuds créés avec `eksctl` + **NodeInstanceRole**— Pour les groupes de nœuds créés à l'aide de AWS CloudFormation modèles Amazon EKS vendus dans le AWS Management Console 1. Appliquez la configuration. L'exécution de cette commande peut prendre quelques minutes. ``` kubectl apply -f aws-auth-cm.yaml ``` **Note** Si vous recevez d'autres erreurs concernant les types d'autorisations ou de ressources, consultez [Accès non autorisé ou refusé (`kubectl`)](troubleshooting.md#unauthorized) dans la rubrique relative à la résolution des problèmes. 1. Observez le statut de vos nœuds et attendez qu'ils obtiennent le statut `Ready`. ``` kubectl get nodes --watch ``` Saisissez `Ctrl`\$1`C` pour revenir à une invite de shell.