Comment puis-je corriger l’erreur « Vous devez être connecté au serveur (non autorisé) » lorsque je me connecte au serveur d’API Amazon EKS ?

Lecture de 10 minute(s)

J’utilise les commandes kubectl pour me connecter au serveur d’interface de programmation d’application (API) Amazon Elastic Kubernetes Service (Amazon EKS). J’ai reçu le message « erreur : vous devez être connecté au serveur (non autorisé) ».

Brève description

Cette erreur se produit lorsque l’entité AWS Identity and Access Management (IAM) configurée dans kubectl n’est pas authentifiée par Amazon EKS.

Vous êtes authentifié et autorisé à accéder à votre cluster Amazon EKS en fonction de l’entité IAM (utilisateur ou rôle) que vous utilisez. Par conséquent, vérifiez les points suivants :

Vous avez configuré l’outil kubectl pour utiliser votre utilisateur ou rôle IAM.
Votre entité IAM est mappée au fichier aws-auth ConfigMap.

Pour résoudre ce problème, vous devez suivre les étapes décrites dans l’une des sections suivantes en fonction de votre cas d’utilisation :

Vous êtes le créateur du cluster.
Vous n’êtes pas le créateur du cluster.

Résolution

Si vous obtenez des erreurs lors de l’exécution des commandes de l’interface de la ligne de commande AWS (AWS CLI), vérifiez que vous exécutez bien une version récente d’AWS CLI.

Vous êtes le créateur du cluster.

Vous êtes le créateur du cluster si votre entité IAM a été utilisée pour créer le cluster Amazon EKS.

1. Exécutez la requête suivante dans Amazon CloudWatch Log Insights pour identifier l’ARN du créateur du cluster :

Sélectionnez d’abord le groupe de journaux de votre cluster Amazon EKS (exemple : /aws/eks/my-cluster/cluster). Exécutez ensuite la requête suivante :

fields @logstream, @timestamp, @message
| sort @timestamp desc
| filter @logStream like /authenticator/
| filter @message like "username=kubernetes-admin"
| limit 50

**Remarque :**assurez-vous d’avoir activé les journaux d’authentification Amazon EKS.

Cette requête renvoie l’entité IAM qui est mappée en tant que créateur du cluster :

@message
time="2022-05-26T18:55:30Z" level=info msg="access granted" arn="arn:aws:iam::123456789000:user/testuser" client="127.0.0.1:57586" groups="[system:masters]" method=POST path=/authenticate uid="aws-iam-authenticator:123456789000:AROAFFXXXXXXXXXX" username=kubernetes-admin

2. Assurez-vous d’avoir configuré l’interface de la ligne de commande AWS avec l’entité IAM du créateur du cluster. Pour voir si l’entité IAM est configurée pour l’interface de la ligne de commande AWS dans votre environnement shell, exécutez la commande suivante :

$ aws sts get-caller-identity

Vous pouvez également exécuter cette commande à l’aide d’un profil spécifique :

$ aws sts get-caller-identity --profile MY-PROFILE

La sortie renvoie le nom Amazon Resource Name (ARN) de l’entité IAM configurée pour l’interface AWS CLI.

Exemple :

{
    "UserId": "XXXXXXXXXXXXXXXXXXXXX",
    "Account": "XXXXXXXXXXXX",
    "Arn": "arn:aws:iam::XXXXXXXXXXXX:user/testuser"
}

Vérifiez que l’entité IAM renvoyée correspond à l’entité IAM du créateur du cluster. Si l’entité IAM renvoyée n’est pas celle du créateur du cluster, mettez à jour la configuration de l’AWS CLI pour utiliser l’entité IAM du créateur de cluster.

3. Mettez à jour ou générez le fichier kubeconfig à l’aide de la commande suivante :

$ aws eks update-kubeconfig --name eks-cluster-name --region aws-region

Remarque :

Remplacez eks-cluster-name par le nom de votre cluster.
Remplacez aws-region par le nom de votre Région AWS.

Pour spécifier un profil d’AWS CLI, exécutez la commande suivante :

$ aws eks update-kubeconfig --name eks-cluster-name —region aws-region —profile my-profile

Remarque :

Remplacez eks-cluster-name par le nom de votre cluster.
Remplacez aws-region par le nom de votre région.
Remplacez my-profile par le nom de votre profil.

4. Pour vérifier que le fichier kubeconfig est mis à jour, exécutez la commande suivante :

$ kubectl config view --minify

5. Pour vérifier que votre entité IAM est authentifiée et que vous pouvez accéder à votre cluster EKS, exécutez la commande suivante :

$ kubectl get svc

Exemple de sortie :

NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes      ClusterIP   10.100.0.1     <none>        443/TCP   77d

