**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
<a name="cross-account-access"></a>

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
<a name="_option_1_create_an_identity_provider_from_another_accounts_cluster"></a>

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](enable-iam-roles-for-service-accounts.md) et [Attribution de rôles IAM aux comptes de service Kubernetes](associate-service-account-role.md) 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`
<a name="_option_2_use_chained_assumerole_operations"></a>

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
<a name="_step_1_create_the_target_role_in_account_b"></a>

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'`Principal`ARN 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
<a name="_step_2_create_the_irsa_role_in_account_a"></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 format`system: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
<a name="_step_3_attach_the_assumerole_permission_to_account_as_role"></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
<a name="_step_4_configure_the_pod_to_chain_roles"></a>

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](https://aws.amazon.com/developer/tools/).