Aidez à améliorer cette page
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.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.
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.
Attribuer un rôle IAM à un compte de service Kubernetes
Cette rubrique explique comment configurer un compte de service Kubernetes pour qu'il assume un rôle de gestion des AWS identités et des accès (IAM) avec EKS Pod Identity. Tous les pods configurés pour utiliser le compte de service peuvent ensuite accéder à tout AWS service auquel le rôle est autorisé à accéder.
Pour créer une association EKS Pod Identity, il n'y a qu'une seule étape : vous créez l'association dans EKS via la AWS Management Console AWS CLI AWS CloudFormation et d'autres outils. AWS SDKs Il n'existe aucune donnée ou métadonnée concernant les associations au sein du cluster dans les objets Kubernetes et vous n'ajoutez aucune annotation aux comptes de service.
-
Un cluster existant. Si vous n'en avez pas, vous pouvez en créer un en suivant l'un des guides présentés dansMise en route avec Amazon EKS.
-
Le principal IAM qui crée l’association doit avoir le
iam:PassRole
. -
La dernière version de la AWS CLI installée et configurée sur votre appareil ou AWS CloudShell. Vous pouvez vérifier votre version actuelle avec
aws --version | cut -d / -f2 | cut -d ' ' -f1
. Les gestionnaires de packages tels queyum
Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI.apt-get
Pour installer la dernière version, consultez la section Installation et configuration rapide avec aws configure dans le Guide de l'utilisateur de l'interface de ligne de AWS commande. La version de la AWS CLI installée dans le AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section Installation de la AWS CLI dans votre répertoire de base dans le guide de AWS CloudShell l'utilisateur. -
L'outil de ligne de commande
kubectl
est installé sur votre appareil ou AWS CloudShell. La version peut être identique ou supérieure à une version mineure antérieure ou ultérieure à la version Kubernetes de votre cluster. Par exemple, si la version de votre cluster est1.29
, vous pouvez utiliser la versionkubectl
1.28
,1.29
ou1.30
. Pour installer ou mettre à niveaukubectl
, veuillez consulter Configurez kubectl et eksctl. -
Un fichier existant
kubectl
config
qui contient la configuration de votre cluster. Pour créer un fichierkubectl
config
, consultez Connect kubectl à un cluster EKS en créant un fichier kubeconfig.
Création d'une association Pod Identity (AWS console)
-
Ouvrez la console Amazon EKS
. -
Dans le panneau de navigation de gauche, sélectionnez Clusters, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire l’agent d’identité du pod EKS.
-
Choisissez l’onglet Access.
-
Dans Associations d’identité du pod, sélectionnez Créer.
-
Pour Rôle IAM, sélectionnez le rôle IAM avec les autorisations dont a besoin la charge de travail.
Note
La liste ne contient que les rôles qui ont la politique d’approbation suivante qui permet à l’identité du pod EKS de les utiliser.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowEksAuthToAssumeRoleForPodIdentity", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] }
sts:AssumeRole
— EKS PodAssumeRole
Identity assume le rôle IAM avant de transmettre les informations d'identification temporaires à vos pods.sts:TagSession
— EKS Pod Identity est utiliséTagSession
pour inclure des balises de session dans les demandes adressées à AWS STS.Vous pouvez utiliser ces balises dans les clés de condition de la politique de confiance pour limiter les comptes de service, les espaces de noms et les clusters autorisés à utiliser ce rôle.
Pour obtenir la liste des clés de condition Amazon EKS, consultez la rubrique Conditions définies par Amazon Elastic Kubernetes Service de la Référence de l'autorisation de service. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez la rubrique Actions définies par Amazon Elastic Kubernetes Service.
-
Pour l'espace de noms Kubernetes, sélectionnez l'espace de noms Kubernetes qui contient le compte de service et la charge de travail. Vous pouvez éventuellement spécifier un espace de noms par un nom qui n'existe pas dans le cluster.
-
Pour le compte de service Kubernetes, sélectionnez le compte de service Kubernetes à utiliser. Le manifeste de votre charge de travail Kubernetes doit spécifier ce compte de service. Vous pouvez éventuellement spécifier un compte de service par un nom qui n'existe pas dans le cluster.
-
(Facultatif) Pour Balises, choisissez Ajouter une balise pour ajouter des métadonnées dans une paire clé et valeur. Ces balises sont appliquées à l’association et peuvent être utilisées dans les politiques IAM.
Vous pouvez répéter cette étape pour ajouter plusieurs balises.
-
Sélectionnez Create (Créer).
Création d'une association Pod Identity (AWS CLI)
-
Si vous souhaitez associer une politique IAM existante à votre rôle IAM, passez à l'étape suivante.
Créez une politique IAM. Vous pouvez créer votre propre politique ou copier une politique AWS gérée qui accorde déjà certaines des autorisations dont vous avez besoin et la personnaliser en fonction de vos besoins spécifiques. Pour plus d’informations, consultez Création de politiques IAM dans le Guide de l’utilisateur IAM.
-
Créez un fichier qui inclut les autorisations pour les AWS services auxquels vous souhaitez que vos pods accèdent. Pour obtenir la liste de toutes les actions pour tous les AWS services, consultez la référence d'autorisation des services.
Vous pouvez exécuter la commande suivante pour créer un exemple de fichier de politique autorisant l'accès en lecture seule à un compartiment Amazon S3. Vous pouvez éventuellement stocker des informations de configuration ou un script de démarrage dans ce compartiment, et les conteneurs de votre Pod peuvent lire le fichier depuis le compartiment et le charger dans votre application. Si vous souhaitez créer cet exemple de politique, copiez le contenu suivant sur votre appareil.
my-pod-secrets-bucket
Remplacez-le par le nom de votre compartiment et exécutez la commande.cat >my-policy.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws: s3:::my-pod-secrets-bucket" } ] } EOF
-
Créez la politique IAM.
aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
-
-
Créez un rôle IAM et associez-le à un compte de service Kubernetes.
-
Si vous possédez déjà un compte de service Kubernetes et que vous souhaitez assumer un rôle IAM, vous pouvez ignorer cette étape.
Créez un compte de service Kubernetes. Copiez les contenus suivants sur votre appareil.
my-service-account
Remplacez-le par le nom de votre choix etdefault
par un autre espace de noms, si nécessaire. Si vous modifiezdefault
, l'espace de noms doit déjà exister.cat >my-service-account.yaml <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: my-service-account namespace: default EOF kubectl apply -f my-service-account.yaml
Exécutez la commande suivante.
kubectl apply -f my-service-account.yaml
-
Exécutez la commande suivante pour créer un fichier de stratégie d'approbation pour le rôle IAM.
cat >trust-relationship.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowEksAuthToAssumeRoleForPodIdentity", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } EOF
-
Créez le rôle. Remplacez
my-role
avec un nom pour votre rôle IAM, etmy-role-description
avec une description de votre rôle.aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
-
Liez une politique IAM à votre rôle. Remplacez
my-role
par le nom de votre rôle IAM etmy-policy
par le nom d'une politique existante que vous avez créée.aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws: iam::111122223333:policy/my-policy
Note
Contrairement aux rôles IAM pour les comptes de service, EKS Pod Identity n'utilise pas d'annotation sur le compte de service.
-
Exécutez la commande suivante pour créer l’association.
my-cluster
Remplacez-le par le nom du cluster, remplacez-lemy-service-account
par le nom de votre choix etdefault
par un autre espace de noms, si nécessaire.aws eks create-pod-identity-association --cluster-name my-cluster --role-arn arn:aws: iam::111122223333:role/my-role --namespace default --service-account my-service-account
L'exemple qui suit illustre un résultat.
{ "association": { "clusterName": "my-cluster", "namespace": "default", "serviceAccount": "my-service-account", "roleArn": "arn:aws: iam::111122223333:role/my-role", "associationArn": "arn:aws::111122223333:podidentityassociation/my-cluster/a-abcdefghijklmnop1", "associationId": "a-abcdefghijklmnop1", "tags": {}, "createdAt": 1700862734.922, "modifiedAt": 1700862734.922 } }
Note
Vous pouvez spécifier un espace de noms et un compte de service par un nom qui n'existe pas dans le cluster. Vous devez créer l’espace de noms, le compte de service et la charge de travail qui utilise le compte de service pour que l’association de l’identité du pod EKS fonctionne.
-
Confirmer la configuration
-
Vérifiez que la politique de confiance du rôle IAM est correctement configurée.
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
L'exemple qui suit illustre un résultat.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Allow EKS Auth service to assume this role for Pod Identities", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] }
-
Vérifiez que la stratégie que vous avez associée à votre rôle lors d'une étape précédente est associée au rôle.
aws iam list-attached-role-policies --role-name my-role --query AttachedPolicies[].PolicyArn --output text
L'exemple qui suit illustre un résultat.
arn:aws: iam::111122223333:policy/my-policy
-
Définissez une variable pour stocker l'Amazon Resource Name (ARN) de la stratégie que vous souhaitez utiliser.
my-policy
Remplacez-le par le nom de la politique pour laquelle vous souhaitez confirmer les autorisations.export policy_arn=arn:aws: iam::111122223333:policy/my-policy
-
Affichez la version par défaut de la stratégie.
aws iam get-policy --policy-arn $policy_arn
L'exemple qui suit illustre un résultat.
{ "Policy": { "PolicyName": "my-policy", "PolicyId": "EXAMPLEBIOWGLDEXAMPLE", "Arn": "arn:aws: iam::111122223333:policy/my-policy", "Path": "/", "DefaultVersionId": "v1", [...] } }
-
Consultez le contenu de la politique pour vous assurer qu'elle inclut toutes les autorisations dont votre Pod a besoin. Si nécessaire, remplacez
1
la commande suivante par la version renvoyée dans la sortie précédente.aws iam get-policy-version --policy-arn $policy_arn --version-id v1
L'exemple qui suit illustre un résultat.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws: s3:::my-pod-secrets-bucket" } ] }
Si vous avez créé l'exemple de stratégie lors d'une étape précédente, le résultat est le même. Si vous avez créé une politique différente, le
example
contenu est différent.
Étapes suivantes
Configurer les pods pour accéder aux AWS services avec des comptes de service