Vous n’êtes pas le créateur du cluster.

Vous n’êtes pas le créateur du cluster si votre entité IAM n’a pas été utilisée pour créer le cluster. Dans ce cas, vous devez mapper votre entité IAM au fichier aws-auth ConfigMap pour autoriser l’accès au cluster.

1. Assurez-vous d’avoir configuré l’AWS CLI avec votre entité IAM. Pour voir l’entité IAM configurée pour l’AWS CLI dans votre environnement shell, exécutez la commande suivante :

$ aws sts get-caller-identity

Vous pouvez également exécuter cette commande à l’aide d’un profil spécifique :

$ aws sts get-caller-identity --profile my-profile

La sortie renvoie l’ARN de l’entité IAM configurée pour l’AWS CLI.

Exemple :

{
    "UserId": "XXXXXXXXXXXXXXXXXXXXX",
    "Account": "XXXXXXXXXXXX",
    "Arn": "arn:aws:iam::XXXXXXXXXXXX:user/testuser"
}

Vérifiez que l’entité IAM renvoyée est bien la vôtre. Si l’entité IAM renvoyée n’est pas celle utilisée pour interagir avec votre cluster, mettez d’abord à jour la configuration de l’AWS CLI pour utiliser l’entité IAM appropriée. Ensuite, réessayez d’accéder à votre cluster à l’aide de kubectl. Si le problème persiste, passez à l’étape 2.

2. Si l’entité IAM renvoyée n’est pas le créateur du cluster, ajoutez votre entité IAM au fichier aws-auth ConfigMap. Cela permet d’autoriser l’entité IAM à accéder au cluster.

Seul l’administrateur du cluster peut modifier le fichier aws-auth ConfigMap. Par conséquent, effectuez l’une des opérations suivantes :

Pour accéder au cluster à l’aide de l’entité IAM du créateur du cluster, suivez les instructions de la section Vous êtes le créateur.
Demandez à l’administrateur du cluster d’effectuer cette action.

Vérifiez si l’entité IAM figure dans le fichier aws-auth ConfigMap en exécutant la commande suivante :

eksctl get iamidentitymapping --cluster cluster-name

-ou-

kubectl describe configmap aws-auth -n kube-system

Si l’entité IAM se trouve dans le fichier aws-auth ConfigMap, vous pouvez passer à l’étape 3.

Mappez automatiquement votre entité IAM en exécutant la commande suivante :

eksctl create iamidentitymapping \
    --cluster $CLUSTER-NAME \
    --region $REGION \
    --arn arn:aws:iam::XXXXXXXXXXXX:user/testuser \
    --group system:masters \
    --no-duplicate-arns \
    --username admin-user1

Vous pouvez également mapper manuellement votre entité IAM en modifiant le fichier aws-auth ConfigMap :

$ kubectl edit configmap aws-auth --namespace kube-system

Pour ajouter un utilisateur IAM, ajoutez l’ARN de l’utilisateur IAM à mapUsers.

Exemple :

mapUsers: |
  - userarn: arn:aws:iam::XXXXXXXXXXXX:user/testuser
    username: testuser
    groups:
      - system:masters

Pour ajouter un rôle IAM, ajoutez l’ARN du rôle IAM à mapRoles.

Exemple :

mapRoles: |
  - rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testrole
    username: testrole
    groups:
      - system:masters

Important :

Le rôle IAM doit être mappé sans le chemin. Pour en savoir plus sur les exigences relatives au chemin rolearn, développez la section Le fichier aws-auth ConfigMap n’accorde pas l’accès au cluster dans l’article Résolution des problèmes liés à la gestion des identités et des accès.
Pour spécifier rolearn pour un rôle IAM AWS IAM Identity Center (successeur d’AWS Single Sign-On), supprimez le chemin « /aws-reserved/sso.amazonaws.com/REGION » de l’ARN du rôle. Sinon, l’entrée dans le fichier ConfigMap ne peut pas vous autoriser en tant qu’utilisateur valide.
Le groupe system:masters autorise les super utilisateurs à accéder à n’importe quelle ressource pour y effectuer des actions. Pour plus d’informations, consultez Rôles par défaut et liaisons de rôles. Pour restreindre l’accès de cet utilisateur, vous pouvez créer un rôle Amazon EKS et une ressource de liaison de rôles. Pour obtenir un exemple de restriction d’accès pour les utilisateurs qui consultent des ressources dans la console Amazon EKS, suivez les étapes 2 et 3 de la section Autorisations requises.

3. Mettez à jour ou générez le fichier kubeconfig en exécutant la commande ci-dessous. Assurez-vous que l’interface de la ligne de commande AWS est configurée avec l’entité IAM renvoyée à l’étape 1.

