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.

Vous souhaitez contribuer à ce guide de l'utilisateur ? Choisissez le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.

Octroi IAM accès des utilisateurs à Kubernetes avec un ConfigMap

Important

aws-auth ConfigMap est obsolète. Pour la méthode recommandée pour gérer l'accès à Kubernetes APIs, voirOctroi IAM accès des utilisateurs à Kubernetes avec 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 aws-auth ConfigMap paramètres, voir 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 accorder à d'autres principaux IAM la possibilité d'interagir avec votre cluster, modifiez le aws-auth ConfigMap Kubernetes et créez un Kubernetes rolebindingou clusterrolebinding avec le nom d'un nom group que vous spécifiez dans leaws-auth ConfigMap.

Note

Pour plus d'informations sur Kubernetes configuration du contrôle d'accès basé sur les rôles (RBAC), voir Utilisation de l'autorisation RBAC dans le 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 avez déjà Kubernetes rolesrolebindingset/ou clusterroles et clusterrolebindings auxquels vous pouvez mapper les principes IAM. Pour plus d'informations sur ces ressources, consultez la section Utilisation de l'autorisation RBAC dans le Kubernetes .
1. Afficher vos données existantes Kubernetes rolesouclusterroles. Rolessont limités à anamespace, mais clusterroles sont limité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. Afficher vos données existantes Kubernetes rolebindingsouclusterrolebindings. Rolebindingssont limités à anamespace, mais clusterrolebindings sont limité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.199.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 indiqué dans votre Kubernetes RoleBindingou ClusterRoleBinding objet. 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 indiqué dans votre Kubernetes RoleBindingou ClusterRoleBinding objet. 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 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.
  - nom d'utilisateur : le nom d'utilisateur indiqué dans Kubernetes pour mapper au rôle IAM.
  - groupes : le groupe ou la liste de Kubernetes groupes auxquels associer 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 le 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.
  - nom d'utilisateur : le nom d'utilisateur indiqué dans Kubernetes pour mapper vers l'utilisateur IAM.
  - groupes : le groupe ou la liste de Kubernetes groupes auxquels associer 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 le Kubernetes .
Par exemple, le bloc YAML ci-dessous contient :
- mapRolesSection qui mappe l'instance du nœud IAM à Kubernetes groupes afin que les nœuds puissent s'enregistrer auprès du cluster et du rôle my-console-viewer-role IAM mappé à un Kubernetes groupe qui peut tout afficher Kubernetes ressources pour tous les clusters. Pour une liste de l'IAM et Kubernetes autorisations de groupe requises pour le rôle my-console-viewer-role IAM, voirAutorisations requises.
- mapUsersSection qui fait correspondre l'utilisateur admin IAM du AWS compte par défaut au system:masters Kubernetes le groupe et l'my-userutilisateur d'un autre AWS compte mappé à un Kubernetes groupe qui peut voir Kubernetes ressources pour un espace de noms spécifique. Pour une liste de l'IAM et Kubernetes autorisations de groupe requises pour l'utilisateur my-user IAM, voirAutorisations 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.

Conventions de rédaction

Vérifiez les autorisations de la politique d'accès

Accorder aux utilisateurs l'accès à Kubernetes avec un appareil externe OIDC provider