**Contribuisci a migliorare questa pagina** 

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Eseguire l’autenticazione a un altro account con IRSA
<a name="cross-account-access"></a>

Ѐ possibile configurare le autorizzazioni IAM multi-account creando un gestore di identità dal cluster di un altro account o utilizzando operazioni `AssumeRole` concatenate. Negli esempi seguenti, l’*account A* possiede un cluster Amazon EKS che supporta i ruoli IAM per gli account di servizio. I pod in esecuzione sul cluster devono assumere le autorizzazioni IAM dall’*account B*.
+  **L'opzione 1** è più semplice ma richiede l'Account B per creare e gestire un provider di identità OIDC per il cluster dell'Account A.
+  **L'opzione 2** mantiene la gestione OIDC nell'Account A ma richiede il concatenamento dei ruoli tramite due chiamate. `AssumeRole`

## Opzione 1: creare un provider di identità dal cluster di un altro account
<a name="_option_1_create_an_identity_provider_from_another_accounts_cluster"></a>

In questo esempio, l'account A fornisce all'account B l'URL dell'emittente OpenID Connect (OIDC) dal relativo cluster. L’account B segue le istruzioni indicate alle pagine [Create an IAM OIDC provider for your cluster](enable-iam-roles-for-service-accounts.md) e [Assegnare ruoli IAM agli account di servizio Kubernetes](associate-service-account-role.md) utilizzando l’URL dell’emittente OIDC dal cluster dell’account A. Quindi, un amministratore del cluster annota l'account di servizio nel cluster dell'Account A per utilizzare il ruolo dell'Account B (*444455556666*).

```
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws: iam::444455556666:role/account-b-role
```

## Opzione 2: utilizzare operazioni `AssumeRole` concatenate
<a name="_option_2_use_chained_assumerole_operations"></a>

In questo approccio, ogni account crea un ruolo IAM. Il ruolo dell'Account B si affida all'Account A e il ruolo dell'Account A utilizza la federazione OIDC per ottenere le credenziali dal cluster. Il Pod concatena quindi i due ruoli utilizzando i AWS profili CLI.

### Fase 1: Creare il ruolo di destinazione nell'Account B
<a name="_step_1_create_the_target_role_in_account_b"></a>

L'account B (*444455556666*) crea un ruolo IAM con le autorizzazioni necessarie ai pod del cluster dell'account A. L'account B associa la politica di autorizzazione desiderata a questo ruolo, quindi aggiunge la seguente politica di fiducia.

 **Politica di fiducia per il ruolo dell'Account B**: questa politica consente al ruolo IRSA specifico dell'Account A di assumere questo ruolo.

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

**Importante**  
Per ottenere il minimo privilegio, sostituisci l'`Principal`ARN con il ruolo specifico ARN dell'account A invece di usare l'account root (). `arn:aws:iam::111122223333:root` L'utilizzo dell'account root consente a *qualsiasi* principale IAM dell'account A di assumere questo ruolo.

### Fase 2: Creare il ruolo IRSA nell'Account A
<a name="_step_2_create_the_irsa_role_in_account_a"></a>

L'account A (*111122223333*) crea un ruolo con una politica di fiducia che ottiene le credenziali dal provider di identità creato con l'indirizzo dell'emittente OIDC del cluster.

 **Politica di fiducia per il ruolo dell'Account A (federazione OIDC)**: questa politica consente al provider OIDC del cluster EKS di emettere credenziali per questo ruolo.

```
{
  "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"
        }
      }
    }
  ]
}
```

**Importante**  
Per ottenere il privilegio minimo, aggiungi una `StringEquals` condizione per la `sub` dichiarazione di limitare questo ruolo a uno specifico account di servizio Kubernetes. Senza una `sub` condizione, qualsiasi account di servizio nel cluster può assumere questo ruolo. Il `sub` valore utilizza il formato`system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME `. Ad esempio, per limitarsi a un account di servizio denominato `my-service-account` nel `default` namespace:  

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

### Passaggio 3: allegare l' AssumeRole autorizzazione al ruolo dell'Account A
<a name="_step_3_attach_the_assumerole_permission_to_account_as_role"></a>

L'Account A allega una politica di autorizzazione al ruolo creato nella Fase 2. Questa politica consente al ruolo di assumere il ruolo dell'Account B.

 **Politica di autorizzazione per il ruolo dell'Account A**: questa politica concede `sts:AssumeRole` all'Account B il ruolo obiettivo.

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

### Passaggio 4: configura il Pod per concatenare i ruoli
<a name="_step_4_configure_the_pod_to_chain_roles"></a>

Il codice dell’applicazione per i pod che assumono il ruolo dell’account B utilizza due profili: `account_b_role` e `account_a_role`. Il profilo `account_b_role` utilizza il profilo `account_a_role` come origine. Per la AWS CLI, il `~/.aws/config` file è simile al seguente.

```
[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
```

Per specificare profili concatenati per altri AWS SDKs, consulta la documentazione dell'SDK che stai utilizzando. Per ulteriori informazioni, consulta [Strumenti su cui costruire](https://aws.amazon.com/developer/tools/). AWS