$ aws eks update-kubeconfig --name eks-cluster-name --region aws-region

Remarque :

Remplacez eks-cluster-name par le nom de votre cluster.
Remplacez aws-region par le nom de votre Région AWS.

Vous pouvez également exécuter cette commande à l’aide d’un profil spécifique :

$ aws eks update-kubeconfig --name eks-cluster-name —region aws-region —profile my-profile

Remarque :

Remplacez eks-cluster-name par le nom de votre cluster.
Remplacez aws-region par le nom de votre Région AWS.
Remplacez my-profile par le nom de votre profil.

4. Pour vérifier que le fichier kubeconfig est mis à jour, exécutez la commande suivante :

$ kubectl config view --minify

5. Pour vérifier si votre utilisateur ou rôle IAM est authentifié, essayez à nouveau d’accéder au cluster. Par exemple, vous pouvez exécuter la commande suivante pour vérifier si l’erreur est résolue :

$ kubectl get svc

Exemple de sortie :

NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes      ClusterIP   10.100.0.1     <none>        443/TCP   77d

Conseils de dépannage supplémentaires

Si l’erreur persiste, suivez les conseils de dépannage ci-dessous pour identifier la cause du problème.

Lorsque vous exécutez une commande kubectl, une demande est envoyée au serveur d’API du cluster Amazon EKS. L’application d’authentification Amazon EKS essaie ensuite d’authentifier cette demande. Par conséquent, vérifiez les journaux de l'application d’authentification EKS dans CloudWatch afin d’identifier le problème.

1. Assurez-vous d’avoir activé la journalisation pour votre cluster Amazon EKS.

2. Ouvrez CloudWatch Log Insights.

3. Sélectionnez le groupe de journaux de votre cluster. Exemple : « /aws/eks/example-cluster/cluster ».

4. Exécutez la requête suivante :

fields @timestamp, @message
| filter @logStream like /authenticator/
| sort @timestamp desc
| limit 1000

Identifiez les lignes de journal correspondant au même intervalle de temps que celui pendant lequel vous avez reçu l’erreur en exécutant les commandes kubectl. Vous trouverez de plus amples informations sur la cause de l’erreur dans les journaux de l’application d’authentification Amazon EKS.

Si le problème est dû à l’utilisation d’une entité IAM incorrecte pour kubectl, examinez la configuration du fichier kubectl kubeconfig et de l’AWS CLI. Assurez-vous d’utiliser le bon rôle IAM. Supposons, par exemple, que les journaux ressemblent à ce qui suit. Cette sortie signifie que l’entité IAM utilisée par kubectl ne peut pas être validée. Assurez-vous que l’entité IAM utilisée par kubectl existe dans IAM et que l’accès programmatique de l’entité est activé.

time="2022-12-26T20:46:48Z" level=warning msg="access denied" client="127.0.0.1:43440" error="sts getCallerIdentity failed: error from AWS (expected 200, got 403). Body: {\"Error\":{\"Code\":\"InvalidClientTokenId\",\"Message\":\"The security token included in the request is invalid.\",\"Type\":\"Sender\"},\"RequestId\":\"a9068247-f1ab-47ef-b1b1-cda46a27be0e\"}" method=POST path=/authenticate

Si le problème est dû au fait que votre entité IAM n’est pas mappée ou est incorrectement mappée dans aws-auth ConfigMap, examinez le fichier aws-auth ConfigMap. Assurez-vous que l’entité IAM est correctement mappée et qu’elle répond aux exigences répertoriées dans la section Vous n’êtes pas le créateur du cluster. Dans ce cas, les journaux de l'application d’authentification EKS se présentent comme suit :

time="2022-12-28T15:37:19Z" level=warning msg="access denied" arn="arn:aws:iam::XXXXXXXXXX:role/admin-test-role" client="127.0.0.1:33384" error="ARN is not mapped" method=POST path=/authenticate

Si le fichier aws-auth ConfigMap a été mis à jour et que vous avez perdu l’accès au cluster, vous pouvez accéder au cluster à l’aide de l’entité IAM du créateur du cluster. Cela est dû au fait que le créateur du cluster n’a pas besoin d’être mappé dans le fichier aws-auth ConfigMap.
Si l’entité IAM du créateur du cluster a été supprimée, créez à nouveau le même utilisateur ou rôle IAM. Accédez ensuite au cluster à l’aide de cette entité IAM en suivant les étapes décrites dans la section Vous êtes le créateur du cluster.
Si le créateur du cluster est un rôle IAM créé pour un utilisateur SSO qui a été supprimé, vous ne pouvez pas de nouveau créer ce rôle IAM. Dans ce cas, contactez AWS Support pour obtenir de l’aide.