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

# Ruoli IAM per gli account di servizio
<a name="iam-roles-for-service-accounts"></a>

**Suggerimento**  
 [Registrati](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) ai prossimi workshop Amazon EKS.

Le applicazioni nei contenitori di un Pod possono utilizzare un AWS SDK o la AWS CLI per effettuare richieste API AWS ai servizi AWS utilizzando le autorizzazioni Identity and Access Management (IAM). Le applicazioni devono firmare le proprie richieste AWS API con credenziali. AWS **I ruoli IAM per gli account di servizio (IRSA)** offrono la possibilità di gestire le credenziali per le applicazioni, in modo simile al modo in cui i profili di EC2 istanza Amazon forniscono le credenziali alle istanze Amazon. EC2 Invece di creare e distribuire AWS le tue credenziali ai contenitori o utilizzare il ruolo dell' EC2 istanza Amazon, associ un ruolo IAM a un account di servizio Kubernetes e configuri i tuoi Pods per utilizzare l'account di servizio. Non puoi utilizzare i ruoli IAM per gli account di servizio con [cluster locali per Amazon EKS on AWS Outposts](eks-outposts-local-cluster-overview.md).

La caratteristica dei ruoli IAM per gli account di servizio offre i seguenti vantaggi:
+  **Privilegio minimo**: è possibile definire l’ambito delle autorizzazioni IAM per un account di servizio; solo i pod che utilizzano tale account avranno accesso alle autorizzazioni definite. Questa caratteristica elimina anche la necessità di soluzioni di terze parti, ad esempio `kiam` o `kube2iam`.
+  **Isolamento delle credenziali**: quando l'accesso all'[Amazon EC2 Instance Metadata Service (IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) è limitato, i contenitori di un Pod possono recuperare solo le credenziali per il ruolo IAM associato all'account di servizio utilizzato dal contenitore. Un container non ha mai accesso alle credenziali utilizzate da altri container in altri pod. Se IMDS non è soggetto a restrizioni, i container del pod hanno accesso anche al [ruolo IAM del nodo Amazon EKS](create-node-role.md) potrebbero essere in grado di accedere alle credenziali dei ruoli IAM di altri pod sullo stesso nodo. Per ulteriori informazioni, consulta [Limitazione dell’accesso al profilo dell’istanza assegnato al nodo worker](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations).

**Nota**  
I pod configurati con `hostNetwork: true` avranno sempre accesso IMDS, ma la AWS SDKs CLI e la CLI utilizzeranno le credenziali IRSA quando abilitate.
+  **Verificabilità: la registrazione degli accessi e degli eventi è disponibile per garantire un controllo** retrospettivo. AWS CloudTrail 

**Importante**  
I container non costituiscono un limite di sicurezza e l’uso dei ruoli IAM per gli account di servizio non cambia questa situazione. I pod assegnati allo stesso nodo condivideranno un kernel e potenzialmente altre risorse a seconda della configurazione del pod. Sebbene i pod in esecuzione su nodi separati siano isolati a livello di elaborazione, esistono applicazioni di nodo che dispongono di autorizzazioni aggiuntive nell’API Kubernetes oltre all’ambito di una singola istanza. Alcuni esempi sono `kubelet`, `kube-proxy`, i driver di archiviazione CSI o le tue applicazioni Kubernetes.

Abilita i ruoli IAM per gli account di servizio completando le seguenti procedure:

1.  [Creazione di un provider OIDC IAM per il cluster](enable-iam-roles-for-service-accounts.md): questa operazione viene completata solo una sola volta per cluster.
**Nota**  
Se è stato abilitato l’endpoint VPC EKS, non è possibile accedere all’endpoint del servizio OIDC EKS dall’interno di tale VPC. Di conseguenza, le operazioni come la creazione di un provider OIDC con `eksctl` nel VPC non funzioneranno e comporteranno un timeout durante il tentativo di richiesta di `https://oidc.eks.region.amazonaws.com`. Segue un messaggio di errore di esempio:  

   ```
   server cant find oidc.eks.region.amazonaws.com: NXDOMAIN
   ```
Per completare questo passaggio, puoi eseguire il comando all'esterno del VPC, ad esempio in AWS CloudShell o su un computer connesso a Internet. In alternativa, puoi creare un resolver condizionale di tipo split-horizon nel VPC, come il risolutore Route 53, per utilizzare un resolver diverso per l’URL emittente OIDC e non utilizzare il DNS VPC. [Per un esempio di inoltro condizionale in CoredNS, consulta la richiesta di funzionalità Amazon EKS su.](https://github.com/aws/containers-roadmap/issues/2038) GitHub

1.  [Assegna i ruoli IAM agli account del servizio Kubernetes](associate-service-account-role.md): completa questa procedura per ogni set univoco di autorizzazioni che desideri abbia un’applicazione.

1.  [Configura i Pod per utilizzare un account di servizio Kubernetes](pod-configuration.md): completa questa procedura per ogni Pod che deve accedere ai servizi. AWS 

1.  [Usa IRSA con l' AWS SDK: conferma che il](iam-roles-for-service-accounts-minimum-sdk.md) carico di lavoro utilizzi un AWS SDK di una versione supportata e che il carico di lavoro utilizzi la catena di credenziali predefinita.

## Informazioni di base su IAM, Kubernetes e OpenID Connect (OIDC)
<a name="irsa-oidc-background"></a>

Nel 2014, AWS Identity and Access Management ha aggiunto il supporto per le identità federate utilizzando OpenID Connect (OIDC). Questa funzionalità consente di autenticare le chiamate AWS API con i provider di identità supportati e di ricevere un token web JSON (JWT) OIDC valido. Puoi passare questo token all'operazione `AssumeRoleWithWebIdentity` API AWS STS e ricevere credenziali di ruolo temporaneo IAM. Puoi utilizzare queste credenziali per interagire con qualsiasi AWS servizio, inclusi Amazon S3 e DynamoDB.

Ogni token JWT è firmato da una coppia di chiavi di firma. Le chiavi vengono fornite dal provider OIDC gestito da Amazon EKS e la chiave privata ruota ogni 7 giorni. Amazon EKS conserva le chiavi pubbliche fino alla loro scadenza. Se si connettono client OIDC esterni, si tenga presente che è necessario aggiornare le chiavi di firma prima della scadenza della chiave pubblica. Scopri [Fetch signing keys to validate OIDC tokens](irsa-fetch-keys.md).

Kubernetes utilizza da tempo gli account di servizio come sistema di identità interno. I pod possono eseguire l’autenticazione con il server API Kubernetes utilizzando un token con montaggio automatico (che è un token JWT non OIDC) che solo il server API Kubernetes può convalidare. Questi token legacy dell’account di servizio non hanno scadenza e la rotazione della chiave di firma è un processo difficile. Nella versione `1.12` di Kubernetes, è stato aggiunto il supporto per una nuova funzionalità `ProjectedServiceAccountToken`. Questa funzionalità è un token Web OIDC JSON che contiene anche l’identità dell’account del servizio e supporta un pubblico configurabile.

Amazon EKS ora ospita un endpoint di rilevamento OIDC pubblico per ogni cluster, contenente le chiavi di firma per i token Web `ProjectedServiceAccountToken` JSON, in modo che i sistemi esterni, ad esempio IAM, possano convalidare e accettare i token OIDC emessi da Kubernetes.

# Per creare un provider di identità IAM OIDC per il cluster
<a name="enable-iam-roles-for-service-accounts"></a>

Il cluster ha un URL emittente [OpenID Connect](https://openid.net/connect/) (OIDC) associato. Per utilizzare i ruoli AWS Identity and Access Management (IAM) per gli account di servizio, deve esistere un provider IAM OIDC per l'URL dell'emittente OIDC del cluster.

## Prerequisiti
<a name="_prerequisites"></a>
+ Un cluster Amazon EKS esistente. Per implementarne uno, consulta [Nozioni di base su Amazon EKS](getting-started.md).
+ Versione `2.12.3` o successiva o versione `1.27.160` o successiva dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo o. AWS CloudShell Per verificare la versione attuale, usa `aws --version | cut -d / -f2 | cut -d ' ' -f1`. I gestori di pacchetti come `yum` Homebrew per macOS sono spesso diverse versioni dell'ultima versione della CLI AWS . `apt-get` Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [configurazione rapida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella Guida per l'utente dell'*interfaccia a riga di AWS comando*. La versione AWS CLI installata in AWS CloudShell potrebbe anche contenere diverse versioni precedenti alla versione più recente. Per aggiornarlo, consulta [Installazione della AWS CLI nella tua home directory nella Guida per](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) l'* AWS CloudShell utente*.
+ Lo strumento a riga di comando `kubectl` è installato sul dispositivo o AWS CloudShell. La versione può essere uguale oppure immediatamente precedente o successiva alla versione di Kubernetes del cluster. Ad esempio, se la versione del cluster è `1.29`, puoi usare `kubectl` versione `1.28`, `1.29` o `1.30`. Per installare o aggiornare `kubectl`, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md):
+ Un file `kubectl` `config` esistente che contiene la configurazione del cluster. Per creare un file `kubectl` `config`, consulta [Connettere kubectl a un cluster EKS creando un file kubeconfig](create-kubeconfig.md).

È possibile creare un gestore OIDC IAM per il cluster utilizzando `eksctl` o la Console di gestione AWS.

## Creare un gestore OIDC (eksctl)
<a name="_create_oidc_provider_eksctl"></a>

1. La versione `0.215.0` o quelle successive dello strumento a riga di comando `eksctl` deve essere installata sul dispositivo o nella AWS CloudShell. Per l’installazione o l’aggiornamento di `eksctl`, consulta la sezione [Installation](https://eksctl.io/installation) nella documentazione di `eksctl`.

1. Determinare l’ID dell’emittente OIDC per il cluster.

   Recuperare gli ID dell’emittente OIDC del cluster e archiviarlo in una variabile. Sostituire `<my-cluster>` con il proprio valore.

   ```
   cluster_name=<my-cluster>
   oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
   echo $oidc_id
   ```

1. Determinare se un gestore OIDC IAM con l’ID del cluster è già presente nell’account.

   ```
   aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
   ```

   Se viene restituito un output, il cluster dispone già di un gestore OIDC IAM ed è possibile saltare al passaggio successivo. Se non viene restituito alcun output, devi creare un provider OIDC IAM per il cluster.

1. Creare un provider di identità OIDC IAM per il cluster con il comando seguente.

   ```
   eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve
   ```
**Nota**  
Se è stato abilitato l’endpoint VPC EKS, non è possibile accedere all’endpoint del servizio OIDC EKS dall’interno di tale VPC. Di conseguenza, operazioni come la creazione di un gestore OIDC con `eksctl` nel VPC non funzioneranno e comporteranno un timeout. Segue un messaggio di errore di esempio:  

   ```
   ** server cant find oidc.eks.<region-code>.amazonaws.com: NXDOMAIN
   ```

   Per completare questo passaggio, puoi eseguire il comando all'esterno del VPC, ad esempio in AWS CloudShell o su un computer connesso a Internet. In alternativa, puoi creare un resolver condizionale di tipo split-horizon nel VPC, come il risolutore Route 53, per utilizzare un resolver diverso per l’URL emittente OIDC e non utilizzare il DNS VPC. [Per un esempio di inoltro condizionale in CoredNS, consulta la richiesta di funzionalità Amazon EKS su.](https://github.com/aws/containers-roadmap/issues/2038) GitHub

## Crea un provider OIDC (Console)AWS
<a name="create_oidc_provider_shared_aws_console"></a>

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

1. Nel riquadro a sinistra, seleziona **Cluster**, quindi seleziona il nome del cluster nella pagina **Cluster**.

1. Nella sezione **Dettagli** della scheda **Panoramica**, annota il valore dell'**URL del provider OpenID Connect**.

1. Apri la console IAM all'indirizzo. https://console.aws.amazon.com/iam/

1. Nel pannello di navigazione, scegli **Identity Providers** (Provider di identità) in **Access management** (Gestione accesso). Se un **Provider** nell'elenco corrisponde all'URL del cluster, significa che si dispone già di un provider per il cluster. Se nell’elenco non è presente un gestore che corrisponde all’URL del cluster, è necessario crearne uno.

1. Per creare un provider, selezionare **Aggiungi provider**.

1. Per **Tipo di provider**, selezionare **OpenID Connect**.

1. Per **URL provider**, inserire l’URL del gestore OIDC del cluster.

1. Per **Destinatari**, inserisci `sts.amazonaws.com`

1. (Facoltativo) Aggiungere eventuali tag, ad esempio un tag per identificare quale cluster è assegnato a questo gestore.

1. Scegli **Aggiungi provider**.

Fase successiva: [Assegnare ruoli IAM agli account di servizio Kubernetes](associate-service-account-role.md) 

# Assegnare ruoli IAM agli account di servizio Kubernetes
<a name="associate-service-account-role"></a>

Questo argomento spiega come configurare un account di servizio Kubernetes per assumere un ruolo AWS Identity and Access Management (IAM). Tutti i Pod configurati per utilizzare l'account di servizio possono quindi accedere a qualsiasi AWS servizio a cui il ruolo dispone delle autorizzazioni per accedere.

## Prerequisiti
<a name="_prerequisites"></a>
+ Un cluster esistente. Se non ne possiedi già uno, crealo seguendo una delle guide in [Nozioni di base su Amazon EKS](getting-started.md).
+ Creare un provider di identità OpenID Connect (OIDC) IAM per il cluster. Per sapere se disponi di un account o, per crearne uno, consulta [Per creare un provider di identità IAM OIDC per il cluster](enable-iam-roles-for-service-accounts.md).
+ Versione `2.12.3` o successiva o versione `1.27.160` o successiva dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo o. AWS CloudShell Per verificare la versione attuale, usa `aws --version | cut -d / -f2 | cut -d ' ' -f1`. I gestori di pacchetti come `yum` Homebrew per macOS sono spesso diverse versioni dell'ultima versione della CLI AWS . `apt-get` Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [configurazione rapida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella Guida per l'utente dell'*interfaccia a riga di AWS comando*. La versione AWS CLI installata in AWS CloudShell potrebbe anche contenere diverse versioni precedenti alla versione più recente. Per aggiornarlo, consulta [Installazione della AWS CLI nella tua home directory nella Guida per](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) l'* AWS CloudShell utente*.
+ Lo strumento a riga di comando `kubectl` è installato sul dispositivo o AWS CloudShell. La versione può essere uguale oppure immediatamente precedente o successiva alla versione di Kubernetes del cluster. Ad esempio, se la versione del cluster è `1.29`, puoi usare `kubectl` versione `1.28`, `1.29` o `1.30`. Per installare o aggiornare `kubectl`, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md):
+ Un file `kubectl` `config` esistente che contiene la configurazione del cluster. Per creare un file `kubectl` `config`, consulta [Connettere kubectl a un cluster EKS creando un file kubeconfig](create-kubeconfig.md).

## Fase 1: creare la policy IAM
<a name="irsa-associate-role-procedure"></a>

Se desideri associare una policy IAM esistente al ruolo IAM, passa al prossimo passaggio.

1. Creare una policy IAM Puoi creare la tua policy o copiare una policy AWS gestita che già concede alcune delle autorizzazioni di cui hai bisogno e personalizzarla in base alle tue esigenze specifiche. Per ulteriori informazioni, consulta [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) nella *Guida per l’utente di IAM*.

1. Crea un file che includa le autorizzazioni per i AWS servizi a cui desideri che i tuoi Pod accedano. Per un elenco di tutte le azioni per tutti i AWS servizi, consulta il [Service Authorization](https://docs.aws.amazon.com/service-authorization/latest/reference/) Reference.

   Puoi eseguire il comando seguente per creare un file policy di esempio che consenta l’accesso in sola lettura a un bucket Amazon S3. Facoltativamente, puoi archiviare le informazioni di configurazione o uno script di bootstrap in questo bucket; i container nel pod possono leggere il file dal bucket e caricarlo nell’applicazione. Se desideri creare questa policy di esempio, copia i seguenti contenuti sul dispositivo. Sostituiscilo *my-pod-secrets-bucket* con il nome del tuo bucket ed esegui il comando.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
           }
       ]
   }
   ```

1. Creare la policy IAM.

   ```
   aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
   ```

## Fase 2: creare e associare il ruolo IAM
<a name="_step_2_create_and_associate_iam_role"></a>

Creare un ruolo IAM e associarlo a un account di servizio Kubernetes. È possibile utilizzare uno dei due `eksctl` o la AWS CLI.

### Creare e associare il ruolo (eksctl)
<a name="_create_and_associate_role_eksctl"></a>

Questo comando `eksctl` crea un account di servizio Kubernetes nel namespace specificato, crea un ruolo IAM (se non esiste) con il nome specificato, allega un ARN della policy IAM esistente al ruolo e annota l’account di servizio con l’ARN del ruolo IAM. Assicurati di sostituire i valori segnaposto di esempio in questo comando con i valori specifici. Per l’installazione o l’aggiornamento di `eksctl`, consulta la sezione [Installation](https://eksctl.io/installation) nella documentazione di `eksctl`.

```
eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name my-role \
    --attach-policy-arn arn:aws: iam::111122223333:policy/my-policy --approve
