Comment puis-je fournir un accès et des rôles à d’autres utilisateurs après la création d’un cluster dans Amazon EKS ?

Dernière mise à jour : 28/09/2020

Lorsque j’essaie d’accéder au service Amazon Elastic Kubernetes (Amazon EKS) via des commandes kubectl, je reçois les erreurs d’autorisation suivantes : « Erreur : vous devez être connecté au serveur (non autorisé) ». Comment puis-je résoudre cette erreur ?

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. Le ConfigMap permet à d’autres entités IAM, telles que des utilisateurs et des rôles, d’accéder au cluster Amazon EKS.

Remarque : Si vous utilisez eksctl, tenez compte de la résolution dans Manage IAM users and roles (Gérer les utilisateurs et les rôles IAM) sur le site Web Weaveworks.

Solution

Avant d’effectuer les étapes suivantes, identifiez l’utilisateur ou le rôle IAM (le créateur du cluster) qui a un accès master à la configuration de votre cluster Amazon EKS. Identifiez également l’utilisateur IAM auquel le créateur du cluster donnera les autorisations 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.

Remarque : Dans les étapes suivantes, le créateur du cluster est cluster_creator, et l’utilisateur qui n’a pas actuellement accès au cluster mais qui a besoin d’un accès est designated_user.

Ajouter designated_user au ConfigMap si cluster_creator est un utilisateur IAM

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

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 le cluster_creator a accès au cluster, exécutez la commande suivante :

kubectl get pods

Vous ne devriez plus obtenir de message d'erreur d'autorisation. Le résultat doit répertorier tous les pods en cours d'exécution 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 fournir l’accès au cluster au designated_user, ajoutez la section mapUsers à votre fichier aws-auth.yaml. Consultez l’exemple suivant de fichier aws-auth.yaml dans Gestion des utilisateurs ou des rôles IAM pour 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 le designated_user a accès au cluster, exécutez la commande suivante :

kubectl get pods

Vous ne devriez plus obtenir de message d'erreur d'autorisation. Le résultat doit répertorier tous les pods en cours d'exécution 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.

Ajouter designated_user au ConfigMap si le 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 au lieu d’un utilisateur IAM, vous ne pourrez 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 le fichier 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 confirmer que le 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 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 fournir l’accès au cluster au designated_user, ajoutez la section mapUsers à votre fichier aws-auth.yaml. Consultez l’exemple suivant de fichier aws-auth.yaml dans Gestion des utilisateurs ou des rôles IAM pour 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 mapUsers. 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.    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 confirmer que le designated_user a accès au cluster, exécutez la commande suivante :

kubectl get pods

Vous ne devriez plus obtenir de message d'erreur d'autorisation. Le résultat doit répertorier tous les pods en cours d'exécution 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.


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


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