Autorisation d'un principal IAM à accéder à votre cluster - Amazon EKS

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.

Autorisation d'un principal IAM à accéder à votre cluster

L'authentificateur IAM AWS pour Kubernetes, qui s'exécute sur le plan de contrôle Amazon EKS, permet à des principaux IAM d'accéder à votre cluster. 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 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 permettre à d'autres principaux IAM d'interagir avec votre cluster, modifiez la ConfigMap aws-auth dans Kubernetes et créez un rolebinding ou un clusterrolebinding Kubernetes avec le nom d'un group que vous spécifiez dans la ConfigMap aws-auth.

Note

Pour plus d'informations sur la configuration du contrôle d'accès basé sur les rôles (RBAC) de Kubernetes, consultez la rubrique Utilisation de l'autorisation RBAC de la documentation Kubernetes.

Pour ajouter un principal IAM à un cluster Amazon EKS
  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. 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 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.

  2. Assurez-vous de disposer de roles et de rolebindings ou de clusterroles et de clusterrolebindings Kubernetes auxquels vous pouvez mapper des principaux IAM. Pour plus d'informations sur ces ressources, consultez Utilisation de l'autorisation RBAC dans la documentation Kubernetes.

    1. Affichez vos Kubernetes roles ou clusterroles existants. Les Roles sont étendus à un namespace, mais les clusterroles sont étendus 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 Kubernetes rolebindings ou clusterrolebindings existants. Les Rolebindings sont étendus à un namespace, mais les clusterrolebindings sont étendus 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 Utiliser des outils pour apporter des modifications au aws-authConfigMap dans les guides des bonnes pratiques Amazon EKS. Un aws-auth ConfigMap mis en forme incorrectement peut entraîner la perte de l'accès à votre cluster.

    eksctl
    Prérequis

    Version 0.172.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 spécifié dans votre Kubernetes RoleBinding ou 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
    3. 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 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
    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 principaux IAM à la ConfigMap. Un groupe IAM n'est pas un principal IAM, il ne peut donc pas être ajouté à la 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 un 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 : le nom d'utilisateur dans Kubernetes à mapper au rôle IAM.

        • groups : le groupe ou la 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 dans la documentation 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 : le nom d'utilisateur dans Kubernetes à mapper à l'utilisateur IAM.

        • groups : le groupe ou la 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 dans la documentation 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 nécessaires.

      • mapUsersSection qui fait correspondre l'utilisateur admin IAM du AWS compte par défaut au system:masters Kubernetes groupe et l'my-userutilisateur d'un autre AWS compte mappé à un Kubernetes groupe qui peut afficher les Kubernetes ressources d'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 nécessaires.

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

    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.