Accordez aux utilisateurs IAM l'accès à Kubernetes avec un ConfigMap

Mode de mise au point

Accordez aux utilisateurs IAM l'accès à Kubernetes avec un ConfigMap - Amazon EKS

Ajout de principaux IAM à votre cluster Amazon EKS Appliquer la ConfigMap aws-auth à votre cluster

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.

Aidez à améliorer cette page

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.

Important

aws-auth ConfigMap est obsolète. Pour connaître la méthode recommandée pour gérer l'accès à Kubernetes APIs, consultez. Accorder aux utilisateurs IAM l'accès à Kubernetes avec des entrées d'accès EKS

L'accès à votre cluster à l'aide des principes IAM est activé par l'authentificateur AWS IAM pour Kubernetes, 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 sur GitHub.

Ajout de principaux IAM à votre cluster Amazon EKS

Lorsque vous créez un cluster Amazon EKS, le principal IAM qui crée le cluster reçoit automatiquement des system:masters autorisations 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. Assurez-vous donc de savoir quel principal a créé le cluster à l'origine. Pour autoriser des principaux IAM supplémentaires à interagir avec votre cluster, modifiez-le aws-auth ConfigMap dans Kubernetes et créez un Kubernetes rolebinding ou clusterrolebinding avec le nom d'un Kubernetes que vous spécifiez dans le. group 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 dans la documentation de Kubernetes.

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. ~/.kube/configRemplacez-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. Si ce n'est pas l'utilisateur qui a créé le cluster, vous devez effectuer les étapes restantes pour permettre l'accès au cluster pour les autres principaux IAM. Les bonnes pratiques IAM 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:       <none>
Annotations:  <none>

Data
====
mapRoles:
----
- groups:
  - system:bootstrappers
  - system:nodes
  rolearn: arn:aws: iam::111122223333:role/my-node-role
  username: system:node:{{EC2PrivateDNSName}}


BinaryData
====

Events:  <none>
```
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.
Assurez-vous que vous disposez de Kubernetes rolebindings et/ou de Kubernetes existants roles clusterroles et clusterrolebindings que vous pouvez y mapper les principaux IAM. Pour plus d'informations sur ces ressources, consultez Utilisation de l'autorisation 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
```
2. 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
```
3. 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
```
4. 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
```
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 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 le fichier configmap avec eksctl.
- Consultez les étapes pour modifier manuellement le configmap.

Modifier Configmap avec Eksctl

Vous avez besoin d'0.205.0une 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 dans la documentation de eksctl.

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

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 du rôle ne peut pas inclure un chemin tel querole/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
```
Ajoutez un mappage pour un utilisateur. Les bonnes pratiques IAM 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
```

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

Modifier manuellement le fichier Configmap

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 pour appliquer le stock. ConfigMap
Ajoutez vos principaux IAM à la ConfigMap. Un groupe IAM n'est pas un principal IAM, il ne peut donc pas être ajouté au. ConfigMap
- Pour ajouter un rôle IAM (par exemple, pour les utilisateurs fédérés) : 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 inclure de chemin. Par exemple, vous ne pouvez pas spécifier un ARN tel quearn: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 la section Rôles par défaut et liaisons de rôles dans la documentation de Kubernetes.
- Pour ajouter un utilisateur IAM : les bonnes pratiques IAM 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 la section Rôles par défaut et liaisons de rôles dans la documentation de Kubernetes.
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.
- mapUsersSection qui fait correspondre l'utilisateur admin IAM du AWS compte par défaut au groupe system:masters Kubernetes et l'my-userutilisateur 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.
  
  Ajoutez ou supprimez des lignes si nécessaire et remplacez toutes les example values 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
```
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 ne les avez pas appliqués aws-auth ConfigMap à votre cluster, vous pouvez le faire en suivant la procédure suivante.

Vérifiez si vous avez déjà appliqué le aws-authConfigMap.
```
kubectl describe configmap -n kube-system aws-auth
```
Si vous recevez un message d'erreur indiquant Error from server (NotFound): configmaps "aws-auth" not found « », procédez comme suit pour appliquer le stockConfigMap.
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
```
2. 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|<ARN of instance role (not instance profile)>|my-node-instance-role|' aws-auth-cm.yaml
```
  Ne modifiez aucune autre ligne de ce fichier.
  
  Important
  L'ARN du rôle ne peut pas inclure un chemin tel querole/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
3. 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) dans la rubrique relative à la résolution des problèmes.
Observez le statut de vos nœuds et attendez qu'ils obtiennent le statut Ready.
```
kubectl get nodes --watch
```
Saisissez Ctrl+C pour revenir à une invite de shell.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.