Comment résoudre l'erreur « Votre utilisateur ou votre rôle actuel n'a pas accès aux objets Kubernetes de ce cluster EKS » dans Amazon EKS ?
L'erreur suivante s'affiche dans Amazon Elastic Kubernetes Service (Amazon EKS) : « Votre utilisateur ou rôle actuel n'a pas accès aux objets Kubernetes de ce cluster EKS. »
Brève description
Cette erreur peut s’afficher lorsque vous utilisez la console de gestion AWS avec une identité (utilisateur ou rôle) Gestion des identités et des accès AWS (AWS IAM). L’erreur indique que l’utilisateur ou le rôle IAM ne dispose pas des autorisations RBAC requises pour accéder à l’API Kubernetes. Pour afficher les ressources Kubernetes sur la console de gestion AWS, votre utilisateur ou votre identité AWS IAM doit correspondre à aws-auth ConfigMap dans votre cluster Amazon EKS. Pour en savoir plus, consultez la page Utilisation de l’autorisation RBAC du site Web Kubernetes.
Lorsque vous créez un cluster Amazon EKS, les autorisations system:masters sont accordées automatiquement à votre identité IAM dans la configuration RBAC du cluster. Cela vous permet de visualiser les ressources Kubernetes via la console Amazon EKS. Il vous permet également de modifier le fichier de configuration aws-auth ConfigMap dans Kubernetes et d’autoriser d’autres utilisateurs ou rôles AWS à interagir avec le cluster. La console de gestion AWS utilise IAM pour les autorisations, et le cluster EKS utilise le système Kubernetes RBAC. Dans la mesure où le ConfigMap aws-auth du cluster associe les identités IAM aux identités RBAC du cluster, le ConfigMap aws-auth associe les identités IAM aux identités Kubernetes.
Résolution
Prérequis
Collectez les informations suivantes en fonction de votre situation.
Utilisateur ou rôle non administrateur
Si vous n’êtes pas un utilisateur ou si n’avez pas un rôle IAM d’administrateur de cluster et que vous avez besoin de visibilité sur la console Amazon EKS, procédez comme suit :
- Obtenez l’ARN d’identité IAM de l’utilisateur de la console de gestion AWS. AWS IAM Authenticator n’autorise pas de chemin dans le rôle ARN utilisé dans le ConfigMap. S’il s’agit d’un rôle IAM, utilisez le format ARN suivant :
arn:aws:iam::111122223333:role/example
Remarque : n’utilisez pas le format suivant, car il contient des informations inutiles :
arn:aws:iam::111122223333:role/my-team/developers/example - Fournissez l’ARN à l’administrateur de votre cluster et demandez-lui de vous ajouter au ConfigMap aws-auth.
Remarque : Consultez la section Identifier l'ARN d'identité IAM de l'utilisateur de la console de gestion AWS pour savoir comment accéder à votre ARN.
Utilisateur ou rôle de créateur de cluster ou d'administrateur de cluster
Si vous êtes le créateur ou l'administrateur du cluster, utilisez l'outil kubectl ou l'outil eksctl pour gérer l’aws-auth ConfigMap.
Remarque : Par défaut, le groupe system:masters est lié au clusterrole nommé cluster-admin. Ce clusterrole utilise le caractère générique (*) pour les ressources et les verbes dans sa PolicyRule. Cela signifie que tout utilisateur assigné au groupe system:masters bénéficie d’un accès complet à toutes les ressources Kubernetes du cluster.
Consultez la section Identifier le créateur du cluster pour obtenir des instructions sur la manière dont les créateurs et les administrateurs de cluster peuvent identifier leur statut d’administrateur.
Identifier l’ARN d’identité IAM de l’utilisateur de la console de gestion AWS
Identifiez l’utilisateur ou le rôle IAM que vous utilisez pour accéder à la console. Cette identité IAM peut être différente de celle que vous utilisez avec l’interface de la ligne de commande AWS (AWS CLI). Vérifiez que l’utilisateur ou le rôle IAM dispose des autorisations requises pour afficher les nœuds et les charges de travail pour tous les clusters dans la console de gestion AWS. Utilisez ensuite l’une des options suivantes pour accéder à l’ARN.
**Remarque :**Si des erreurs surviennent lorsque vous exécutez des commandes AWS CLI, consultez l’article Résoudre les erreurs AWS CLI. Vérifiez également que vous utilisez la version la plus récente d’AWS CLI.
AWS CLI
Si vous avez accès à l’utilisateur ou au rôle IAM depuis AWS CLI, exécutez la commande suivante :
aws sts get-caller-identity --query Arn
CloudShell
Si vous ne disposez pas de l’accès AWS CLI, exécutez la commande suivante depuis AWS CloudShell :
aws sts get-caller-identity --query Arn
La sortie ressemble à ce qui suit :
"arn:aws:iam::111122223333:role/testrole"
-ou-
"arn:aws:iam::111122223333:user/testuser"
Remarque :
- s’il s’agit d’un ARN de rôle IAM, assurez-vous que le format est semblable au format ARN de la section Prérequis.
- Si l’ARN inclut un rôle assumé, vous devez obtenir l’ARN du rôle. Par exemple, le rôle ARN assumé de arn:aws:sts::123456:assumed-role/MyRole/aadams est associé au rôle ARN arn:aws:sts::123456:role/MyRole. Vérifiez cette valeur dans la console IAM.
Identifier le créateur du cluster
Pour trouver le créateur du cluster ou le rôle d’administrateur disposant des autorisations principales pour configurer votre cluster, recherchez l’appel d’API CreateCluster dans AWS CloudTrail. Consultez ensuite la section userIdentity de l’appel d’API. Si vous trouvez le nom du créateur du cluster dans CloudTrail, mais que celui-ci est supprimé, recréez un nouvel utilisateur ou un nouveau rôle IAM portant le même nom. Dans la mesure où cette nouvelle entité IAM possède le même ARN que le créateur du cluster d’origine, elle hérite du même accès administrateur au cluster.
Remarque : CloudTrail ne fournit que 90 jours d’historique.
Ajouter le nouvel utilisateur ou le nouveau rôle IAM au Kubernetes RBAC
Pour ajouter le nouvel utilisateur ou le nouveau rôle IAM au Kubernetes RBAC, commencez par configurer AWS CLI pour utiliser le créateur de cluster IAM. Pour vérifier qu’AWS CLI est correctement configurée avec l’entité IAM, exécutez la commande suivante :
$ aws sts get-caller-identity
La sortie renvoie l’ARN de l’utilisateur ou du rôle IAM. Exemple :
{ "UserId": "XXXXXXXXXXXXXXXXXXXXX", "Account": "XXXXXXXXXXXX", "Arn": "arn:aws:iam::XXXXXXXXXXXX:user/testuser" }
Ensuite, utilisez kubectl ou eksctl pour modifier le ConfigMap aws-auth.
kubectl
-
Pour utiliser kubectl afin de modifier le ConfigMap aws-auth, exécutez la commande kubectl suivante pour accéder au cluster :
$ kubectl edit configmap aws-auth -n kube-system
La console affiche le ConfigMap actuel. Si vous ne parvenez pas à vous connecter au cluster, essayez de mettre à jour votre fichier kubeconfig. Dans la mesure où l’identité qui crée le cluster dispose toujours d’un accès au cluster, vous devez exécuter la commande avec une identité IAM ayant accès au cluster :
aws eks update-kubeconfig --region region_code --name my_cluster
Remarque : remplacez region_code par le code de région AWS de votre cluster EKS et my_cluster par le nom de votre cluster EKS.
Les commandes kubectl doivent se connecter au point de terminaison du serveur EKS. Si le point de terminaison du serveur API est public, vous devez disposer d’un accès Internet pour vous connecter au point de terminaison. Si le point de terminaison du serveur API est privé, connectez-vous au point de terminaison du serveur EKS depuis l’intérieur du cloud privé virtuel (VPC) sur lequel le cluster EKS s’exécute. -
Pour modifier le ConfigMap aws-auth dans l’éditeur de texte en tant que créateur ou administrateur du cluster, exécutez la commande suivante :
$ kubectl edit configmap aws-auth -n kube-system
-
Ajoutez un utilisateur ou un rôle IAM :
mapUsers: | - userarn: arn:aws:iam::XXXXXXXXXXXX:user/testuser username: testuser groups: - system:bootstrappers - system:nodes
Vous pouvez également ajouter le rôle IAM à mapRoles. Exemple :
mapRoles: | - rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testrole username: testrole groups: - system:bootstrappers - system:nodes
Il est recommandé de ne pas utiliser system:masters pour les environnements de production, car ** system:masters** permet à un superutilisateur d’accéder à n’importe quelle action sur n’importe quelle ressource. Il est également recommandé de limiter au maximum les autorisations accordées. Créez un rôle disposant d’un accès à un espace de noms spécifique uniquement. Consultez la section Afficher les ressources Kubernetes dans un espace de noms spécifique de la page Autorisations requises.
eksctl
Pour utiliser l’outil eksctl afin de mettre à jour le ConfigMap aws-auth, exécutez la commande suivante :
eksctl create iamidentitymapping --cluster your_cluster_Name --region=your_region --arn YOUR_IAM_ARN <arn:aws:iam::123456:role testing=""> --group system:masters --username admin</arn:aws:iam::123456:role>
**Remarque :**Remplacez your_cluster_Name par le nom de votre cluster EKS, your_region par la région de votre cluster EKS et YOUR_IAM_ARN par votre rôle IAM ou utilisez ARN.
Vérifier l’accès à votre cluster Amazon EKS
Procédez comme suit :
- Ouvrez la console Amazon EKS.
- Dans le volet de navigation, choisissez Clusters.
- Choisissez votre cluster.
- Consultez les onglets Présentation et Charges de travail pour détecter les erreurs.
Si vous avez configuré un espace de noms spécifique, le message d’erreur suivant s’affiche dans la console Amazon EKS :
« Error loading Deploymentsdeployments.apps is forbidden: User "xxxxxx" cannot list resource "deployments" in API group "apps" at the cluster scope or in the namespace "xxxxxxx" »
L’erreur n’apparaît pas pour l’espace de noms spécifique. Pour résoudre les messages d'erreur, consultez Impossible de voir les nœuds dans l'onglet Calcul ou quoi que ce soit dans l'onglet Ressources et vous recevez un message d'erreur dans la console de gestion AWS.
Contenus pertinents
- demandé il y a 2 anslg...
- demandé il y a un anlg...
- demandé il y a 13 jourslg...
- demandé il y a 7 moislg...
- demandé il y a 7 moislg...
- Comment puis-je utiliser l'API d'entrée d'accès Amazon EKS pour récupérer l'accès à un cluster EKS ?AWS OFFICIELA mis à jour il y a 8 mois
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 2 mois