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.
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 contribueront à 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.
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. Pods qui s'exécutent sur ce cluster doivent bénéficier IAM des autorisations du compte B.
Exemple Création d'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 de la section Créer un IAM OIDC fournisseur pour votre cluster Créer un IAM OIDC fournisseur pour votre cluster et Assign IAM rôles pour Kubernetes comptes de service utiliser l'OIDCémetteur URL du 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 Pods pour assumer le rôle du compte B, deux profils sont utilisés : account_b_role
etaccount_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