Comment fournir un accès à d'autres utilisateurs et rôles IAM après la création d'un cluster dans Amazon EKS ?

Dernière mise à jour : 08/02/2021

Lorsque j'essaie d'accéder au service Amazon Elastic Kubernetes Service (Amazon EKS) via des commandes kubectl, je reçois l'erreur « error: You must be logged in to the server (Unauthorized) » (Erreur : vous devez être connecté au serveur (non autorisé).

Brève description

Vous obtenez une erreur d'autorisation lorsque votre entité AWS Identity and Access Management (IAM) n'est pas autorisée par la configuration du Role-Based Access Control (RBAC) (Contrôle d'accès en fonction du rôle) du cluster Amazon EKS. Cette erreur se produit lorsque le cluster Amazon EKS est créé par un utilisateur ou un rôle IAM différent de celui utilisé par aws-iam-authenticator.

Au départ, seul le créateur du cluster Amazon EKS possède les autorisations system:masters pour configurer le cluster. Pour étendre les autorisations system:masters à d’autres utilisateurs et rôles, vous devez ajouter le ConfigMap aws-auth à la configuration du cluster Amazon EKS. La ConfigMap permet à d'autres entités IAM, telles que des utilisateurs et des rôles, d'accéder au cluster Amazon EKS.

Important : notez ce qui suit :

  • Évitez les erreurs de syntaxe (telles que les fautes de frappe) lorsque vous mettez à jour la ConfigMap aws-auth . Ces erreurs peuvent affecter les autorisations de tous les utilisateurs et rôles IAM mis à jour dans la ConfigMap du cluster Amazon EKS.
  • Il est recommandé d'éviter d'ajouter cluster_creator à la ConfigMap, car la modification incorrecte du ConfigMap peut entraîner la perte permanente de l'accès au cluster Amazon EKS par tous les utilisateurs et rôles IAM (y compris cluster_creator).
  • Vous n'avez pas besoin d'ajouter cluster_creator à la ConfigMap aws-auth pour obtenir l'accès administrateur au cluster Amazon EKS. Par défaut, cluster_creator dispose d'un accès administrateur au cluster Amazon EKS qu'il a créé.

Remarque : si vous recevez des erreurs lors de l'exécution de commandes depuis l'interface de ligne de commande AWS (CLI AWS), assurez-vous d'utiliser la version la plus récente de cette dernière.

Solution

Remarque : dans les étapes suivantes, le créateur de cluster est cluster_creator. L'utilisateur qui n'a pas actuellement accès au cluster, mais qui en a besoin est designated_user.

Identification de l'utilisateur ou du rôle IAM du créateur du cluster

1.    Identifiez l'utilisateur ou le rôle IAM du créateur de cluster disposant d'un accès maître pour configurer votre cluster Amazon EKS.

2.    Identifiez l'utilisateur IAM auquel le créateur du cluster accordera l'autorisation après la création du cluster. Pour identifier le créateur du cluster, recherchez l'appel d'API CreateCluster dans AWS CloudTrail, puis vérifiez la section userIdentity de l'appel d'API.

Ajout d'un utilisateur désigné (designated_user) à la ConfigMap si cluster_creator est un utilisateur IAM

1.    Utilisez SSH pour vous connecter à l’instance kubectl.

2.    Dans l'interface de ligne de commande AWS, exécutez la commande suivante :

aws sts get-caller-identity

Le résultat présente les détails de l’utilisateur IAM pour designated_user.

3.    Pour répertorier les pods en cours d’exécution dans le cluster de l’espace de noms par défaut, exécutez la commande kubectl suivante :

kubectl get pods

Le résultat affiche le message d'erreur suivant : « error: You must be logged in to the server (Unauthorized) » (« Erreur : vous devez être connecté au serveur [non autorisé]. »). Cette erreur signifie que le designated_user n'est pas autorisé à accéder au cluster Amazon EKS.

4.    Pour configurer l’ID de clé d’accès AWS et la clé d’accès secrète AWS du cluster_creator, exécutez la commande suivante :

aws configure

5.    Pour vérifier que cluster_creator a accès au cluster, exécutez la commande suivante :

kubectl get pods

Si tout est configuré correctement, vous n'obtenez pas de message d'erreur d'absence d'autorisation, et la sortie doit répertorier tous les pods s'exécutant dans l'espace de noms par défaut. Si le résultat montre qu'aucune ressource n'a été trouvée, cela signifie qu'aucun pod n'est en cours d'exécution.

6.    Pour permettre à designated_user d'accéder au cluster, ajoutez la section mapUsers à votre fichier aws-auth.yaml. Consultez l'exemple de fichier aws-auth.yaml suivant dans Gestion des utilisateurs ou des rôles IAM de votre cluster :

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

7.    Ajoutez designated_user à la section mapUsers du fichier aws-auth.yaml à l’étape 6, puis enregistrez le fichier. Par exemple :

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: aws-auth 
  namespace: kube-system 
data: 
  mapRoles: | 
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B 
      username: system:node:{{EC2PrivateDNSName}} 
      groups: 
        - system:bootstrappers 
        - system:nodes 
  mapUsers: | 
    - userarn: arn:aws:iam::11122223333:user/designated_user 
      username: designated_user 
      groups: 
        - system:masters

Remarque : Le username dans l’exemple ci-dessus est le nom que Kubernetes utilise pour renvoyer à l’entité IAM indiquée en userarn.

8.    Pour appliquer le nouveau ConfigMap à la configuration RBAC du cluster, exécutez la commande suivante :

kubectl apply -f aws-auth.yaml

9.    Pour modifier à nouveau la configuration de l’interface en ligne de commande AWS afin d’utiliser les informations d’identification du designated_user, exécutez la commande suivante :

aws configure

10.    Pour vérifier que designated_user a accès au cluster, exécutez la commande suivante :

kubectl get pods

Si tout est configuré correctement, vous n'obtenez pas de message d'erreur d'absence d'autorisation, et la sortie doit répertorier tous les pods s'exécutant dans l'espace de noms par défaut. Si le résultat montre qu'aucune ressource n'a été trouvée, cela signifie qu'aucun pod n'est en cours d'exécution.

Ajout d'un utilisateur désigné (designated_user) à la ConfigMap si cluster_creator est un rôle IAM

Dans les étapes précédentes, vous avez utilisé les informations d'identification de cluster_creator pour fournir l'accès à designated_user. Toutefois, si le cluster a été créé par un rôle IAM et non pas par un utilisateur IAM, vous ne pouvez pas utiliser d'informations d'identification. Dans ce cas, vous devez assumer le rôle IAM qui a créé le cluster pour fournir l'accès à designated_user. Si le créateur du cluster n'est pas un rôle IAM, vous n'avez pas besoin d'effectuer les étapes suivantes.

Pour assumer le rôle IAM et modifier la ConfigMap aws-auth sur le cluster afin que vous puissiez fournir l'accès à designated_user, procédez comme suit :

1.    Pour afficher les détails d’utilisateur IAM du designated_user, exécutez la commande suivante :

aws sts get-caller-identity

2.    Pour vérifier que designated_user a accès au cluster, exécutez la commande suivante :

kubectl get pods

Le résultat affiche le message d'erreur suivant : « error: You must be logged in to the server (Unauthorized) » (« Erreur : vous devez être connecté au serveur [non autorisé]. ». Cette erreur signifie que l'utilisateur sélectionné ne dispose pas de l'autorisation pour configurer le cluster Amazon EKS.

3.    Pour autoriser le designated_user à assumer le rôle de cluster_creator, exécutez la commande suivante :

aws sts assume-role --role-arn arn:aws:iam:11122223333:role/cluster_creator --role-session-name test

Le résultat indique les informations d'identification IAM temporaires pour le designated_user, qui utilise le rôle assumé de cluster_creator.

4.    Utilisez les informations d’identification IAM temporaires pour définir les variables d’environnement AWS_ACCESS_KEY_ID, AWS_SESSION_TOKEN et AWS_SECRET_ACCESS_KEY. Par exemple :

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SESSION_TOKEN=EXAMPLETOKEN
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

L'interface de ligne de commande (CLI) AWS priorise désormais les informations d'identification définies dans les variables d'environnement et les utilise pour effectuer des appels aux services AWS.

5.    Pour vérifier que l’interface de ligne de commande AWS utilise le rôle assumé pour cluster_creator, exécutez la commande suivante :

aws sts get-caller-identity

6.    Pour permettre à designated_user d'accéder au cluster, ajoutez la section mapUsers à votre fichier aws-auth.yaml. Consultez l'exemple de fichier aws-auth.yaml suivant dans Gestion des utilisateurs ou des rôles IAM de votre cluster :

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

7.    Dans votre fichier aws-auth.yaml, ajoutez mapRoles. Par exemple :

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::11122223333:role/designated_role
      username: designated_role
      groups:
        - system:masters

Remarque : Le username dans l’exemple ci-dessus est le nom que Kubernetes utilise pour renvoyer à l’entité IAM indiquée en userarn.

8.    Ajoutez designated_user au fichier aws-auth.yaml, puis enregistrez vos modifications.

9.    Pour appliquer la nouvelle configuration à la configuration RBAC du cluster Amazon EKS, exécutez la commande suivante :

kubectl apply -f aws-auth-cm.yml

10.    Pour annuler les variables d’environnement suivantes, exécutez les commandes suivantes :

unset AWS_ACCESS_KEY_ID
unset AWS_SESSION_TOKEN
unset AWS_SECRET_ACCESS_KEY

11.    Pour afficher les détails d’utilisateur IAM du designated_user, exécutez la commande suivante :

aws sts get-caller-identity

12.    Pour vérifier que designated_user a accès au cluster, exécutez la commande suivante :

kubectl get pods

Si tout est configuré correctement, vous n'obtenez pas de message d'erreur d'absence d'autorisation, et la sortie doit répertorier tous les pods s'exécutant dans l'espace de noms par défaut. Si le résultat montre qu'aucune ressource n'a été trouvée, cela signifie qu'aucun pod n'est en cours d'exécution.

Remarque : si vous utilisez eksctl, consultez la solution dans la section relative à la gestion des utilisateurs et rôles IAM sur le site Web Weaveworks.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?