Octroi IAM accès des utilisateurs à Kubernetes avec un ConfigMap - Amazon EKS
Ajouter des IAM principesAppliquer la ConfigMap aws-auth à votre cluster

Aidez à améliorer cette page

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tous.

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.

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

Important

L'interface aws-auth ConfigMap est obsolète. La méthode recommandée pour gérer l'accès à Kubernetes APIsest Access Entries.

L'accès à votre cluster à l'aide de IAMprincipes est activé par l'AWS IAMauthentificateur pour Kubernetes, qui fonctionne sur le plan EKS de contrôle Amazon. 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.

Ajoutez IAM des principaux à votre cluster Amazon EKS

Lorsque vous créez un EKS cluster Amazon, le IAMprincipal 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 EKS contrôle Amazon. Ce principal n'apparaît dans aucune configuration visible. Souvenez-vous donc du principal qui a créé le cluster à l'origine. Pour accorder à IAM d'autres principaux 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'RBACautorisation dans Kubernetes .

Pour ajouter un IAM principal à un EKS cluster Amazon

  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. Remplacez ~/.kube/config par le chemin de votre fichier kubeconfig 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 IAM principaux. IAMles meilleures pratiques recommandent d'accorder des autorisations aux rôles plutôt qu'aux 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.

  2. Assurez-vous que vous avez déjà Kubernetes rolesrolebindingset/ou clusterroles et sur clusterrolebindings lesquels vous pouvez mapper IAM des principes. Pour plus d'informations sur ces ressources, consultez la section Utilisation de l'RBACautorisation 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. Consultez les détails de n'importe role lequel ou clusterrole renvoyé dans la sortie précédente et confirmez qu'il dispose des autorisations (rules) que vous souhaitez accorder à IAM vos principaux 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

  3. 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 aws-authConfigMap modifications aux guides des EKS meilleures pratiques d'Amazon. Un aws-auth ConfigMap mis en forme incorrectement peut entraîner la perte de l'accès à votre cluster.

    eksctl
    Prérequis

    Version 0.191.0 ou ultérieure de l'outil de ligne de commande eksctl installée sur votre appareil ou AWS CloudShell. Pour installer ou mettre à jour eksctl, veuillez consulter Installation dans la documentation de eksctl.

    1. Affichez les mappages actuels dans le ConfigMap. Remplacez my-cluster par le nom de votre cluster. region-codeRemplacez-le par Région AWS celui dans lequel 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

    2. 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 avec le nom de votre choix.

      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

      Le rôle ne ARN peut pas inclure un chemin tel querole/my-team/developers/my-role. Le format du ARN doit êtrearn: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

    3. Ajoutez un mappage pour un utilisateur. IAMles meilleures pratiques recommandent d'accorder des autorisations aux rôles plutôt qu'aux 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 avec le nom de votre choix.

      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

    4. 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
    Edit ConfigMap manually

    1. Ouvrez le ConfigMap pour le modifier.

      kubectl edit -n kube-system configmap/aws-auth
      Note

      Si vous recevez une erreur indiquant « Error from server (NotFound): configmaps "aws-auth" not found », suivez la procédure dans Appliquer la ConfigMap aws-auth à votre cluster pour appliquer le ConfigMap stock.

    2. Ajoutez vos IAM principes au. ConfigMap Un IAM groupe n'est pas un IAM principal, il ne peut donc pas être ajouté auConfigMap.

      • Pour ajouter un IAM rôle (par exemple, pour les utilisateurs fédérés) : ajoutez les détails du rôle dans la mapRoles section duConfigMap, sousdata. Ajoutez cette section si elle n'existe pas déjà dans le fichier. Chaque entrée prend en charge les paramètres suivants :

        • rolearn : Le ARN IAM rôle à ajouter. Cette valeur ne peut pas inclure un chemin. Par exemple, vous ne pouvez pas spécifier un ARN tel quearn:aws:iam::111122223333:role/my-team/developers/role-name. Les ARN besoins doivent l'être arn:aws:iam::111122223333:role/role-name plutôt.

        • nom d'utilisateur : le nom d'utilisateur indiqué dans Kubernetes pour mapper au IAM rôle.

        • 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 IAM utilisateur : les IAM meilleures pratiques recommandent d'accorder des autorisations aux rôles plutôt qu'aux 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 : celui ARN de l'IAMutilisateur à ajouter.

        • nom d'utilisateur : le nom d'utilisateur indiqué dans Kubernetes pour mapper à l'IAMutilisateur.

        • 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 YAML bloc suivant contient :

      • mapRolesSection qui fait correspondre l'instance du IAM nœud à Kubernetes groupes afin que les nœuds puissent s'enregistrer auprès du cluster et du my-console-viewer-role IAM rôle mappé à un Kubernetes groupe qui peut tout afficher Kubernetes ressources pour tous les clusters. Pour une liste des IAM et Kubernetes autorisations de groupe requises pour le my-console-viewer-role IAM rôle, voirAutorisations nécessaires.

      • Une mapUsers section qui fait correspondre l'adminIAMutilisateur 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 des IAM et Kubernetes autorisations de groupe requises pour l'my-userIAMutilisateur, voirAutorisations nécessaires.

      Ajoutez ou supprimez des lignes selon les besoins et remplacez-les toutes exemples de valeurs avec 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

    3. 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 pouvez également l'utiliser ConfigMap pour ajouter un contrôle d'accès basé sur les rôles (RBAC) aux IAM principaux. Si vous avez lancé des nœuds autogérés et que vous n'avez pas encore appliqué la aws-auth ConfigMap à votre cluster, vous pouvez le faire en suivant la procédure ci-dessous.

Pour appliquer le aws-authConfigMap à votre cluster

  1. Vérifiez si vous avez déjà appliqué la aws-auth ConfigMap.

    kubectl describe configmap -n kube-system aws-auth

    Si vous recevez une erreur indiquant « Error from server (NotFound): configmaps "aws-auth" not found », effectuez les opérations suivantes pour appliquer le ConfigMap stock.

  2. 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 aws-auth-cm.yaml fichier, définissez le nom rolearn de ressource Amazon (ARN) du IAM rôle associé à 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

      Le rôle ne ARN peut pas inclure un chemin tel querole/my-team/developers/my-role. Le format du ARN doit êtrearn: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 Vended 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.

  3. 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.