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à.

# Abilita IAM Roles per il cluster EKS
<a name="setting-up-enable-IAM-roles"></a>

I seguenti argomenti descrivono in dettaglio le opzioni per abilitare i ruoli IAM.

**Topics**
+ [Opzione 1: abilitare EKS Pod Identity sul cluster EKS](setting-up-enable-IAM.md)
+ [Opzione 2: abilitare IAM Roles for Service Accounts (IRSA) sul cluster EKS](setting-up-enable-IAM-service-accounts.md)

# Opzione 1: abilitare EKS Pod Identity sul cluster EKS
<a name="setting-up-enable-IAM"></a>

Le associazioni Amazon EKS Pod Identity offrono la possibilità di gestire le credenziali per le applicazioni, in modo simile a come i profili di istanza di Amazon EC2 forniscono le credenziali alle istanze Amazon EC2. Amazon EKS Pod Identity fornisce le credenziali per i tuoi carichi di lavoro con un'API EKS Auth aggiuntiva e un pod di agenti che viene eseguito su ogni nodo.

Amazon EMR su EKS inizia a supportare l'identità dei pod EKS dalla versione emr-7.3.0 per il modello di invio. StartJobRun 

Per ulteriori informazioni sulle identità dei pod EKS, consulta [Comprendere](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html) come funziona EKS Pod Identity.

## Perché EKS Pod Identities?
<a name="setting-up-enable-IAM-pod-identity-why"></a>

Come parte della configurazione EMR, il Job Execution Role deve stabilire limiti di fiducia tra un ruolo IAM e gli account di servizio in uno spazio dei nomi specifico (di cluster virtuali EMR). Con IRSA, ciò è stato ottenuto aggiornando la politica di fiducia dell'EMR Job Execution Role. Tuttavia, a causa del limite massimo di 4096 caratteri alla lunghezza della policy di fiducia IAM, esisteva un vincolo alla condivisione di un singolo ruolo IAM Job Execution su un massimo di dodici (12) cluster EKS.

Con il supporto di EMR per Pod Identities, il confine di fiducia tra i ruoli IAM e gli account di servizio viene ora gestito dal team EKS tramite l'associazione di EKS pod identity. APIs

**Nota**  
Il limite di sicurezza per l'identità del pod EKS è ancora a livello di account di servizio, non a livello di pod.

## Considerazioni sull'identità dei pod
<a name="setting-up-enable-IAM-pod-identity-consider"></a>

Per informazioni sulle limitazioni relative all'identità dei Pod, consulta le [considerazioni relative all'identità di EKS Pod](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations).

## Prepara EKS Pod Identity in EKS Cluster
<a name="setting-up-enable-IAM-pod-eks-cluster"></a>

### Verifica se l'autorizzazione richiesta esiste in NodeInstanceRole
<a name="setting-up-enable-IAM-pod-eks-cluster-permission"></a>

Il ruolo del nodo `NodeInstanceRole` richiede l'autorizzazione dell'agente per eseguire l'`AssumeRoleForPodIdentity`azione nell'API di autenticazione EKS. Puoi aggiungere quanto segue ad [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy), definito nella Guida per l'utente di Amazon EKS, o utilizzare una politica personalizzata.

Se il tuo cluster EKS è stato creato con una versione eksctl successiva alla **0.181.0,** Amazon EKSWorkerNodePolicy, inclusa l'`AssumeRoleForPodIdentity`autorizzazione richiesta, verrà assegnato automaticamente al ruolo del nodo. Se l'autorizzazione non è presente, aggiungi manualmente la seguente autorizzazione ad Amazon EKSWorker NodePolicy che consente di assumere un ruolo per l'identità del pod. Questa autorizzazione è necessaria all'agente di identità dei pod EKS per recuperare le credenziali dei pod.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks-auth:AssumeRoleForPodIdentity"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEKSAUTHAssumeroleforpodidentity"
    }
  ]
}
```

------

### Crea il componente aggiuntivo EKS pod identity agent
<a name="setting-up-enable-IAM-pod-eks-cluster-agent"></a>

Usa il seguente comando per creare il componente aggiuntivo EKS Pod Identity Agent con la versione più recente:

```
aws eks create-addon --cluster-name cluster-name --addon-name eks-pod-identity-agent

kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```

Utilizza i seguenti passaggi per creare il componente aggiuntivo EKS Pod Identity Agent dalla console Amazon EKS:

1. Apri la console Amazon EKS: console [Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Nel riquadro di navigazione a sinistra, seleziona **Cluster**, quindi scegli il nome del cluster per cui configurare il componente aggiuntivo di EKS Pod Identity Agent.

1. Selezionare la scheda **Componenti aggiuntivi**.

1. Scegli **Ottieni altri componenti aggiuntivi**.

1. Seleziona la casella nella parte superiore destra di quella del componente aggiuntivo relativo a EKS Pod Identity Agent e scegli **Avanti**.

1. Nella pagina **Configura le impostazioni dei componenti aggiuntivi selezionati**, seleziona una versione qualsiasi nell'elenco a discesa **Versione**.

1. (Facoltativo) Espandi **Impostazioni di configurazione facoltative** per inserire una configurazione aggiuntiva. Ad esempio, puoi fornire una posizione alternativa per l'immagine del container e `ImagePullSecrets`. Lo Schema JSON con le chiavi accettate sono mostrate in **Schema di configurazione del componente aggiuntivo**.

   Inserisci le chiavi e i valori di configurazione in **Valori di configurazione**.

1. Scegli **Next (Successivo)**.

1. Verifica che i pod dell'agente siano in esecuzione sul tuo cluster tramite la CLI.

   `kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'`

Un esempio di output è il seguente:

```
NAME                              READY   STATUS    RESTARTS      AGE
eks-pod-identity-agent-gmqp7      1/1     Running   1 (24h ago)   24h
eks-pod-identity-agent-prnsh      1/1     Running   1 (24h ago)   24h
```

Questo ne imposta uno nuovo DaemonSet nel `kube-system` namespace. Amazon EKS Pod Identity Agent, in esecuzione su ogni nodo EKS, utilizza l'[AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)azione per recuperare credenziali temporanee dall'API EKS Auth. Queste credenziali vengono quindi rese disponibili per l' AWS SDKs esecuzione all'interno dei contenitori.

Per ulteriori informazioni, consulta il prerequisito nel documento pubblico: [Configurazione di Amazon EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) Agent.

## Creare un ruolo Job Execution
<a name="setting-up-enable-IAM-pod-create-job-role"></a>

### Crea o aggiorna un ruolo di esecuzione del lavoro che consenta EKS Pod Identity
<a name="setting-up-enable-IAM-pod-create-job-role-update"></a>

Per eseguire carichi di lavoro con Amazon EMR su EKS, devi creare un ruolo IAM. Nella presente documentazione, tale ruolo viene definito ruolo di esecuzione di processo. Per ulteriori informazioni su come creare il ruolo IAM, consulta [Creazione di ruoli IAM nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) per l'utente.

Inoltre, è necessario creare una policy IAM che specifichi le autorizzazioni necessarie per il ruolo di esecuzione del lavoro e quindi allegare questa policy al ruolo per abilitare EKS Pod Identity.

Ad esempio, avete il seguente ruolo di esecuzione del lavoro. Per ulteriori informazioni, vedere [Creare un ruolo di esecuzione del lavoro](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html).

```
arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole
```

**Importante**  
Amazon EMR su EKS crea automaticamente account di servizio Kubernetes, in base al nome del ruolo di esecuzione del lavoro. Assicurati che il nome del ruolo non sia troppo lungo, poiché il lavoro potrebbe fallire se la combinazione di e `service_account_name` supera `cluster_name` il `pod_name` limite di lunghezza.

**Configurazione del ruolo di esecuzione** del lavoro: assicurati che il ruolo di esecuzione del lavoro sia creato con l'autorizzazione di fiducia seguente per EKS Pod Identity. Per aggiornare un ruolo di esecuzione del lavoro esistente, configuralo in modo che consideri attendibile il seguente principale del servizio EKS come autorizzazione aggiuntiva nella politica di fiducia. Questa autorizzazione di fiducia può coesistere con le politiche di trust IRSA esistenti.

