Résoudre l'erreur d'accès aux objets Kubernetes sur AWS EKS

En utilisant Amazon Elastic Kubernetes Service (EKS), avez-vous déjà rencontré le message d'erreur "Your current user or role does not have access to Kubernetes objects on this EKS cluster" ? Cette erreur peut être déconcertante, surtout lorsqu'on vous indique que vous n'avez pas les droits alors que vous êtes super-administrateur global. Dans cet article, nous décryptons la signification de cette erreur et vous proposons un guide pas à pas pour la résoudre.

access

Exemple issu de l'interface de la console AWS

AWS

Exemple depuis la CLI kubectl exécutée sur un cluster EKS

Comprendre le problème

Pour visualiser les ressources Kubernetes dans la console AWS Management Console, l'utilisateur ou le rôle AWS IAM doit être mappé au aws-auth``ConfigMap du cluster EKS. Ce mappage est essentiel : lorsqu'une personne crée un cluster EKS, son utilisateur ou rôle IAM se voit automatiquement attribuer les permissions system:masters dans la configuration RBAC (Role-Based Access Control) du cluster. Cela lui permet de visualiser les ressources Kubernetes via la console EKS et de modifier le aws-auth``ConfigMap au sein de Kubernetes, accordant ainsi à d'autres utilisateurs ou rôles AWS la possibilité d'interagir avec le cluster.

Par défaut, l'utilisateur ou le rôle AWS IAM qui crée le cluster dispose d'un accès exclusif à la console AWS et à l'outil kubectl. Contrairement à ce que l'on pourrait croire, si vous ne parvenez pas à voir les éléments dans la console AWS, c'est en raison de l'absence d'une configuration de mappage correcte entre les droits RBAC Kubernetes et IAM dans le aws-auth``ConfigMap.

Comment résoudre le problème

Identifier le créateur du cluster

Vous devez identifier le créateur du cluster EKS. Une approche consiste à consulter les journaux AWS CloudTrail. AWS CloudTrail enregistre tous les appels d'API AWS, y compris ceux effectués via la console AWS Management Console, les SDK et la CLI. Ainsi, si CloudTrail est activé sur votre compte, vous devriez pouvoir retrouver l'identité de l'utilisateur ayant créé le cluster EKS.

Voici la marche à suivre :

Connectez-vous à la console AWS Management Console.
Accédez à CloudTrail depuis la console AWS Management Console : saisissez 'CloudTrail' dans la barre de recherche des services et sélectionnez-le dans le menu déroulant.
Dans le dashboard CloudTrail, sélectionnez 'Event history' dans la barre latérale.
Sur la page Event history, des filtres apparaissent en haut. Définissez le filtre 'Event name' sur 'CreateCluster', l'appel d'API qui crée un nouveau cluster EKS.
Si vous connaissez le nom du cluster EKS, vous pouvez également filtrer par 'Resource name' et indiquer le nom du cluster.
Une fois les filtres appliqués, vous devriez voir une liste d'événements 'CreateCluster'. Cliquez sur l'événement pour en consulter les détails. Le champ 'User name' correspond à l'identité de l'utilisateur ayant créé le cluster EKS.

Notez que cette approche ne fonctionne que si CloudTrail était activé dans le compte AWS au moment de la création du cluster EKS, ce qui est généralement le cas par défaut. Si CloudTrail n'était pas activé à ce moment-là, il sera impossible de déterminer le créateur du cluster EKS. Dans cette hypothèse, mieux vaut solliciter l'aide d'un administrateur AWS, d'un DevOps, d'un SRE ou d'un expert du domaine au sein de votre organisation, qui pourra vous orienter pour identifier le créateur du cluster.

Identifier l'ARN de l'identité IAM

Identifiez l'utilisateur ou le rôle IAM que vous utilisez pour accéder à la console. Vous pouvez obtenir l'ARN de l'identité IAM en exécutant la commande AWS CLI suivante :

aws sts get-caller-identity --query Arn

Ajouter un utilisateur ou un rôle IAM au ConfigMap aws-auth

Pour accorder l'accès à votre cluster EKS, le créateur du cluster peut ajouter un utilisateur ou un rôle IAM au aws-auth``ConfigMap. L'utilisateur ou le rôle peut alors interagir avec le cluster sans friction. Voici des exemples illustrant la procédure avec kubectl ou eksctl :

kubectl

Récupérez le ConfigMap actuel :

kubectl get -n kube-system configmap/aws-auth -o yaml

Cette commande affiche le aws-auth``ConfigMap actuel. Il devrait ressembler à ceci :

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

Pour ajouter un nouvel utilisateur ou rôle IAM, modifiez ce YAML afin d'inclure le nouvel utilisateur ou rôle sous mapRoles ou mapUsers. Voici un 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/YourNewRole
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:masters
  mapUsers: |
    - userarn: arn:aws:iam::11122223333:user/YourNewUser
      username: YourNewUser
      groups:
        - system:masters

Dans cet exemple, remplacez arn:aws:iam::11122223333:role/YourNewRole par l'ARN de votre nouveau rôle IAM, et arn:aws:iam::11122223333:user/YourNewUser par l'ARN de votre nouvel utilisateur IAM. Remplacez également YourNewUser par le nom du nouvel utilisateur IAM.

3. Une fois les modifications effectuées, appliquez le nouveau ConfigMap avec la commande suivante :

kubectl apply -f aws-auth-configmap.yaml

Dans la commande ci-dessus, remplacez aws-auth-configmap.yaml par le nom du fichier de votre ConfigMap modifié.

