Authentifiez-vous sur un autre compte avec IRSA - Amazon EKS

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.

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 Attribuer IAM des rôles aux comptes Kubernetes 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'AssumeRoleaccè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.