```
cat >trust-relationship.json <<EOF
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}
EOF
```

**Autorizzazione utente**: gli utenti richiedono l'`iam:PassRole`autorizzazione per eseguire chiamate `StartJobRun` API o inviare lavori. Questa autorizzazione consente agli utenti di passare il ruolo di esecuzione del lavoro a EMR su EKS. Gli amministratori di Job devono disporre dell'autorizzazione per impostazione predefinita.

Di seguito è riportata l'autorizzazione necessaria per un utente:

```
{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole",
    "Condition": {
        "StringEquals": {
            "iam:PassedToService": "pods.eks.amazonaws.com"
        }
    }
}
```

Per limitare ulteriormente l'accesso degli utenti a cluster EKS specifici, aggiungi il filtro AssociatedResourceArn degli attributi alla policy IAM. Limita l'assunzione di ruoli ai cluster EKS autorizzati, rafforzando i controlli di sicurezza a livello di risorsa.

```
"Condition": {
        "ArnLike": {
            "iam:AssociatedResourceARN": [
                "arn:aws:eks:us-west-2:111122223333:cluster/*"
            ]
        }
```

## Configura le associazioni di identità dei pod EKS
<a name="setting-up-enable-IAM-pod-identity-asociations"></a>

### Prerequisito
<a name="setting-up-enable-IAM-pod-identity-asociations-prereq"></a>

