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 tous.
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.
Authentifiez-vous sur un autre compte avec IRSA
Vous pouvez configurer les IAM autorisations entre comptes soit en créant un fournisseur d'identité à partir du cluster d'un autre compte, soit en utilisant des opérations en chaîneAssumeRole
. Dans les exemples suivants, le compte A possède un EKS cluster Amazon qui prend en charge les IAM rôles pour les comptes de service. Podsqui s'exécutent sur ce cluster doivent bénéficier IAM des autorisations du compte B.
Exemple Créer un fournisseur d'identité à partir du cluster d'un autre compte
Dans cet exemple, le compte A fournit au compte B l'émetteur OpenID Connect (OIDC) URL de son cluster. Le compte B suit les instructions fournies Créez un IAM OIDC fournisseur pour votre cluster et Assign IAM rôles pour Kubernetes comptes de service utilisées par l'OIDCémetteur URL depuis le cluster du compte A. Ensuite, un administrateur de cluster annote le compte de service dans le cluster du compte A pour utiliser le rôle du compte B (444455556666
).
apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::
444455556666
:role/account-b-role
Exemple Utiliser des opérations AssumeRole
chaînées
Dans cet exemple, le compte B crée une IAM politique avec les autorisations à accorder Pods dans le cluster du compte A. Compte B (444455556666
) associe cette politique à un IAM rôle doté d'une relation de confiance autorisant l'AssumeRole
accès au compte A (111122223333
).
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
111122223333
:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] }
Le compte A crée un rôle avec une politique de confiance qui obtient les informations d'identification du fournisseur d'identité créé avec l'adresse de l'OIDCémetteur du cluster.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::
111122223333
:oidc-provider/oidc.eks.region-code
.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE
" }, "Action": "sts:AssumeRoleWithWebIdentity" } ] }
Si votre cluster se trouve dans une autre , ou si vous avez copié les images dans votre propre référentiel lors d'une étape précédente, effectuez les étapes suivantes.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::
444455556666
:role/account-b-role
" } ] }
Le code d'application pour que les Pods endossent le rôle du compte B utilise deux profils : account_b_role
et account_a_role
. Le profil account_b_role
utilise le profil account_a_role
comme source. Pour le AWS CLI, le ~/.aws/config
fichier est similaire au suivant.
[profile account_b_role] source_profile = account_a_role role_arn=arn:aws:iam::
444455556666
:role/account-b-role
[profile account_a_role] web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token role_arn=arn:aws:iam::111122223333
:role/account-a-role
Pour spécifier des profils chaînés pour d'autres AWS SDKs, consultez la documentation du produit SDK que vous utilisez. Pour plus d'informations, consultez la section Outils sur lesquels vous pouvez vous appuyer AWS