Aidez à améliorer cette page
Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Accordez aux IAM utilisateurs Kubernetes l'accès à ConfigMap
Important
Le aws-auth
ConfigMap est obsolète. La méthode recommandée pour gérer l'accès aux Kubernetes API est celle des entrées d'accès.
L'authentificateur IAM AWS pour Kubernetesaws-auth
ConfigMap
. Pour tous les paramètres aws-auth
ConfigMap
, consultez Format de configuration complet
Ajout de principaux IAM à votre cluster Amazon EKS
Lorsque vous créez un cluster Amazon EKS, le principal IAM qui crée le cluster se voit automatiquement accorder des autorisations system:masters
dans la configuration du contrôle d'accès basé sur les rôles (RBAC) du cluster dans le plan de contrôle Amazon EKS. Ce principal n'apparaît dans aucune configuration visible. Souvenez-vous donc du principal qui a créé le cluster à l'origine. Pour permettre à d'autres principaux IAM d'interagir avec votre cluster, modifiez la ConfigMap
aws-auth
dans Kubernetes et créez un rolebinding
ou un clusterrolebinding
Kubernetes avec le nom d'un group
que vous spécifiez dans la ConfigMap
aws-auth
.
Note
Pour plus d'informations sur la configuration du contrôle d'accès basé sur les rôles (RBAC) de Kubernetes, consultez la rubrique Utilisation de l'autorisation RBAC
Pour ajouter un principal IAM à un cluster Amazon EKS
-
Déterminer les informations d'identification que
kubectl
utilise pour accéder à votre cluster. Sur votre ordinateur, vous pouvez voir quelles informations d'identificationkubectl
utilise avec la commande suivante. Remplacez
par le chemin de votre fichier~/.kube/config
kubeconfig
si vous n'utilisez pas le chemin par défaut.cat
~/.kube/config
L'exemple qui suit illustre un résultat.
[...] contexts: - context: cluster:
my-cluster.
user:region-code
.eksctl.ioadmin@my-cluster.
name:region-code
.eksctl.ioadmin@my-cluster.
current-context:region-code
.eksctl.ioadmin@my-cluster.
[...]region-code
.eksctl.ioDans l'exemple de sortie précédent, les informations d'identification d'un utilisateur nommé
sont configurées pour un cluster nomméadmin
. Si c'est l'utilisateur qui a créé le cluster, alors il a déjà accès à votre cluster. S'il ne s'agit pas de l'utilisateur qui a créé le cluster, suivez les étapes restantes pour permettre à d'autres principaux IAM d'accéder au cluster. Les bonnes pratiques IAM recommandent d'accorder des autorisations à des rôles plutôt qu'à des utilisateurs. Vous pouvez voir quels autres principaux ont actuellement accès à votre cluster à l'aide de la commande suivante :my-cluster
kubectl describe -n kube-system configmap/aws-auth
L'exemple qui suit illustre un résultat.
Name: aws-auth Namespace: kube-system Labels: <none> Annotations: <none> Data ==== mapRoles: ---- - groups: - system:bootstrappers - system:nodes rolearn: arn:aws:iam::
111122223333
:role/my-node-role
username: system:node:{{EC2PrivateDNSName}} BinaryData ==== Events: <none>L'exemple précédent est un
aws-auth
ConfigMap
par défaut. Seul le rôle d'instance du nœud a accès au cluster. -
Assurez-vous de disposer de
roles
et derolebindings
ou declusterroles
et declusterrolebindings
Kubernetes auxquels vous pouvez mapper des principaux IAM. Pour plus d'informations sur ces ressources, consultez Utilisation de l'autorisation RBACdans la documentation Kubernetes. -
Affichez vos Kubernetes
roles
ouclusterroles
existants. LesRoles
sont étendus à unnamespace
, mais lesclusterroles
sont étendus au cluster.kubectl get roles -A
kubectl get clusterroles
-
Affichez les détails de tout
role
ouclusterrole
renvoyé dans la sortie précédente et assurez-vous qu'il dispose des autorisations (rules
) dont vous souhaitez que vos principaux IAM disposent dans votre cluster.Remplacez
par un nom derole-name
role
renvoyé dans la sortie de la commande précédente. Remplacez
par l'espace de noms dukube-system
role
.kubectl describe role
role-name
-nkube-system
Remplacez
par un nom decluster-role-name
clusterrole
renvoyé dans la sortie de la commande précédente.kubectl describe clusterrole
cluster-role-name
-
Affichez vos Kubernetes
rolebindings
ouclusterrolebindings
existants. LesRolebindings
sont étendus à unnamespace
, mais lesclusterrolebindings
sont étendus au cluster.kubectl get rolebindings -A
kubectl get clusterrolebindings
-
Affichez les détails de n'importe quel
rolebinding
ouclusterrolebinding
et confirmez qu'il possède unrole
ou unclusterrole
de l'étape précédente répertorié comme unroleRef
et un nom de groupe répertorié poursubjects
.Remplacez
par un nom derole-binding-name
rolebinding
renvoyé dans la sortie de la commande précédente. Remplacez
avec lekube-system
namespace
durolebinding
.kubectl describe rolebinding
role-binding-name
-nkube-system
L'exemple qui suit illustre un résultat.
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name:
eks-console-dashboard-restricted-access-role-binding
namespace:default
subjects: - kind: Group name:eks-console-dashboard-restricted-access-group
apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name:eks-console-dashboard-restricted-access-role
apiGroup: rbac.authorization.k8s.ioRemplacez
par un nom decluster-role-binding-name
clusterrolebinding
renvoyé dans la sortie de la commande précédente.kubectl describe clusterrolebinding
cluster-role-binding-name
L'exemple qui suit illustre un résultat.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name:
eks-console-dashboard-full-access-binding
subjects: - kind: Group name:eks-console-dashboard-full-access-group
apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name:eks-console-dashboard-full-access-clusterrole
apiGroup: rbac.authorization.k8s.io
-
-
Modifiez le
aws-auth
ConfigMap
. Vous pouvez utiliser un outil tel queeksctl
pour mettre à jour leConfigMap
ou vous pouvez le mettre à jour manuellement en le modifiant.Important
Nous vous recommandons d'utiliser
eksctl
, ou un autre outil, pour modifier leConfigMap
. Pour plus d'informations sur les autres outils que vous pouvez utiliser, consultez Utiliser des outils pour apporter des modifications auaws-auth
ConfigMap
dans les guides des bonnes pratiques Amazon EKS. Un aws-auth
ConfigMap
mis en forme incorrectement peut entraîner la perte de l'accès à votre cluster.
Appliquer la ConfigMap
aws-auth
à votre cluster
Le aws-auth
ConfigMap
est automatiquement créé et appliqué à votre cluster lorsque vous créez un groupe de nœuds géré ou lorsque vous créez un groupe de nœuds à l'aide de eksctl
. Il est initialement créé pour permettre aux nœuds de rejoindre votre cluster, mais vous utilisez également cette ConfigMap
pour ajouter un accès RBAC aux principaux IAM. Si vous avez lancé des nœuds autogérés et que vous n'avez pas encore appliqué la aws-auth
ConfigMap
à votre cluster, vous pouvez le faire en suivant la procédure ci-dessous.
Pour appliquer le aws-auth
ConfigMap
à votre cluster
-
Vérifiez si vous avez déjà appliqué la
aws-auth
ConfigMap
.kubectl describe configmap -n kube-system aws-auth
Si vous recevez une erreur indiquant «
Error from server (NotFound): configmaps "aws-auth" not found
», effectuez les opérations suivantes pour appliquer leConfigMap
stock. -
Téléchargez, modifiez et appliquez le plan de configuration de l' AWS authentificateur.
-
Téléchargez la mappe de configuration.
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
-
Dans le fichier
, remplacezaws-auth-cm.yaml
rolearn
par l'Amazon Resource Name (ARN) du rôle IAM associé par vos nœuds. Pour ce faire, utilisez un éditeur de texte ou remplacez
et exécutez la commande suivante :my-node-instance-role
sed -i.bak -e 's|<ARN of instance role (not instance profile)>|
my-node-instance-role
|' aws-auth-cm.yamlNe modifiez aucune autre ligne de ce fichier.
Important
L'ARN de rôle ne peut pas inclure de chemin d'accès tel que
role/my-team/developers/my-role
. Le format de l'ARN doit êtrearn:aws:iam::
. Dans cet exemple,111122223333
:role/my-role
my-team/developers/
doit être supprimé.Vous pouvez inspecter les sorties de la AWS CloudFormation pile pour vos groupes de nœuds et rechercher les valeurs suivantes :
-
InstanceRoleARN — Pour les groupes de nœuds créés avec
eksctl
-
NodeInstanceRole— Pour les groupes de nœuds créés à l'aide de AWS CloudFormation modèles Amazon EKS vendus dans le AWS Management Console
-
-
Appliquez la configuration. L'exécution de cette commande peut prendre quelques minutes.
kubectl apply -f aws-auth-cm.yaml
Note
Si vous recevez d'autres erreurs concernant les types d'autorisations ou de ressources, consultez Accès non autorisé ou refusé (kubectl) dans la rubrique relative à la résolution des problèmes.
-
-
Observez le statut de vos nœuds et attendez qu'ils obtiennent le statut
Ready
.kubectl get nodes --watch
Saisissez
Ctrl
+C
pour revenir à une invite de shell.