Assicurati che l'identità IAM che crea l'associazione di identità del pod, ad esempio un utente amministratore EKS, disponga dell'autorizzazione `eks:CreatePodIdentityAssociation` e`iam:PassRole`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:CreatePodIdentityAssociation"
      ],
      "Resource": [
        "arn:aws:eks:*:*:cluster/*"
      ],
      "Sid": "AllowEKSCreatepodidentityassociation"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:aws:iam::*:role/*"
      ],
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "pods.eks.amazonaws.com"
        }
      },
      "Sid": "AllowIAMPassrole"
    }
  ]
}
```

------

### Creare associazioni per il ruolo e l'account del servizio EMR
<a name="setting-up-enable-IAM-pod-identity-asociations-emr-service"></a>

------
#### [ Create EMR role associations through the AWS CLI ]

Quando invii un lavoro a un namespace Kubernetes, un amministratore deve creare associazioni tra il ruolo di esecuzione del lavoro e l'identità dell'account del servizio gestito EMR. Ricorda che l'account di servizio gestito da EMR viene creato in automatico all'invio del processo, nell'ambito dello spazio dei nomi in cui viene inviato il processo.

Con la AWS CLI (precedente versione 2.24.0), esegui il comando seguente per creare associazioni di ruoli con l'identità del pod.

Esegui il comando seguente per creare associazioni di ruoli con l'identità del pod:

```
aws emr-containers create-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2
```

Nota:
+ Ogni cluster può avere un limite di 1.000 associazioni. La mappatura di ogni ruolo di esecuzione del lavoro (namespace) richiederà 3 associazioni per i pod Job Submitter, Driver ed Executor.
+ È possibile associare solo ruoli che si trovano nello stesso account del cluster. AWS È possibile delegare l'accesso da un altro account al ruolo di questo account configurato per l'utilizzo delle associazioni EKS Pod Identity. Per un tutorial sulla delega dell'accesso e`AssumeRole`, consulta il [tutorial IAM: delega l'accesso tra AWS account utilizzando i ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html).

------
#### [ Create EMR role associations through Amazon EKS ]

EMR crea un account di servizio con un determinato schema di denominazione quando viene inviato un lavoro. Per creare associazioni manuali o integrare questo flusso di lavoro con l' AWS SDK, procedi nel seguente modo:

Costruisci il nome dell'account del servizio:

```
emr-containers-sa-spark-%(SPARK_ROLE)s-%(AWS_ACCOUNT_ID)s-%(BASE36_ENCODED_ROLE_NAME)s
```

Gli esempi seguenti creano un'associazione di ruoli per un ruolo di Job execution di esempio JobExecutionRoleIRSAv2.

**Esempi di associazioni di ruoli:**

```
RoleName: JobExecutionRoleIRSAv2
Base36EncodingOfRoleName: 2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

**Esempio di comando CLI:**

```
# setup for the client service account (used by job runner pod)
# emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# driver service account
# emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe        
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# executor service account
# emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

------

Dopo aver completato tutti i passaggi richiesti per l'identità del pod EKS, puoi saltare i seguenti passaggi per la configurazione IRSA:
+ [Abilita IAM Roles for Service Accounts (IRSA) sul cluster EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html)
+ [Crea un ruolo di esecuzione del lavoro](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)
+ [Aggiorna la politica di fiducia del ruolo di esecuzione del lavoro](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html)

Puoi passare direttamente al passaggio seguente: [Concedi agli utenti l'accesso ad Amazon EMR su EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html)

## Elimina le associazioni di ruoli
<a name="setting-up-enable-IAM-pod-identity-asociations-delete-associations"></a>

Ogni volta che si elimina un cluster virtuale o un ruolo di esecuzione del lavoro e non si desidera più concedere l'accesso a EMR ai relativi account di servizio, è necessario eliminare le associazioni per il ruolo. Questo perché EKS consente associazioni con risorse inesistenti (namespace e account di servizio). Amazon EMR su EKS consiglia di eliminare le associazioni se lo spazio dei nomi viene eliminato o il ruolo non è più in uso, per liberare spazio per altre associazioni.

**Nota**  
Le associazioni persistenti potrebbero potenzialmente influire sulla tua capacità di scalabilità se non le elimini, poiché EKS ha dei limiti sul numero di associazioni che puoi creare (limite minimo: 1000 associazioni per cluster). Puoi elencare le associazioni di identità dei pod in un determinato namespace per verificare se ci sono associazioni persistenti che devono essere ripulite:

```
aws eks list-pod-identity-associations --cluster-name mycluster --namespace mynamespace
```

Con AWS CLI (versione 2.24.0 o successiva), esegui il seguente comando emr-containers per eliminare le associazioni di ruolo di EMR:

```
aws emr-containers delete-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2
```

## Migra automaticamente l'IRSA esistente su Pod Identity
<a name="setting-up-enable-IAM-pod-identity-auto-migrate"></a>

Puoi utilizzare lo strumento eksctl per migrare gli IAM Roles for Service Accounts (IRSA) esistenti alle associazioni di identità pod:

```
eksctl utils migrate-to-pod-identity \
    --cluster mycluster \
    --remove-oidc-provider-trust-relationship \
    --approve
```

L'esecuzione del comando senza il `--approve` flag produrrà solo un piano che riflette le fasi della migrazione e non si verificherà alcuna migrazione effettiva.

## Risoluzione dei problemi
<a name="setting-up-enable-IAM-pod-identity-troubleshooting"></a>

### Il mio lavoro non è riuscito con NoClassDefinitionFound ClassNotFound Exception for Credentials Provider o non sono riuscito a ottenere il provider di credenziali.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-no-class"></a>

EKS Pod Identity utilizza il Container Credentials Provider per recuperare le credenziali necessarie. Se hai specificato un provider di credenziali personalizzato, assicurati che funzioni correttamente. In alternativa, assicurati di utilizzare una versione AWS SDK corretta che supporti EKS Pod Identity. Per ulteriori informazioni, consulta la sezione [Introduzione ad Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

### Job non riuscito con l'errore «Impossibile recuperare le credenziali a causa di [x] Size Limit» visualizzato nel eks-pod-identity-agent registro.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds"></a>

EMR su EKS crea account di servizio Kubernetes in base al nome del ruolo di esecuzione del lavoro. Se il nome del ruolo è troppo lungo, EKS Auth non riuscirà a recuperare le credenziali perché la combinazione di e supera il limite di `cluster_name` lunghezza. `pod_name` `service_account_name` Identifica quale componente occupa più spazio e regola le dimensioni di conseguenza.

### Job non riuscito con l'errore «Failed to Retrieve Credentials xxx» visualizzato nel eks-pod-identity registro.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds-error"></a>

Una possibile causa di questo problema potrebbe essere che il cluster EKS è configurato in sottoreti private senza una configurazione PrivateLink corretta per il cluster. Verifica se il cluster si trova in una rete privata e configuralo AWS PrivateLink per risolvere il problema. Per istruzioni dettagliate, consulta la sezione Guida [introduttiva ad Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

# Opzione 2: abilitare IAM Roles for Service Accounts (IRSA) sul cluster EKS
<a name="setting-up-enable-IAM-service-accounts"></a>

La funzionalità dei ruoli IAM per gli account di servizio è disponibile per i nuovi cluster Amazon EKS con Kubernetes versione 1.14 e successiva e per i cluster EKS aggiornati alle versioni 1.13 o successiva dopo il 3 settembre 2019 incluso. Per poter utilizzare questa funzionalità, puoi aggiornare i cluster EKS esistenti alla versione 1.14 o successiva. Per ulteriori informazioni, consulta [Aggiornamento di una versione Kubernetes del cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).

Se supporta i ruoli IAM per gli account di servizio, il cluster è associato a un URL dell'emittente [OpenID Connect](https://openid.net/connect/). Puoi visualizzare questo URL nella console Amazon EKS oppure puoi utilizzare il seguente AWS CLI comando per recuperarlo.

**Importante**  
È necessario utilizzare la versione più recente di AWS CLI per ricevere l'output corretto da questo comando.

```
aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text
```

L'output previsto è il seguente:

```
https://oidc.eks.<region-code>.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E
```

Per utilizzare i ruoli IAM per gli account di servizio nel cluster è necessario creare un provider di identità OIDC utilizzando [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) o la [Console di gestione AWS](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console).

## Creazione di un provider di identità IAM OIDC per il cluster con `eksctl`
<a name="setting-up-OIDC-eksctl"></a>

Controlla la versione della `eksctl` con il comando seguente. Questa procedura presuppone che `eksctl` sia installato e che la versione di `eksctl` sia 0.32.0 o successiva.

```
eksctl version
```

Per ulteriori informazioni sull'installazione o sull'aggiornamento di eksctl, consulta [Installazione o aggiornamento di eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl).

Crea il provider di identità OIDC per il cluster con il comando seguente. Sostituire *cluster\$1name* con il proprio valore.

```
eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve
```

## Per creare un provider di identità IAM OIDC per il cluster con Console di gestione AWS
<a name="setting-up-OIDC-console"></a>

Recupera l'URL dell'emittente OIDC dalla descrizione della console Amazon EKS del cluster o usa il seguente comando. AWS CLI 

Utilizza il seguente comando per recuperare l'URL dell'emittente OIDC dalla AWS CLI.

```
aws eks describe-cluster --name <cluster_name> --query "cluster.identity.oidc.issuer" --output text
```

Utilizza la seguente procedura per recuperare l'URL dell'emittente OIDC dalla console Amazon EKS. 

1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Nel pannello di navigazione, scegli **Identity Providers (Provider di identità)**, quindi seleziona **Create Provider (Crea provider)**.

   1. Per **Tipo di provider**, seleziona **Scegli un tipo di provider** e quindi **OpenID Connect**.

   1. Per **URL provider**, incolla l'URL dell'emittente OIDC del cluster.

   1. Per Audience (Pubblico), digita sts.amazonaws.com e scegli **Next Step (Fase successiva)**.

1. Verifica che le informazioni del provider siano corrette, quindi seleziona **Crea** per creare il provider di identità.

# Creazione di un ruolo di esecuzione di processo
<a name="creating-job-execution-role"></a>

Per eseguire carichi di lavoro su Amazon EMR su EKS, occorre creare un ruolo IAM. Nella presente documentazione, tale ruolo viene definito *ruolo di esecuzione di processo*. Per ulteriori informazioni su come creare ruoli IAM, consulta [Creazione di ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) nella Guida per l'utente IAM. 

È necessario anche creare una policy IAM che specifichi le autorizzazioni per il ruolo di esecuzione di processo e, successivamente, collegare la policy IAM al ruolo di esecuzione di processo. 

La seguente politica per il ruolo di esecuzione del lavoro consente l'accesso a destinazioni di risorse, Amazon S3 e. CloudWatch Queste autorizzazioni sono necessarie per monitorare i processi e i log di accesso. Per seguire la stessa procedura, utilizza: AWS CLI

Creazione del ruolo IAM per l'esecuzione del lavoro: creiamo il ruolo che EMR utilizzerà per l'esecuzione del lavoro. Questo è il ruolo che i lavori EMR assumeranno quando verranno eseguiti su EKS.

```
cat <<EoF > ~/environment/emr-trust-policy.json
 {
   "Version": "2012-10-17",		 	 	 
   "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "Service": "elasticmapreduce.amazonaws.com"
       },
       "Action": "sts:AssumeRole"
     }
   ]
 }
 EoF
  
 aws iam create-role --role-name EMRContainers-JobExecutionRole --assume-role-policy-document file://~/environment/emr-trust-policy.json
```

Successivamente, dobbiamo collegare le politiche IAM richieste al ruolo in modo che possa scrivere i log su s3 e cloudwatch.

```
cat <<EoF > ~/environment/EMRContainers-JobExecutionRole.json
 {
     "Version": "2012-10-17",		 	 	 
     "Statement": [
         {
             "Effect": "Allow",
             "Action": [
                 "s3:PutObject",
                 "s3:GetObject",
                 "s3:ListBucket"
             ],
             "Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
         },
         {
             "Effect": "Allow",
             "Action": [
                 "logs:PutLogEvents",
                 "logs:CreateLogStream",
               "logs:DescribeLogGroups",
                 "logs:DescribeLogStreams"
             ],
             "Resource": [
                 "arn:aws:logs:*:*:*"
             ]
         }
     ]
 } 
 EoF
 aws iam put-role-policy --role-name EMRContainers-JobExecutionRole --policy-name EMR-Containers-Job-Execution --policy-document file://~/environment/EMRContainers-JobExecutionRole.json
```

**Nota**  
L'accesso deve essere compreso in modo appropriato, non concesso a tutti gli oggetti S3 nel ruolo di esecuzione di processo.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket"
      ],
      "Sid": "AllowS3Putobject"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:PutLogEvents",
        "logs:CreateLogStream",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "arn:aws:logs:*:*:*"
      ],
      "Sid": "AllowLOGSPutlogevents"
    }
  ]
}
```

------

Per ulteriori informazioni, consulta [Usare i ruoli di esecuzione dei job](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html), [Configurare un job run per utilizzare i log di S3 e [Configurare un](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch) job run per usare Logs](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3). CloudWatch 

# Aggiornamento della policy di affidabilità del ruolo di esecuzione di processo
<a name="setting-up-trust-policy"></a>

Quando si utilizzano ruoli IAM per gli account di servizio (IRSA) per eseguire processi in uno spazio dei nomi Kubernetes, un amministratore deve creare una relazione di fiducia tra il ruolo di esecuzione di processo e l'identità dell'account del servizio gestito da EMR. La relazione di fiducia può essere creata aggiornando la policy di affidabilità del ruolo di esecuzione di processo. Ricorda che l'account di servizio gestito da EMR viene creato in automatico all'invio del processo, nell'ambito dello spazio dei nomi in cui viene inviato il processo.

Per aggiornare la policy di affidabilità, esegui il comando seguente:

```
 aws emr-containers update-role-trust-policy \
       --cluster-name cluster \
       --namespace namespace \
       --role-name iam_role_name_for_job_execution
```

Per ulteriori informazioni, consulta [Uso dei ruoli di esecuzione di processo con Amazon EMR su EKS](iam-execution-role.md).

**Importante**  
L'operatore che esegue il comando precedente deve disporre delle seguenti autorizzazioni: `eks:DescribeCluster`, `iam:GetRole` e `iam:UpdateAssumeRolePolicy`.