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

Brève description

Vous recevez 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 lorsqu'un utilisateur ou un rôle IAM crée un cluster Amazon EKS 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.

Pour accorder l'accès à un rôle IAM, vous devez utiliser les informations d'identification du créateur du cluster. Ajoutez ensuite le rôle IAM dans la section mapRoles du ConfigMap aws-auth.

Important :

• Évitez les erreurs de syntaxe (telles que les fautes de frappe) lorsque vous mettez à jour le ConfigMap aws-auth. Ces erreurs peuvent affecter les autorisations de tous les utilisateurs et rôles IAM mis à jour dans le ConfigMap du cluster Amazon EKS.
• Il est recommandé d'éviter d'ajouter cluster_creator à ConfigMap. Toute modification incorrecte de ConfigMap peut entraîner la perte définitive de l'accès au cluster Amazon EKS pour tous les utilisateurs et rôles IAM, y compris cluster_creator.
• Vous n'avez pas besoin d'ajouter cluster_creator au 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 des commandes depuis AWS Command Line Interface (AWS CLI), assurez-vous d'utiliser la version la plus récente de l'AWS CLI.

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 primaire pour configurer votre cluster Amazon EKS.

2.    Identifiez l'utilisateur IAM auquel le créateur du cluster accorde 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.    Installez kubectl sur votre machine hôte locale. Ou, si vous disposez d'une instance Amazon Elastic Compute Cloud (Amazon EC2) dédiée avec un package kubectl installé, utilisez SSH pour vous connecter à l'instance.

2.    Sur la même machine hôte sur laquelle kubectl est installé, configurez l'AWS CLI avec les informations d'identification designated_user :

aws configure

3.    Dans l'AWS CLI, exécutez la commande suivante :

aws sts get-caller-identity

Le résultat doit renvoyer les détails de l'utilisateur IAM pour designated_user.

Par exemple :

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

4.    Répertoriez les pods qui s'exécutent dans le cluster de l'espace de noms par défaut :

kubectl get pods --namespace default

Le résultat affiche le message 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.

5.    Configurez l'identifiant de la clé d'accès AWS et la clé d'accès secrète AWS du cluster_creator.

Si le cluster a été créé à l'aide de la Console de gestion AWS, identifiez le rôle ou l'utilisateur IAM qui a créé le cluster. Sur la machine hôte sur laquelle kubectl est installé, configurez l'utilisateur ou le rôle IAM cluster_creator dans l'AWS CLI :

aws configure

Si eksctl a été utilisé pour créer le cluster, utilisez les informations d'identification de profil d'AWS CLI par défaut ou spécifiées pour configurer l'AWS CLI afin d'exécuter les commandes kubectl.

6.    Vérifiez que cluster_creator a accès au cluster :

kubectl get pods

Si tout est configuré correctement, vous ne recevez pas de message d'erreur non autorisé. Le résultat doit répertorier tous les pods qui s'exécutent 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 dans l'espace de noms par défaut.

7.    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 dans Activation de l'accès des utilisateurs et des rôles IAM à votre cluster.

8.    Ajoutez designated_user à la section mapUsers du fichier aws-auth.yaml à l'étape 7, puis enregistrez le fichier.

9.    Appliquez le nouveau ConfigMap à la configuration RBAC du cluster :

kubectl apply -f aws-auth.yaml

10.    Modifiez à nouveau la configuration de l'AWS CLI afin d'utiliser les informations d'identification du designated_user :

aws configure

11.    Vérifiez que designated_user a accès au cluster :

kubectl get pods

Si tout est configuré correctement, vous ne recevez pas de message d'erreur non autorisé. Le résultat répertorie tous les pods qui s'exécutent 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 dans l'espace de noms par défaut.

Ajout d'un utilisateur désigné (designated_user) au 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 un rôle IAM a créé le cluster au lieu d'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.

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

Pour assumer le rôle IAM et modifier le ConfigMap aws-auth sur le cluster afin que vous puissiez fournir l'accès à designated_user, effectuez les étapes suivantes :

1.    Affichez les détails de l'utilisateur IAM de assume_role_user :

aws sts get-caller-identity

2.    Confirmez que assume_role_user a accès au cluster :

kubectl get pods

Le résultat affiche le message 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 assume_role_user ne dispose pas de l'autorisation pour configurer le cluster Amazon EKS.

3.    Permettez à assume_role_user d'assumer le rôle de cluster_creator :

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

Le résultat affiche les informations d'identification IAM temporaires pour assume_role_user.

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'AWS CLI 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.    Vérifiez que l'AWS CLI utilise le rôle assumé pour cluster_creator :

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 dans Activation de l'accès des utilisateurs et des rôles IAM à votre cluster.

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

8.    Appliquez la nouvelle configuration à la configuration RBAC du cluster Amazon EKS :

kubectl apply -f aws-auth.yaml

9.    Désactivez les variables d'environnement suivantes :

unset AWS_ACCESS_KEY_ID
unset AWS_SESSION_TOKEN
unset AWS_SECRET_ACCESS_KEY

10.    Affichez les détails de l'utilisateur IAM de designated_user :

aws sts get-caller-identity

11.    Confirmez que designated_user a accès au cluster :

kubectl get pods

Si tout est configuré correctement, vous ne recevez pas de message d'erreur non autorisé. Le résultat répertorie tous les pods qui s'exécutent 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 dans l'espace de noms par défaut.

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.

---

Informations connexes

Utilisation d'un rôle IAM dans l'interface de ligne de commande AWS