```

**Importante**  
Se il ruolo o l’account del servizio esiste già, il comando precedente potrebbe non riuscire. `eksctl` ha diverse opzioni che puoi fornire in queste situazioni. Per ulteriori informazioni, esegui `eksctl create iamserviceaccount --help`.

### Creazione e associazione di ruoli (AWS CLI)
<a name="create_and_associate_role_shared_aws_cli"></a>

Se disponi di un account di servizio Kubernetes esistente che deve assumere un ruolo IAM, puoi saltare questa fase.

1. Creare un account di servizio Kubernetes. Copia i seguenti contenuti sul dispositivo. Sostituiscilo *my-service-account* con il nome desiderato e *default* con un namespace diverso, se necessario. Se si modifica*default*, lo spazio dei nomi deve già esistere.

   ```
   cat >my-service-account.yaml <<EOF
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-service-account
     namespace: default
   EOF
   kubectl apply -f my-service-account.yaml
   ```

1. Imposta l'ID AWS del tuo account su una variabile di ambiente con il seguente comando.

   ```
   account_id=$(aws sts get-caller-identity --query "Account" --output text)
   ```

1. Imposta il provider di identità OIDC del cluster su una variabile di ambiente con il comando seguente. Sostituisci *my-cluster* con il nome del cluster.

   ```
   oidc_provider=$(aws eks describe-cluster --name my-cluster --region $AWS_REGION --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")
   ```

1. Imposta le variabili per lo spazio dei nomi e il nome dell'account del servizio. Sostituisci *my-service-account* con l'account del servizio Kubernetes che desideri assumere il ruolo. Sostituisci *default* con lo spazio dei nomi dell'account del servizio.

   ```
   export namespace=default
   export service_account=my-service-account
   ```

1. Per creare una policy di attendibilità del ruolo IAM, esegui il comando seguente. Se desideri consentire a tutti gli account di servizio all’interno di un namespace di utilizzare il ruolo, copia i seguenti contenuti sul dispositivo. Sostituisci *StringEquals* con `StringLike` e sostituisci *\$1service\$1account* con. `*` Puoi aggiungere più voci nelle condizioni `StringEquals` e `StringLike` riportate di seguito per utilizzare più account di servizio o namespace con il ruolo. Per consentire ai ruoli di un AWS account diverso da quello in cui si trova il cluster di assumere il ruolo, consulta [Eseguire l’autenticazione a un altro account con IRSA](cross-account-access.md) per ulteriori informazioni.

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "arn:aws:iam::123456789012:oidc-provider/$oidc_provider"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "$oidc_provider:aud": "sts.amazonaws.com",
             "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account"
           }
         }
       }
     ]
   }
   ```

1. Crea il ruolo. Sostituisci *my-role* con un nome per il ruolo IAM e *my-role-description* con una descrizione per il tuo ruolo.

   ```
   aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
   ```

1. Allegare una policy IAM al ruolo. Sostituisci *my-role* con il nome del ruolo IAM e *my-policy* con il nome di una policy esistente che hai creato.

   ```
   aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws: iam::$account_id:policy/my-policy
   ```

1. Annota l'account del servizio con il nome della risorsa Amazon (ARN) del ruolo IAM che desideri che l'account del servizio assuma. Sostituisci *my-role* con il nome del ruolo IAM esistente. Supponiamo di aver consentito a un ruolo di un AWS account diverso da quello in cui si trova il cluster di assumere il ruolo in un passaggio precedente. Quindi, assicurati di specificare l' AWS account e il ruolo dell'altro account. Per ulteriori informazioni, consulta [Eseguire l’autenticazione a un altro account con IRSA](cross-account-access.md).

   ```
   kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws: iam::$account_id:role/my-role
   ```

1. (Facoltativo) [Configura l'endpoint del servizio AWS Security Token per un account di servizio](configure-sts-endpoint.md). AWS consiglia di utilizzare un endpoint AWS STS regionale anziché un endpoint globale. Ciò riduce la latenza, fornisce una ridondanza integrata e aumenta la validità del token di sessione.

## Fase 3: confermare la configurazione
<a name="irsa-confirm-role-configuration"></a>

1. Confermare che la policy di attendibilità del ruolo IAM sia configurata correttamente.

   ```
   aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
   ```

   Di seguito viene riportato un output di esempio.

   ```
   {
       "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:sub": "system:serviceaccount:default:my-service-account",
                       "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
                   }
               }
           }
       ]
   }
   ```

1. Conferma che la policy che hai associato al tuo ruolo in un passaggio precedente sia associata al ruolo.

   ```
   aws iam list-attached-role-policies --role-name my-role --query "AttachedPolicies[].PolicyArn" --output text
   ```

   Di seguito viene riportato un output di esempio.

   ```
    arn:aws: iam::111122223333:policy/my-policy
   ```

1. Imposta una variabile per memorizzare il nome della risorsa Amazon (ARN) della policy che desideri utilizzare. Sostituiscilo *my-policy* con il nome della politica per cui desideri confermare le autorizzazioni.

   ```
   export policy_arn=arn:aws: iam::111122223333:policy/my-policy
   ```

1. Visualizza la versione predefinita della policy.

   ```
   aws iam get-policy --policy-arn $policy_arn
   ```

   Di seguito viene riportato un output di esempio.

   ```
   {
       "Policy": {
           "PolicyName": "my-policy",
           "PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
           "Arn": "arn:aws: iam::111122223333:policy/my-policy",
           "Path": "/",
           "DefaultVersionId": "v1",
           [...]
       }
   }
   ```

1. Visualizza il contenuto della policy per assicurarti che includa tutte le autorizzazioni di cui il pod ha bisogno. Se necessario, sostituiscilo *1* nel comando seguente con la versione restituita nell'output precedente.

   ```
   aws iam get-policy-version --policy-arn $policy_arn --version-id v1
   ```

   Di seguito viene riportato un output di esempio.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
           }
       ]
   }
   ```

   Se hai creato la policy di esempio in un passaggio precedente, il risultato è lo stesso. Se hai creato una politica diversa, il *example* contenuto è diverso.

1. Confermare che l’account di servizio Kubernetes sia annotato con il ruolo.

   ```
   kubectl describe serviceaccount my-service-account -n default
   ```

   Di seguito viene riportato un output di esempio.

   ```
   Name:                my-service-account
   Namespace:           default
   Annotations:         eks.amazonaws.com/role-arn: arn:aws: iam::111122223333:role/my-role
   Image pull secrets:  <none>
   Mountable secrets:   my-service-account-token-qqjfl
   Tokens:              my-service-account-token-qqjfl
   [...]
   ```

## Fasi successive
<a name="_next_steps"></a>
+  [Configurazione di pod per utilizzare un account di servizio Kubernetes](pod-configuration.md) 

# Configurazione di pod per utilizzare un account di servizio Kubernetes
<a name="pod-configuration"></a>

Se un Pod deve accedere ai AWS servizi, devi configurarlo per utilizzare un account di servizio Kubernetes. L'account di servizio deve essere associato a un ruolo AWS Identity and Access Management (IAM) con le autorizzazioni per accedere ai servizi AWS .
+ Un cluster esistente. Se non se ne possiede già uno, crearlo utilizzando una delle guide in [Nozioni di base su Amazon EKS](getting-started.md).
+ Creare un provider di identità OpenID Connect (OIDC) IAM per il cluster. Per sapere se disponi di un account o, per crearne uno, consulta [Per creare un provider di identità IAM OIDC per il cluster](enable-iam-roles-for-service-accounts.md).
+ Un account di servizio Kubernetes esistente associato a un ruolo IAM. L'account del servizio deve essere annotato con il nome della risorsa Amazon (ARN) del ruolo IAM. Al ruolo deve essere associata una policy IAM che contenga le autorizzazioni che desideri che i tuoi Pod abbiano per utilizzare i servizi. AWS Per ulteriori informazioni su come creare e configurare l'account e il ruolo del servizio, consulta [Assegnare ruoli IAM agli account di servizio Kubernetes](associate-service-account-role.md).
+ Versione `2.12.3` o successiva o versione `1.27.160` o successiva dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo o. AWS CloudShell Per verificare la versione attuale, usa `aws --version | cut -d / -f2 | cut -d ' ' -f1`. I gestori di pacchetti come `yum` Homebrew per macOS sono spesso diverse versioni dell'ultima versione della CLI AWS . `apt-get` Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [configurazione rapida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella Guida per l'utente dell'*interfaccia a riga di AWS comando*. La versione AWS CLI installata in AWS CloudShell potrebbe anche contenere diverse versioni precedenti alla versione più recente. Per aggiornarlo, consulta [Installazione della AWS CLI nella tua home directory nella Guida per](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) l'* AWS CloudShell utente*.
+ Lo strumento a riga di comando `kubectl` è installato sul dispositivo o AWS CloudShell. La versione può essere uguale oppure immediatamente precedente o successiva alla versione di Kubernetes del cluster. Ad esempio, se la versione del cluster è `1.29`, puoi usare `kubectl` versione `1.28`, `1.29` o `1.30`. Per installare o aggiornare `kubectl`, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md):
+ Un file `kubectl` `config` esistente che contiene la configurazione del cluster. Per creare un file `kubectl` `config`, consulta [Connettere kubectl a un cluster EKS creando un file kubeconfig](create-kubeconfig.md).

  1. Utilizza il seguente comando per creare un manifesto di implementazione per implementare un pod con cui confermare la configurazione. Sostituire i valori di esempio con i propri valori.

     ```
     cat >my-deployment.yaml <<EOF
     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: my-app
     spec:
       selector:
         matchLabels:
           app: my-app
       template:
         metadata:
           labels:
             app: my-app
         spec:
           serviceAccountName: my-service-account
           containers:
           - name: my-app
             image: public.ecr.aws/nginx/nginx:X.XX
     EOF
     ```

  1. Implementa il file manifesto al cluster.

     ```
     kubectl apply -f my-deployment.yaml
     ```

  1. Verifica che le variabili di ambiente richieste esistano per i pod.

     1. Visualizza i pod distribuiti con l’implementazione nella fase precedente.

        ```
        kubectl get pods | grep my-app
        ```

        Di seguito viene riportato un output di esempio.

        ```
        my-app-6f4dfff6cb-76cv9   1/1     Running   0          3m28s
        ```

     1. Visualizza l’ARN del ruolo IAM che il pod sta utilizzando.

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_ROLE_ARN:
        ```

        Di seguito viene riportato un output di esempio.

        ```
        AWS_ROLE_ARN: arn:aws: iam::111122223333:role/my-role
        ```

        Il ruolo ARN deve corrispondere al ruolo ARN con cui hai annotato l'account del servizio esistente. Per ulteriori informazioni sull'annotazione dell'account del servizio, consulta [Assegnare ruoli IAM agli account di servizio Kubernetes](associate-service-account-role.md).

     1. Conferma che il pod abbia un file di token di identità web montato.

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_WEB_IDENTITY_TOKEN_FILE:
        ```

        Di seguito viene riportato un output di esempio.

        ```
        AWS_WEB_IDENTITY_TOKEN_FILE:  /var/run/secrets/eks.amazonaws.com/serviceaccount/token
        ```

        `kubelet` richiede e memorizza il token per conto del pod. Per impostazione predefinita, la `kubelet` aggiorna il token se è più vecchio dell'80% del suo tempo totale di vita o se il token è più vecchio di 24 ore. È possibile modificare la durata di scadenza per qualsiasi account, ad eccezione dell’account di servizio predefinito, con le impostazioni nelle specifiche del pod. Per ulteriori informazioni, consultare [Proiezione Volume Token Acount di Servizio](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection) nella documentazione di Kubernetes.

        Il [Webhook di Pod Identity di Amazon EKS](https://github.com/aws/amazon-eks-pod-identity-webhook#amazon-eks-pod-identity-webhook) sugli orologi del cluster per pod che utilizzano un account di servizio con la seguente annotazione:

        ```
        eks.amazonaws.com/role-arn: arn:aws: iam::111122223333:role/my-role
        ```

        Il webhook applica le variabili di ambiente precedenti a questi pod. Il cluster non deve utilizzare il webhook per configurare le variabili di ambiente e i montaggi del file di token. È possibile configurare manualmente i pod per ottenere queste variabili di ambiente. Le [versioni supportate dell' AWS SDK](iam-roles-for-service-accounts-minimum-sdk.md) cercano innanzitutto queste variabili di ambiente nel provider della catena di credenziali. Le credenziali del ruolo sono utilizzate per i pod che soddisfano questi criteri.

  1. Verifica che i tuoi Pod possano interagire con i AWS servizi utilizzando le autorizzazioni assegnate nella policy IAM associata al tuo ruolo.
**Nota**  
Quando un Pod utilizza AWS le credenziali di un ruolo IAM associato a un account di servizio, la AWS CLI o SDKs altro nei contenitori per quel Pod utilizza le credenziali fornite da quel ruolo. Se non si limita l’accesso alle credenziali fornite al [ruolo IAM del nodo di Amazon EKS](create-node-role.md), il pod ha comunque accesso a tali credenziali. Per ulteriori informazioni, consulta [Limita l’accesso al profilo dell’istanza assegnato al nodo (worker)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

     Se il tuo pod non riesce a interagire con i servizi come previsto, completa i seguenti passaggi per confermare che tutto sia configurato correttamente.

     1. Verifica che i tuoi Pod utilizzino una versione AWS SDK che supporti l'assunzione di un ruolo IAM tramite un file di token di identità web OpenID Connect. Per ulteriori informazioni, consulta [Usa IRSA con AWS SDK](iam-roles-for-service-accounts-minimum-sdk.md).

     1. Conferma che l'implementazione stia utilizzando l'account del servizio.

        ```
        kubectl describe deployment my-app | grep "Service Account"
        ```

        Di seguito viene riportato un output di esempio.

        ```
        Service Account:  my-service-account
        ```

     1. Se i tuoi pod non riescono ancora ad accedere ai servizi, controlla i [passaggi](associate-service-account-role.md#irsa-confirm-role-configuration) descritti in [Assign IAM roles to Kubernetes service accounts](associate-service-account-role.md) per confermare che il ruolo e l’account del servizio siano configurati correttamente.

# Configurare l’endpoint del Servizio di token di sicurezza AWS per un account di servizio
<a name="configure-sts-endpoint"></a>

Se si utilizza un account di servizio Kubernetes con [ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md), è possibile configurare il tipo di endpoint del Servizio di token di sicurezza AWS utilizzato dall’account di servizio.

 AWS consiglia di utilizzare gli endpoint AWS STS Regionali anziché l’endpoint globale. Ciò riduce la latenza, fornisce una ridondanza integrata e aumenta la validità del token di sessione. Il Servizio di token di sicurezza AWS deve essere attivo nella Regione AWS in cui viene eseguito il pod. Inoltre, l’applicazione deve avere una ridondanza incorporata per una Regione AWS diversa nel caso di un guasto del servizio nella Regione AWS iniziale. Per ulteriori informazioni, consultare [Managing AWS STS in an AWS Region](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) nella Guida per l’utente di IAM.
+ Un cluster esistente. Se non se ne possiede già uno, crearlo utilizzando una delle guide in [Nozioni di base su Amazon EKS](getting-started.md).
+ Provider OIDC IAM esistente per il cluster. Per ulteriori informazioni, consulta [Per creare un provider di identità IAM OIDC per il cluster](enable-iam-roles-for-service-accounts.md).
+ Un account del servizio Kubernetes esistente configurato per l'uso con la funzionalità [Ruoli IAM di Amazon EKS per gli account di servizio](iam-roles-for-service-accounts.md).

Tutti gli esempi seguenti utilizzano l’account di servizio Kubernetes aws-node utilizzato dal [plugin CNI di Amazon VPC](cni-iam-role.md). I *valori di esempio* possono essere sostituiti con gli account di servizio, i pod, i namespace e altre risorse personalizzate.

1. Selezionare un pod che utilizza un account di servizio per il quale si desidera modificare l’endpoint. Determinare in quale Regione AWS viene eseguito il pod. Sostituire *aws-node-6mfgv* con il namespace e *kube-system* con il namespace del pod.

   ```
   kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:
   ```

   Di seguito viene riportato un output di esempio:

   ```
   ip-192-168-79-166.us-west-2/192.168.79.166
   ```

   Nell’output precedente, il pod è in esecuzione su un nodo nella Regione AWS us-west-2.

1. Determinare il tipo di endpoint utilizzato dall’account di servizio del pod.

   ```
   kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
   ```

   Di seguito viene riportato un output di esempio:

   ```
   AWS_STS_REGIONAL_ENDPOINTS: regional
   ```

   Se l'endpoint attuale è globale, l'output restituisce `global`. Se non viene restituito alcun output, il tipo di endpoint predefinito è in uso e non è stato sovrascritto.

1. Se le versioni del cluster e della piattaforma corrispondono o sono successive a quelle elencate nella tabella, puoi modificare il tipo di endpoint utilizzato dall'account del servizio dal tipo predefinito con un tipo diverso tramite uno dei comandi seguenti. Sostituisci *aws-node* con il nome dell'account del servizio e *kube-system* con lo spazio dei nomi dell'account del servizio.
   + Se il tipo di endpoint predefinito o attuale è globale e vuoi modificarlo in regionale:

     ```
     kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true
     ```

     Se si utilizzano i [ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md) per generare URL S3 prefirmati nell’applicazione in esecuzione nei container dei pod, il formato dell’URL per gli endpoint Regionali è simile al seguente esempio:

     ```
     https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
     ```
   + Se il tipo di endpoint predefinito o attuale è regionale e vuoi modificarlo in globale:

     ```
     kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false
     ```

     Se l’applicazione sta effettuando esplicitamente richieste agli endpoint AWS STS globali e non si sostituisce il comportamento predefinito di utilizzo degli endpoint Regionali in cluster Amazon EKS, le richieste avranno esito negativo e restituiranno un codice di errore. Per ulteriori informazioni, consulta [I container dei pod riceveranno il seguente errore: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`](security-iam-troubleshoot.md#security-iam-troubleshoot-wrong-sts-endpoint).

     Se si utilizzano i [ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md) per generare URL S3 prefirmati nell’applicazione in esecuzione nei container dei pod, il formato dell’URL per gli endpoint globali è simile al seguente esempio:

     ```
     https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
     ```

   Se si dispone di un sistema di automazione che prevede un determinato formato per l’URL prefirmato o se l’applicazione o le dipendenze a valle che utilizzano gli URL prefirmati hanno aspettative per la Regione AWS di destinazione, apportare le modifiche necessarie per utilizzare l’endpoint AWS STS appropriato.

1. Eliminare e ricreare i pod esistenti associati all’account di servizio per applicare le variabili di ambiente delle credenziali. Il web hook di modifica non le applica ai pod già in esecuzione. È possibile sostituire *Pods*, *kube-system* e *-l k8s-app=aws-node* con le informazioni dei pod per cui viene impostata l’annotazione.

   ```
   kubectl delete Pods -n kube-system -l k8s-app=aws-node
   ```

1. Verificare che tutti i pod siano stati riavviati.

   ```
   kubectl get Pods -n kube-system -l k8s-app=aws-node
   ```

1. Visualizzare le variabili di ambiente per uno dei pod. Verifica che il valore `AWS_STS_REGIONAL_ENDPOINTS` sia quello che hai impostato in una fase precedente.

   ```
   kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
   ```

   Di seguito viene riportato un output di esempio:

   ```
   AWS_STS_REGIONAL_ENDPOINTS=regional
   ```

# 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

# Usa IRSA con AWS SDK
<a name="iam-roles-for-service-accounts-minimum-sdk"></a>

**Utilizzo delle credenziali**  
Per utilizzare le credenziali dei ruoli IAM per gli account di servizio (IRSA), il codice può usare qualsiasi AWS SDK per creare un client per un servizio AWS con un SDK e, per impostazione predefinita, l’SDK cercherà le credenziali per AWS Identity and Access Management da utilizzare in una catena di posizioni. I ruoli IAM per le credenziali degli account di servizio vengono utilizzati se non specifichi un provider di credenziali quando crei il client o inizializzi in altro modo l’SDK.

Questo perché i ruoli IAM per gli account di servizio sono stati aggiunti come passaggio nella catena di credenziali predefinita. Se i carichi di lavoro attualmente utilizzano credenziali che si trovano all’inizio della catena di credenziali, tali credenziali continueranno a essere utilizzate anche se configuri ruoli IAM per gli account di servizio per lo stesso carico di lavoro.

L’SDK scambia automaticamente il token OIDC dell’account di servizio con credenziali temporanee di Servizio di token di sicurezza AWS utilizzando l’azione `AssumeRoleWithWebIdentity`. Amazon EKS e questa azione SDK continuano a ruotare le credenziali temporanee rinnovandole prima della scadenza.

Quando utilizzi [Ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md), i container nei tuoi pod devono utilizzare una versione AWS SDK che supporta l’assunzione di un ruolo IAM tramite un file di token di identità web OpenID Connect. Accertati di utilizzare le seguenti versioni, o successive, per il tuo SDK AWS:
+ Java (versione 2) — [2.10.11](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.10.11) 
+ Java – [1.12.782](https://github.com/aws/aws-sdk-java/releases/tag/1.12.782) 
+  AWS SDK per Go v1 – [1.23.13](https://github.com/aws/aws-sdk-go/releases/tag/v1.23.13) 
+  AWS SDK per Go v2: supporto per tutte le versioni
+ Python (Boto3) — [1.9.220](https://github.com/boto/boto3/releases/tag/1.9.220) 
+ Python (botocore) — [1.12.200](https://github.com/boto/botocore/releases/tag/1.12.200) 
+  AWS CLI - [1.16.232](https://github.com/aws/aws-cli/releases/tag/1.16.232) 
+ Nodo: [2.525.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.525.0) e [3.27.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.27.0) 
+ Ruby — [3.58.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#3580-2019-07-01) 
+ C\$1\$1 — [1.7.174](https://github.com/aws/aws-sdk-cpp/releases/tag/1.7.174) 
+ .NET: [3,3.659.1](https://github.com/aws/aws-sdk-net/releases/tag/3.3.659.1) – Devi includere anche `AWSSDK.SecurityToken`.
+ PHP — [3.110.7](https://github.com/aws/aws-sdk-php/releases/tag/3.110.7) 

Molti componenti aggiuntivi popolari di Kubernetes, come [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), il [comando per instrada il traffico Internet col bilanciatore del carico AWS](aws-load-balancer-controller.md) e il [plug-in CNI di Amazon VPC per Kubernetes](cni-iam-role.md) supportano i ruoli IAM per gli account di servizio.

Per assicurarti che l’SDK utilizzato sia supportato, quando crei i container segui la procedura di installazione per il tuo SDK preferito disponibile in [Strumenti per costruire su AWS](https://aws.amazon.com/tools/).

## Considerazioni
<a name="_considerations"></a>

### Java
<a name="_java"></a>

Quando si utilizza Java, è *necessario* includere il modulo `sts` nel percorso della classe. Per ulteriori informazioni, consulta [WebIdentityTokenFileCredentialsProvider](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/WebIdentityTokenFileCredentialsProvider.html) nei documenti SDK Java.

# Recupera le chiavi di firma per convalidare i token OIDC
<a name="irsa-fetch-keys"></a>

Kubernetes rilascia un `ProjectedServiceAccountToken` a ciascun account di servizio Kubernetes. Questo token è un token OIDC, che è un tipo di token web JSON (JWT). Amazon EKS ora ospita un endpoint pubblico OIDC per ogni cluster che contiene le chiavi di firma per i token in modo che i sistemi esterni possano convalidarlo.

Per convalidare un `ProjectedServiceAccountToken`, devi recuperare le chiavi di firma pubbliche OIDC, chiamate anche set di chiavi Web JSON (JWKS). Utilizza queste chiavi nell’applicazione per convalidare il token. Ad esempio, puoi usare [PyJWT Python library](https://pyjwt.readthedocs.io/en/latest/) per convalidare i token utilizzando queste chiavi. Per ulteriori informazioni su `ProjectedServiceAccountToken`, consultare [Informazioni di base su IAM, Kubernetes e OpenID Connect (OIDC)](iam-roles-for-service-accounts.md#irsa-oidc-background).

## Prerequisiti
<a name="_prerequisites"></a>
+ Un provider OpenID Connect (OIDC) esistente di AWS Identity and Access Management (IAM) per il cluster. Per determinare se disponi già di un provider IAM o per crearne uno, consulta [Per creare un provider di identità IAM OIDC per il cluster](enable-iam-roles-for-service-accounts.md).
+  **AWS CLI**: uno strumento a riga di comando per usare i servizi AWS, tra cui Amazon EKS. Per ulteriori informazioni, consulta [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) nella Guida per l’utente dell’interfaccia a riga di comando AWS. Dopo aver installato AWS CLI, si consiglia di procedere anche con la configurazione. Per ulteriori informazioni, consulta [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella Guida per l’utente di AWS per l’interfaccia a guida di comando.

## Procedura
<a name="_procedure"></a>

1. Recupera l’URL OIDC del cluster Amazon EKS utilizzando AWS CLI.

   ```
   $ aws eks describe-cluster --name my-cluster --query 'cluster.identity.oidc.issuer'
   "https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE"
   ```

1. Recupera la chiave di firma pubblica usando curl o uno strumento simile. Il risultato è un [JSON Web Key Set (JWKS)](https://www.rfc-editor.org/rfc/rfc7517#section-5).
**Importante**  
Amazon EKS limita le chiamate all’endpoint OIDC. È necessario caricare nella cache la chiave di firma pubblica. Rispetta l’intestazione `cache-control` inclusa nella risposta.
**Importante**  
Amazon EKS ruota la chiave di firma OIDC ogni sette giorni.

   ```
   $ curl https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE/keys
   {"keys":[{"kty":"RSA","kid":"2284XXXX4a40","use":"sig","alg":"RS256","n":"wklbXXXXMVfQ","e":"AQAB"}]}
   ```