eksctl

Pour ajouter un utilisateur IAM :

eksctl create iamidentitymapping --region region-code --cluster cluster-name --arn arn:aws:iam::11122223333:user/YourNewUser --group system:masters

Pour ajouter un rôle IAM :

eksctl create iamidentitymapping --region region-code --cluster cluster-name --arn arn:aws:iam::11122223333:role/YourNewRole --group system:masters

Dans les exemples ci-dessus :

Remplacez region-code par le code de la région AWS (par exemple, us-west-2).
Remplacez cluster-name par le nom du cluster EKS.
Remplacez arn:aws:iam::11122223333:role/YourNewRole par l'ARN du nouveau rôle IAM, et arn:aws:iam::11122223333:user/YourNewUser par l'ARN du nouvel utilisateur IAM.
Remplacez system:masters par le groupe Kubernetes approprié. Reportez-vous à la section Groupes Kubernetes ci-dessous pour plus de détails.

Groupes Kubernetes

Dans Kubernetes, un groupe est un ensemble d'utilisateurs partageant les mêmes permissions. Voici quelques-uns des groupes par défaut :

system:authenticated: regroupe tous les utilisateurs authentifiés.
system:unauthenticated: regroupe tous les utilisateurs non authentifiés.
system:masters: ce groupe dispose d'un accès complet au cluster et peut y effectuer toute action. Il est généralement associé aux rôles de créateur de cluster.
system:serviceaccounts:<namespace>: regroupe tous les comptes de service du namespace <namespace>.

Le groupe system:masters donne un accès complet au cluster, avec la possibilité de créer, lire, mettre à jour et supprimer toute ressource. Soyez donc vigilant lorsque vous y ajoutez des utilisateurs ou des rôles. Seuls des utilisateurs ou rôles de confiance devraient y figurer, et il convient de toujours appliquer le principe du moindre privilège. Ce principe consiste à n'accorder à un utilisateur ou un rôle que les niveaux d'accès ou les permissions strictement nécessaires à l'accomplissement de ses tâches. Il vise à limiter le risque d'activité malveillante ou de compromission en réduisant la surface d'attaque.

Problèmes d'accès persistants

Si les difficultés persistent après la mise à jour du aws-auth ConfigMap, cela peut tenir à une politique IAM non actualisée ou à un RBAC Kubernetes qui ne reconnaît pas les modifications. Comme indiqué précédemment, les permissions IAM sont distinctes des permissions Kubernetes, et les deux doivent être correctement configurées pour que l'utilisateur puisse interagir avec l'API Kubernetes.

Voici les étapes de dépannage à suivre :

Vérifiez que le ConfigMap aws-auth dans le namespace kube-system a bien été mis à jour :

kubectl -n kube-system describe configmap aws-auth

La sortie devrait afficher l'utilisateur ou le rôle IAM sous mapRoles ou mapUsers. Dans le cas contraire, le ConfigMap n'a pas été mis à jour correctement ou est mal formé. Un ConfigMap mal formé dans Kubernetes équivaut à un ConfigMap supprimé, ce qui peut bloquer l'accès à tout le monde, à l'exception du créateur du cluster. Soyez donc prudent et effectuez un linting YAML à l'aide d'outils tels que YAML Lint pour vérifier votre configuration YAML.

2. Vérifiez que l'utilisateur ou le rôle IAM correspond bien à celui qui a été ajouté au aws-auth``ConfigMap. Une faute de frappe dans l'ARN de l'utilisateur ou du rôle IAM est un problème courant.

3. Assurez-vous que l'utilisateur ou le rôle IAM dispose des permissions AWS nécessaires. Pour cela, vérifiez les politiques IAM associées à l'utilisateur ou au rôle. Si vous devez gérer le cluster EKS et ses nœuds, les politiques AmazonEKSClusterPolicy et AmazonEKSWorkerNodePolicy accorderont les permissions requises. Reportez-vous au guide AWS managed policies for Amazon Elastic Kubernetes Service pour plus de détails.

Vous pouvez également créer une politique IAM personnalisée incluant des permissions en lecture seule pour les actions eks:Describe* et eks:List*, ce qui permet à l'utilisateur ou au rôle de consulter les informations relatives aux ressources EKS.

4. Vérifiez que l'utilisateur Kubernetes et les groupes mappés à l'entité IAM disposent des permissions nécessaires dans Kubernetes. Pour cela, consultez le guide utilisateur Kubernetes RBAC roles and bindings.

Pensez à toujours appliquer le principe du moindre privilège lors de l'attribution des permissions, aussi bien dans AWS que dans Kubernetes. N'accordez que les permissions strictement nécessaires à l'utilisateur ou au rôle pour accomplir ses tâches.

Il est également important de souligner que si le aws-auth ConfigMap est supprimé, contient des erreurs de syntaxe ou est mal formaté, tous les utilisateurs perdront l'accès, à l'exception du créateur du cluster. Ce dernier est alors la seule personne en mesure de rectifier la situation.

Évoluer dans le paysage complexe des erreurs AWS EKS représente indéniablement un défi, mais avec la bonne combinaison de connaissances, d'outils et de bon sens pratique, ces obstacles se franchissent. Comprendre l'articulation subtile entre les identités IAM et Kubernetes constitue une pièce essentielle du puzzle, au même titre que la maîtrise des subtilités du aws-auth ConfigMap. J'espère que ce guide vous sera utile, que vous soyez un habitué d'EKS ou un nouveau venu sur la plateforme.