Authentifiez-vous sur un autre compte avec IRSA - Amazon EKS
Option 1 : créer un fournisseur d'identité à partir du cluster d'un autre compteOption 2 : utiliser des opérations chaînées AssumeRole

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.

Authentifiez-vous sur un autre compte avec IRSA

Vous pouvez configurer les autorisations IAM entre comptes en créant un fournisseur d’identité à partir du cluster d’un autre compte ou en utilisant les opérations AssumeRole chaînées. Dans les exemples suivants, le compte A possède un cluster Amazon EKS qui prend en charge les rôles IAM pour les comptes de service. Les pods qui s’exécutent sur ce cluster doivent assumer les autorisations IAM du compte B.

  • L'option 1 est plus simple mais nécessite que le compte B crée et gère un fournisseur d'identité OIDC pour le cluster du compte A.

  • L'option 2 conserve la gestion de l'OIDC dans le compte A mais nécessite un chaînage des rôles via deux AssumeRole appels.

Option 1 : créer un fournisseur d'identité à partir du cluster d'un autre compte

Dans cet exemple, le Compte A fournit au Compte B l'URL de l'émetteur OpenID Connect (OIDC) à partir de son cluster. Le compte B suit les instructions de la section Créer un fournisseur IAM OIDC pour votre cluster et Attribution de rôles IAM aux comptes de service Kubernetes utilise l’URL d’émetteur OIDC 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

Option 2 : utiliser des opérations chaînées AssumeRole

Dans cette approche, chaque compte crée un rôle IAM. Le rôle du compte B fait confiance au compte A, et le rôle du compte A utilise la fédération OIDC pour obtenir les informations d'identification du cluster. Le Pod enchaîne ensuite les deux rôles à l'aide de profils AWS CLI.

Étape 1 : créer le rôle cible dans le compte B

Le compte B (444455556666) crée un rôle IAM avec les autorisations dont ont besoin les pods du cluster du compte A. Le compte B associe la politique d'autorisation souhaitée à ce rôle, puis ajoute la politique de confiance suivante.

Politique de confiance pour le rôle du compte B — Cette politique permet au rôle IRSA spécifique du compte A d'assumer ce rôle.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}
Important

Pour obtenir le moindre privilège, remplacez l'PrincipalARN par l'ARN du rôle spécifique du compte A au lieu d'utiliser le compte root (arn:aws:iam::111122223333:root). L'utilisation de la racine du compte permet à n'importe quel principal IAM du compte A d'assumer ce rôle.

Étape 2 : créer le rôle IRSA dans le compte A

Le compte A (111122223333) crée un rôle doté d'une politique de confiance qui obtient les informations d'identification du fournisseur d'identité créé avec l'adresse de l'émetteur OIDC du cluster.

Politique de confiance pour le rôle du compte A (fédération OIDC) — Cette politique permet au fournisseur OIDC du cluster EKS de délivrer des informations d'identification pour ce rôle.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}
Important

Pour bénéficier du moindre privilège, ajoutez une StringEquals condition à la sub revendication visant à restreindre ce rôle à un compte de service Kubernetes spécifique. Sans sub condition, n'importe quel compte de service du cluster peut assumer ce rôle. La sub valeur utilise le formatsystem:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME . Par exemple, pour vous limiter à un compte de service nommé my-service-account dans l'espace de default noms :

"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"

Étape 3 : associer l' AssumeRole autorisation au rôle du compte A

Le compte A associe une politique d'autorisation au rôle créé à l'étape 2. Cette politique permet au rôle d'assumer le rôle du compte B.

Politique d'autorisation pour le rôle du compte A — Cette politique accorde sts:AssumeRole le rôle cible du compte B.

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::444455556666:role/account-b-role"
        }
    ]
}

Étape 4 : configurer le Pod pour enchaîner les rôles

Le code d’application permettant aux pods d’assumer 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 la 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 SDK que vous utilisez. Pour plus d'informations, consultez la section Outils sur lesquels vous pouvez vous appuyer AWS.