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

# Informazioni su come EKS Pod Identity consente ai pod di accedere ai servizi AWS
<a name="pod-identities"></a>

Le applicazioni nei container di un pod possono utilizzare un AWS SDK o AWS CLI per effettuare richieste API ai servizi AWS utilizzando le autorizzazioni AWS Identity and Access Management (IAM). Le applicazioni devono firmare le proprie richieste API AWS con le credenziali AWS.

 Le associazioni *EKS Pod Identity* forniscono la possibilità di gestire le credenziali per le applicazioni, analogamente al modo in cui i profili di istanza Amazon EC2 forniscono le credenziali alle istanze Amazon EC2. Invece di creare e distribuire le tue credenziali AWS ai container o utilizzare il ruolo dell’istanza Amazon EC2, associ un ruolo IAM a un account di servizio Kubernetes e configuri i tuoi pod per utilizzare l’account di servizio.

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/aUjJSorBE70?rel=0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/aUjJSorBE70?rel=0)


Ogni associazione EKS Pod Identity associa un ruolo a un account di servizio in uno spazio dei nomi nel cluster specificato. Se hai la stessa applicazione in più cluster, puoi creare associazioni identiche in ogni cluster senza modificare la policy di attendibilità del ruolo.

Se un pod utilizza un account di servizio con un'associazione, Amazon EKS imposta le variabili di ambiente nei container del pod. Le variabili di ambiente configurano AWS SDK, inclusa AWS CLI, per utilizzare le credenziali di EKS Pod Identity.

## Vantaggi delle associazioni EKS Pod Identity
<a name="pod-id-benefits"></a>

Le associazioni EKS Pod Identity offrono 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 al [servizio di metadati di istanza (IMDS) di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) è limitato, un container del pod può recuperare solo le credenziali per il ruolo IAM associato all’account del servizio che utilizza. 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) e i container 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 AWS SDK e CLI utilizzeranno le credenziali di Pod Identity quando abilitati.
+  **Verificabilità**: accesso e registrazione degli eventi sono disponibili tramite AWS CloudTrail per garantire controlli retrospettivi.

**Importante**  
I container non sono un limite di sicurezza e l’uso di Pod Identity non modifica questo aspetto. 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`, driver di archiviazione CSI o le tue applicazioni Kubernetes.

EKS Pod Identity è un metodo più semplice di [Ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md), in quanto non utilizza provider di identità OIDC. EKS Pod Identity presenta i seguenti miglioramenti:
+  **Operazioni indipendenti**: in molte organizzazioni, la creazione di provider di identità OIDC è una responsabilità di team diversi rispetto all’amministrazione dei cluster Kubernetes. EKS Pod Identity offre una netta separazione dei compiti, in cui tutta la configurazione delle associazioni EKS Pod Identity viene eseguita in Amazon EKS e tutta la configurazione delle autorizzazioni IAM viene eseguita in IAM.
+  **Riusabilità**: EKS Pod Identity utilizza un singolo principale IAM anziché principali separati per ogni cluster utilizzato dai ruoli IAM per gli account di servizio. L'amministratore IAM aggiunge il seguente principale alla policy di attendibilità di qualsiasi ruolo per renderlo utilizzabile da parte delle associazioni EKS Pod Identity.

  ```
              "Principal": {
                  "Service": "pods.eks.amazonaws.com"
              }
  ```
+  **Scalabilità**: ciascun set di credenziali temporanee è assunto dal servizio di autenticazione EKS in EKS Pod Identity, anziché da ciascun AWS SDK eseguito in ciascun pod. Quindi, si esegue Amazon EKS Pod Identity Agent su ogni nodo rilasciando le credenziali agli SDK. Pertanto, il carico si riduce a una volta per ciascun nodo e non è duplicato in ciascun pod. Per ulteriori dettagli del processo, consulta [Comprensione di come funziona EKS Pod Identity](pod-id-how-it-works.md).

Per ulteriori informazioni su come confrontare le due alternative, consulta [Concessione ai carichi di lavoro Kubernetes dell’accesso a AWS utilizzando gli account di servizio Kubernetes](service-accounts.md).

## Panoramica sulla configurazione delle associazioni EKS Pod Identity
<a name="pod-id-setup-overview"></a>

Attiva le associazioni EKS Pod Identity completando le seguenti procedure:

1.  [Configurazione dell’agente Amazon EKS Pod Identity](pod-id-agent-setup.md): completi questa procedura una sola volta per ogni cluster. Non è necessario completare questo passaggio se la modalità automatica EKS è abilitata sul cluster.

1.  [Assegnazione di un ruolo IAM a un account di servizio Kubernetes](pod-id-association.md): completa questa procedura per ciascun set univoco di autorizzazioni che desideri abbia un’applicazione.

1.  [Configura i pod per accedere ai AWS servizi con account di servizio](pod-id-configure-pods.md): completa questa procedura per ciascun pod che deve accedere ai servizi AWS.

1.  [Utilizzo di Pod Identity con SDK AWS](pod-id-minimum-sdk.md): verifica che il carico di lavoro utilizzi un AWS SDK di una versione supportata e che il carico di lavoro utilizzi la catena di credenziali predefinita.

## Limiti
<a name="pod-id-limits"></a>
+ Sono supportate fino a 5.000 associazioni EKS Pod Identity per cluster per mappare i ruoli IAM agli account di servizio Kubernetes.

## Considerazioni
<a name="pod-id-considerations"></a>
+  **Associazione del ruolo IAM**: ogni account di servizio Kubernetes in un cluster può essere associato a un ruolo IAM dello stesso account AWS del cluster. Per modificare il ruolo, modifica l’associazione EKS Pod Identity. Per l’accesso multi-account, delega l’accesso al ruolo utilizzando i ruoli IAM. Per ulteriori informazioni, consulta [Delegare l’accesso tra account AWS tramite i ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) nella *Guida per l’utente IAM*.
+  **Agente EKS Pod Identity**: l’agente Pod Identity è necessario per utilizzare EKS Pod Identity. L’agente funziona come Kubernetes `DaemonSet` sui nodi del cluster, fornendo credenziali solo ai pod sullo stesso nodo. Utilizza `hostNetwork` del nodo, la porta occupante `80` e `2703` sull’indirizzo locale del collegamento (`169.254.170.23` per IPv4, `[fd00:ec2::23]` per IPv6). Se IPv6 è disabilitato nel cluster, disabilita IPv6 per l’agente Pod Identity. Per ulteriori informazioni, consulta [Disabilitare IPv6 nell’agente EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-config-ipv6.html).
+  **Coerenza finale**: le associazioni EKS Pod Identity alla fine sono coerenti, con potenziali ritardi di diversi secondi dopo le chiamate API. Evita di creare o aggiornare associazioni in percorsi di codice critici e ad alta disponibilità. Esegui, invece, queste azioni in routine di inizializzazione o configurazione separate e meno frequenti. Per ulteriori informazioni, consulta [Gruppi di sicurezza per pod](https://docs.aws.amazon.com/eks/latest/best-practices/sgpp.html) nella *Guida alle best practice EKS*.
+  **Considerazioni sui proxy e sui gruppi di sicurezza**: per i pod che utilizzano un proxy, aggiungi `169.254.170.23` (IPv4) e `[fd00:ec2::23]` (IPv6) alle variabili di ambiente `no_proxy/NO_PROXY` per evitare richieste non riuscite all’agente EKS Pod Identity. Se utilizzi i gruppi di sicurezza per pods con il CNI di AWS VPC, imposta il flag `ENABLE_POD_ENI` su “vero” e il flag `POD_SECURITY_GROUP_ENFORCING_MODE` su “standard”. Per ulteriori informazioni, consulta [Assegnare di gruppi di sicurezza ai singoli pod](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html).

### Versioni del cluster EKS Pod Identity
<a name="pod-id-cluster-versions"></a>

Per utilizzare le associazioni EKS Pod Identity, il cluster deve avere una versione della piattaforma uguale o successiva a quella elencata nella tabella seguente o una versione Kubernetes successiva a quelle elencate nella tabella. Per trovare la versione consigliata di Amazon EKS Pod Identity Agent per una versione Kubernetes, consulta [Verifica la compatibilità delle versioni aggiuntive di Amazon EKS con un cluster](addon-compat.md).


| Versione di Kubernetes | Versione della piattaforma | 
| --- | --- | 
|  Versioni di Kubernetes non elencate  |  Tutte le versioni delle piattaforma supportate  | 
|   `1.28`   |   `eks.4`   | 

### Restrizioni di EKS Pod Identity
<a name="pod-id-restrictions"></a>

Le associazioni EKS Pod Identity sono disponibili in:
+ Versioni del cluster Amazon EKS elencate nell'argomento precedente [Versioni del cluster EKS Pod Identity](#pod-id-cluster-versions).
+ Nodi worker nel cluster che sono istanze Amazon EC2 di Linux.

Le associazioni EKS Pod Identity non sono disponibili in quanto segue:
+  AWS Outposts.
+ Amazon EKS Anywhere.
+ Cluster Kubernetes creati ed eseguiti su Amazon EC2. I componenti di EKS Pod Identity sono disponibili solo su Amazon EKS.

Non è possibile utilizzare le associazioni EKS Pod Identity con:
+ Pod che vengono eseguiti ovunque, tranne che su istanze Amazon EC2 di Linux. Pod Linux e Windows che sono eseguiti su AWS Fargate (Fargate) non sono supportati. I pod che vengono eseguiti su istanze Amazon EC2 di Windows non sono supportati.

# Comprensione di come funziona EKS Pod Identity
<a name="pod-id-how-it-works"></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.

Nei componenti aggiuntivi, come *i componenti aggiuntivi di Amazon EKS* e i controller, gli operatori e altri componenti aggiuntivi autogestiti, l'autore deve aggiornare il software per utilizzare gli SDK AWS più recenti. Per l'elenco della compatibilità tra EKS Pod Identity e i componenti aggiuntivi prodotti da Amazon EKS, consulta la sezione precedente [Restrizioni di EKS Pod Identity](pod-identities.md#pod-id-restrictions).

## Utilizzo delle associazioni EKS Pod Identity nel codice
<a name="pod-id-credentials"></a>

Nel codice, puoi utilizzare gli SDK AWS per accedere ai servizi AWS. Scrivi il codice per creare un client per un servizio AWS con un SDK e, per impostazione predefinita, l’SDK cerca in una catena di posizioni le credenziali per AWS Identity and Access Management da utilizzare. Dopo aver trovato credenziali valide, la ricerca viene interrotta. Per ulteriori informazioni sulle posizioni predefinite utilizzate, consulta [Catena di fornitori di credenziali](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) nella Guida di riferimento agli SDK e agli strumenti AWS.

Le associazioni EKS Pod Identity sono state aggiunte al *provider di credenziali del container*, che viene cercato in un passaggio nella catena di credenziali predefinita. Se i carichi di lavoro utilizzano attualmente credenziali che si trovano all'inizio della catena di credenziali, quest'ultime continuano a essere utilizzate anche se configuri un'associazione EKS Pod Identity per lo stesso carico di lavoro. In questo modo è possibile migrare in sicurezza da altri tipi di credenziali creando l'associazione prima di rimuovere le vecchie credenziali.

Il provider di credenziali del container assegna credenziali temporanee da un agente che viene eseguito su ogni nodo. In Amazon EKS, l'agente è Amazon EKS Pod Identity Agent e su Amazon Elastic Container Service l'agente è `amazon-ecs-agent`. Gli SDK utilizzano variabili di ambiente per individuare l'agente a cui connettersi.

Al contrario, *i ruoli IAM per gli account di servizio* forniscono un token di *identità Web* che AWS SDK deve scambiare con AWS Security Token Service utilizzando `AssumeRoleWithWebIdentity`.

## Come funziona un agente EKS Pod Identity con un pod
<a name="pod-id-agent-pod"></a>

1. Quando Amazon EKS avvia un nuovo pod che utilizza un account di servizio con un’associazione EKS Pod Identity, il cluster aggiunge il seguente contenuto al manifesto:

   ```
       env:
       - name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
         value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
       - name: AWS_CONTAINER_CREDENTIALS_FULL_URI
         value: "http://169.254.170.23/v1/credentials"
       volumeMounts:
       - mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/"
         name: eks-pod-identity-token
     volumes:
     - name: eks-pod-identity-token
       projected:
         defaultMode: 420
         sources:
         - serviceAccountToken:
             audience: pods.eks.amazonaws.com
             expirationSeconds: 86400 # 24 hours
             path: eks-pod-identity-token
   ```

1. Kubernetes seleziona su quale nodo eseguire il pod. Quindi, Amazon EKS Pod Identity Agent sul nodo utilizza l'azione [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) per recuperare le credenziali temporanee dall'API EKS Auth.

1. EKS Pod Identity Agent rende disponibili queste credenziali per gli SDK AWS che esegui all'interno dei container.

1. Utilizza l'SDK nell'applicazione senza specificare un provider di credenziali per utilizzare la catena di credenziali predefinita. In alternativa, specifica il provider di credenziali del container. Per ulteriori informazioni sulle posizioni predefinite utilizzate, consulta [Catena di fornitori di credenziali](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) nella Guida di riferimento agli SDK e agli strumenti AWS.

1. L'SDK utilizza le variabili di ambiente per connettersi all'EKS Pod Identity Agent e recuperare le credenziali.
**Nota**  
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 un'associazione EKS Pod Identity per lo stesso carico di lavoro.

# Configurazione dell’agente Amazon EKS Pod Identity
<a name="pod-id-agent-setup"></a>

Le associazioni Amazon EKS Pod Identity offrono la possibilità di gestire le credenziali per le tue applicazioni, in modo simile al modo in cui i profili di EC2 istanza Amazon 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.

**Suggerimento**  
Non è necessario installare l’agente EKS Pod Identity sui cluster in modalità automatica EKS. Questa funzionalità è integrata in modalità automatica EKS.

## Considerazioni
<a name="pod-id-agent-considerations"></a>
+ Per impostazione predefinita, l’agente EKS Pod Identity è preinstallato sui cluster in modalità automatica EKS. Per ulteriori informazioni, consulta [Automate cluster infrastructure with EKS Auto Mode](automode.md).
+ Per impostazione predefinita, l’agente EKS Pod Identity ascolta su un indirizzo `IPv4` e sull’indirizzo `IPv6` perché i pod richiedano le credenziali. L’agente utilizza l’indirizzo IP di loopback (localhost) `169.254.170.23` per `IPv4` e l’indirizzo IP localhost `[fd00:ec2::23]` per `IPv6`.
+ Se disabiliti gli indirizzi `IPv6` o impedisci in altro modo gli indirizzi IP `IPv6` localhost, l’agente non può avviarsi. Per avviare l’agente su nodi che non possono utilizzare `IPv6`, segui i passaggi indicati in [Disabilitazione di `IPv6` nell’agente EKS Pod Identity](pod-id-agent-config-ipv6.md) per disabilitare la configurazione `IPv6`.

## Creazione di Amazon EKS Pod Identity Agent
<a name="pod-id-agent-add-on-create"></a>

### Prerequisiti dell'agente
<a name="pod-id-agent-prereqs"></a>
+ Un cluster Amazon EKS esistente. Per implementarne uno, consulta [Nozioni di base su Amazon EKS](getting-started.md). La versione del cluster e la versione della piattaforma devono essere uguali o successive alle versioni elencate nelle [versioni del cluster EKS Pod Identity](pod-identities.md#pod-id-cluster-versions).
+ Il ruolo del nodo dispone delle autorizzazioni per consentire all'agente di eseguire l'azione `AssumeRoleForPodIdentity` nell'API EKS Auth. Puoi utilizzare la [politica AWS gestita: Amazon EKSWorker NodePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksworkernodepolicy) o aggiungere una politica personalizzata simile alla seguente:

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

  Questa azione può essere limitata dai tag per ridurre i ruoli che possono essere assunti dai pod che utilizzano l'agente.
+ I nodi possono raggiungere e scaricare immagini da Amazon ECR. L’immagine del container per il componente aggiuntivo si trova nei registri elencati in [Visualizza registri delle immagini del container Amazon per i componenti aggiuntivi Amazon EKS](add-ons-images.md).

  Tieni presente che puoi modificare la posizione dell'immagine e fornire `imagePullSecrets` componenti aggiuntivi EKS nelle **impostazioni di configurazione opzionali** nella e nella `--configuration-values` AWS CLI. Console di gestione AWS
+ I nodi possono raggiungere l'API Amazon EKS Auth. Per i cluster privati, è necessario l'ingresso dell'`eks-auth`endpoint. AWS PrivateLink 

### Agente di configurazione con console AWS
<a name="setup_agent_with_shared_aws_console"></a>

1. Aprire la [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 di EKS Pod Identity Agent siano in esecuzione sul cluster.

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

   Di seguito viene riportato un output di esempio.

   ```
   eks-pod-identity-agent-gmqp7                                          1/1     Running   1 (24h ago)   24h
   eks-pod-identity-agent-prnsh                                          1/1     Running   1 (24h ago)   24h
   ```

   Ora puoi utilizzare le associazioni EKS Pod Identity nel cluster. Per ulteriori informazioni, consulta [Assegnazione di un ruolo IAM a un account di servizio Kubernetes](pod-id-association.md).

### Agente di configurazione con AWS CLI
<a name="setup_agent_with_shared_aws_cli"></a>

1. Esegui il seguente comando AWS CLI. Sostituisci `my-cluster` con il nome del cluster.

   ```
   aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1
   ```
**Nota**  
L’agente EKS Pod Identity non utilizza `service-account-role-arn` per *ruoli IAM per account di servizio*. È necessario fornire a EKS Pod Identity Agent le autorizzazioni nel ruolo del nodo.

1. Verifica che i pod di EKS Pod Identity Agent siano in esecuzione sul cluster.

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

   Di seguito viene riportato un output di esempio.

   ```
   eks-pod-identity-agent-gmqp7                                          1/1     Running   1 (24h ago)   24h
   eks-pod-identity-agent-prnsh                                          1/1     Running   1 (24h ago)   24h
   ```

   Ora puoi utilizzare le associazioni EKS Pod Identity nel cluster. Per ulteriori informazioni, consulta [Assegnazione di un ruolo IAM a un account di servizio Kubernetes](pod-id-association.md).

# Assegnazione di un ruolo IAM a un account di servizio Kubernetes
<a name="pod-id-association"></a>

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

Per creare un'associazione EKS Pod Identity, è sufficiente un solo passaggio; si crea l'associazione in EKS tramite AWS CLI AWS CloudFormation e altri strumenti. Console di gestione AWS AWS SDKs Non sono presenti dati o metadati sulle associazioni all’interno del cluster in nessun oggetto Kubernetes e non si aggiungono annotazioni agli account di servizio.

 **Prerequisiti** 
+ Un cluster esistente. Se non se ne possiede già uno, crearlo seguendo una delle guide in [Nozioni di base su Amazon EKS](getting-started.md).
+ Il principale IAM che sta creando l'associazione deve avere `iam:PassRole`.
+ La versione più recente della AWS CLI installata e configurata sul dispositivo o. AWS CloudShell È possibile verificare la versione corrente con `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).

## Crea un'associazione Pod Identity (AWS Console)
<a name="pod-id-association-create"></a>

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

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

1. Scegli la scheda **Accesso**.

1. In **Associazioni Pod Identity**, scegli **Crea**.

1. Per **Ruolo IAM**, seleziona il ruolo IAM con le autorizzazioni che desideri assegnare al carico di lavoro.
**Nota**  
L'elenco contiene solo i ruoli con la seguente policy di attendibilità che consente a EKS Pod Identity di utilizzarli.

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

    `sts:AssumeRole`: EKS Pod Identity utilizza `AssumeRole` per assumere il ruolo IAM prima di passare le credenziali temporanee ai pod.

    `sts:TagSession`— EKS Pod Identity utilizza `TagSession` per includere i *tag di sessione* nelle richieste a AWS STS.

   È possibile utilizzare questi tag nelle *chiavi di condizione* nella policy di attendibilità per limitare gli account di servizio, i namespace e i cluster che possono utilizzare questo ruolo.

   Per un elenco di chiavi di condizione di Amazon EKS, consultare [Condizioni per Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) in *Service Authorization Reference*. Per informazioni su operazioni e risorse con cui è possibile utilizzare una chiave di condizione, consultare [Operazioni definite da Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).

1. Per **Namespace Kubernetes**, seleziona il namespace Kubernetes che contiene l’account di servizio e il carico di lavoro. Facoltativamente, è possibile specificare un namespace che non esiste nel cluster.

1. Per l’**account del servizio Kubernetes**, seleziona l’account del servizio Kubernetes da utilizzare. Il manifesto del carico di lavoro Kubernetes deve specificare questo account di servizio. Facoltativamente, è possibile specificare un account di servizio in base al nome che non è presente nel cluster.

1. (Facoltativo) Seleziona **Disabilita i tag di sessione** per disabilitare i tag di sessione predefiniti che Pod Identity aggiunge automaticamente quando assume il ruolo.

1. (Facoltativo) Attiva **Configure session policy** per configurare una policy IAM per applicare restrizioni aggiuntive a questa associazione Pod Identity oltre alle autorizzazioni definite nella policy IAM allegata al ruolo IAM.
**Nota**  
Una policy di sessione può essere applicata solo quando l'impostazione **Disabilita i tag di sessione** è selezionata.

1. (Facoltativo) Per **Tag**, scegli **Aggiungi tag** per aggiungere metadati in una coppia chiave-valore. Questi tag vengono applicati all'associazione e possono essere utilizzati nelle policy IAM.

   Puoi ripetere questo passaggio per aggiungere più tag.

1. Scegli **Create** (Crea).

## Creare un'associazione Pod Identity (AWS CLI)
<a name="create_a_pod_identity_association_shared_aws_cli"></a>

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

   Creare una policy IAM Puoi creare la tua politica o copiare una politica AWS gestita che concede già 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
      ```

1. Crea un ruolo IAM e associalo a un account del servizio Kubernetes.

   1. Se disponi di un account di servizio Kubernetes esistente che desideri assuma un ruolo IAM, puoi saltare questo passaggio.

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

      Eseguire il seguente comando seguente.

      ```
      kubectl apply -f my-service-account.yaml
      ```

   1. Per creare una policy di attendibilità del ruolo IAM, esegui il comando seguente.

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

   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::111122223333:policy/my-policy
      ```
**Nota**  
A differenza dei ruoli IAM per gli account di servizio, EKS Pod Identity non utilizza l’annotazione sull’account di servizio.

   1. Esegui il comando seguente per creare l'associazione. Sostituiscilo `my-cluster` con il nome del cluster, sostituiscilo *my-service-account* con il nome desiderato e *default* con un namespace diverso, se necessario.

      ```
      aws eks create-pod-identity-association --cluster-name my-cluster --role-arn arn:aws: iam::111122223333:role/my-role --namespace default --service-account my-service-account
      ```

      Di seguito viene riportato un output di esempio.

      ```
      {
          "association": {
              "clusterName": "my-cluster",
              "namespace": "default",
              "serviceAccount": "my-service-account",
              "roleArn": "arn:aws: iam::111122223333:role/my-role",
              "associationArn": "arn:aws::111122223333:podidentityassociation/my-cluster/a-abcdefghijklmnop1",
              "associationId": "a-abcdefghijklmnop1",
              "tags": {},
              "createdAt": 1700862734.922,
              "modifiedAt": 1700862734.922
          }
      }
      ```
**Nota**  
È possibile specificare un namespace e un account di servizio in base al nome che non esiste nel cluster. È necessario creare il namespace, l'account di servizio e il carico di lavoro che utilizza l'account di servizio affinché l'associazione EKS Pod Identity funzioni.

## Confermare la configurazione
<a name="pod-id-confirm-role-configuration"></a>

1. Conferma 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": [
           {
               "Sid": "Allow EKS Auth service to assume this role for Pod Identities",
               "Effect": "Allow",
               "Principal": {
                   "Service": "pods.eks.amazonaws.com"
               },
               "Action": [
                   "sts:AssumeRole",
                   "sts:TagSession"
               ]
           }
       ]
   }
   ```

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

## Fasi successive
<a name="_next_steps"></a>

 [Configura i pod per accedere ai AWS servizi con account di servizio](pod-id-configure-pods.md) 

# Accedi alle AWS risorse utilizzando i ruoli IAM di EKS Pod Identity Target
<a name="pod-id-assign-target-role"></a>

Quando esegui applicazioni su Amazon Elastic Kubernetes Service (Amazon EKS), potresti dover accedere AWS a risorse esistenti in account diversi. AWS Questa guida mostra come configurare l'accesso su più account utilizzando EKS Pod Identity, che consente ai pod Kubernetes di accedere ad altre risorse utilizzando i ruoli di destinazione. AWS 

## Prerequisiti
<a name="_prerequisites"></a>

Prima di iniziare, assicurati di aver completato i passaggi seguenti:
+  [Configurazione dell’agente Amazon EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) 
+  [Creazione di un ruolo di EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) 

## Come funziona
<a name="_how_it_works"></a>

Pod Identity consente alle applicazioni del cluster EKS di accedere alle AWS risorse tra gli account attraverso un processo chiamato concatenamento dei ruoli.

Quando crei un'associazione Pod Identity, puoi fornire due ruoli IAM: un [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) nello stesso account del cluster EKS e un ruolo IAM Target dall'account contenente AWS le risorse a cui desideri accedere (come i bucket S3 o i database RDS). Il [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) deve trovarsi nell'account del cluster EKS a causa PassRole dei requisiti [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html), mentre il ruolo IAM di Target può essere in qualsiasi account. AWS PassRole consente a un' AWS entità di delegare l'assunzione del ruolo a un altro servizio. EKS Pod Identity utilizza PassRole per connettere un ruolo a un account di servizio Kubernetes, richiedendo che sia il ruolo che l'identità che lo trasmette si trovino nello stesso AWS account del cluster EKS. Quando il pod dell'applicazione deve accedere alle AWS risorse, richiede le credenziali a Pod Identity. Quindi, Pod Identity esegue automaticamente due assunzione di ruolo in sequenza: prima assume il [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html), poi utilizza tali credenziali per assumere il ruolo IAM di destinazione. Questo processo fornisce al pod credenziali temporanee con le autorizzazioni definite nel ruolo di destinazione, consentendo l'accesso sicuro alle risorse di altri account. AWS 

## Considerazioni sul caching
<a name="_caching_considerations"></a>

Per via dei meccanismi del caching, gli aggiornamenti per un ruolo IAM in un’associazione Pod Identity esistente potrebbero non avere effetto immediato nei pod in esecuzione sul cluster EKS. L’agente Pod Identity memorizza nella cache le credenziali IAM in base alla configurazione dell’associazione al momento del recupero delle credenziali. Se l’associazione include solo un [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) e nessun ruolo IAM di destinazione, le credenziali memorizzate nella cache durano 6 ore. Se l’associazione include sia l’ARN del [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) che un ruolo IAM di destinazione, le credenziali memorizzate nella cache durano 59 minuti. La modifica di un’associazione esistente, ad esempio l’aggiornamento dell’ARN del [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) o l’aggiunta di un ruolo IAM di destinazione, non reimposta la cache esistente. Di conseguenza, l’agente non riconoscerà gli aggiornamenti fino all’aggiornamento delle credenziali memorizzate nella cache. Per applicare prima le modifiche, è possibile ricreare i pod esistenti; in caso contrario, sarà necessario attendere la scadenza della cache.

## Passaggio 1: creazione e associazione di un ruolo IAM di destinazione
<a name="_step_1_create_and_associate_a_target_iam_role"></a>

In questo passaggio, stabilirai una catena di affidabilità sicura creando e configurando un ruolo IAM di destinazione. A titolo dimostrativo, creeremo un nuovo ruolo Target IAM per stabilire una catena di fiducia tra due AWS account: il [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) (ad esempio`eks-pod-identity-primary-role`) nell' AWS account del cluster EKS ottiene l'autorizzazione ad assumere il ruolo Target IAM (ad esempio`eks-pod-identity-aws-resources`) nel tuo account di destinazione, abilitando l'accesso a AWS risorse come i bucket Amazon S3.

### Creazione del ruolo IAM di destinazione
<a name="_create_the_target_iam_role"></a>

1. Apri la [console IAM Amazon](https://console.aws.amazon.com/iam/home).

1. Nella barra di navigazione in alto, verifica di aver effettuato l'accesso all'account contenente AWS le risorse (come i bucket S3 o le tabelle DynamoDB) per il tuo ruolo IAM di Target.

1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.

1. Scegli il pulsante **Crea ruolo**, quindi l'** AWS account** nella sezione «Tipo di entità affidabile».

1. Scegli **Altro AWS account**, inserisci il tuo numero di AWS account (l'account in cui esiste il tuo [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)), quindi scegli **Avanti**.

1. **Aggiungi le politiche di autorizzazione che desideri associare al ruolo (ad esempio, AmazonS3FullAccess), quindi scegli Avanti.**

1. Immetti un nome ruolo, come `MyCustomIAMTargetRole`, quindi scegli **Crea ruolo**.

### Aggiorna la policy di affidabilità di un ruolo IAM di destinazione
<a name="_update_the_target_iam_role_trust_policy"></a>

1. Dopo aver creato il ruolo, ritornerai all’elenco **Ruoli**. Trova e seleziona il nuovo ruolo creato nel passaggio precedente (ad esempio, `MyCustomIAMTargetRole`).

1. Seleziona la scheda **Relazioni di attendibilità**.

1. Fai clic su **Modifica policy di affidabilità** sul lato destro.

1. Nell’editor della policy, sostituisci il file JSON predefinito con la tua policy di affidabilità. Sostituisci i valori segnaposto per il nome del ruolo e `111122223333` nell'ARN del ruolo IAM con l'ID dell' AWS account che ospita il tuo cluster EKS. Opzionalmente, puoi anche utilizzare PrincipalTags la policy di fiducia dei ruoli per autorizzare solo account di servizio specifici di un determinato cluster e namespace ad assumere il tuo ruolo di destinazione. Esempio:

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster",
          "aws:RequestTag/kubernetes-namespace": "ExampleNameSpace",
          "aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName"
        },
        "ArnEquals": {
          "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
        }
      }
    }
  ]
}
```

La politica di cui sopra consente al ruolo `eks-pod-identeity-primary-role` dell' AWS account 111122223333 con i pertinenti [EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html) Session Tag di assumere questo ruolo.

Se hai [Disabilitato i tag di sessione](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) nella tua EKS Pod Identity, EKS Pod Identity imposta anche `sts:ExternalId` con le informazioni sul cluster, sul namespace e sull’account di servizio di un pod quando assume un ruolo di destinazione.

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name"
        },
        "ArnEquals": {
          "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:TagSession"
    }
  ]
}
```

La policy di cui sopra aiuta a garantire che solo il cluster, il namespace e l’account di servizio previsti possano assumere il ruolo di destinazione.

### Aggiorna la policy di autorizzazione per il ruolo EKS Pod Identity
<a name="_update_the_permission_policy_for_eks_pod_identity_role"></a>

In questo passaggio, aggiornerai la policy di autorizzazione del [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) associato al tuo cluster Amazon EKS aggiungendo l’ARN del ruolo IAM di destinazione come risorsa.

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

1. Nel riquadro di navigazione a sinistra, seleziona **Cluster**, quindi seleziona il nome del cluster EKS.

1. Scegliere la scheda **Accesso**.

1. In **Associazioni Pod Identity**, seleziona il tuo [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html).

1. Scegli **Autorizzazioni**, scegli **Aggiungi autorizzazioni**, quindi **Crea policy in linea**.

1. Scegli **JSON** sul lato destro.

1. Nell’editor della policy, sostituisci il file JSON predefinito con la tua policy di autorizzazione. Sostituisci il valore segnaposto per il nome del ruolo e `222233334444` nell’ARN del ruolo IAM con il tuo ruolo IAM di destinazione. Esempio:

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources"
        }
    ]
}
```

## Passaggio 2: associazione del ruolo IAM di destinazione a un account di servizio Kubernetes
<a name="_step_2_associate_the_target_iam_role_to_a_kubernetes_service_account"></a>

In questo passaggio, creerai un’associazione tra il ruolo IAM di destinazione e l’account del servizio Kubernetes nel tuo cluster EKS.

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

1. Nel riquadro di navigazione a sinistra, seleziona **Cluster**, quindi seleziona il nome del cluster a cui aggiungere l’associazione.

1. Scegli la scheda **Accesso**.

1. In **Associazioni Pod Identity**, scegli **Crea**.

1. Scegli il [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) nel **ruolo IAM** per i tuoi carichi di lavoro da assumere.

1. Scegli il ruolo IAM di destinazione nel **ruolo IAM di destinazione** che sarà assunto dal [ruolo EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html).

1. Nel campo del **namespace Kubernetes**, inserisci il nome del namespace in cui desideri creare l’associazione (ad esempio, `my-app-namespace`). Ciò definisce dove risiede l’account del servizio.

1. Nel campo dell’**account del servizio Kubernetes**, inserisci il nome dell’account di servizio (ad esempio, `my-service-account`) che utilizzerà le credenziali IAM. Ciò collega il ruolo IAM all’account del servizio.

1. (Facoltativo) Seleziona **Disabilita i tag di sessione** per disabilitare i tag di sessione predefiniti che Pod Identity aggiunge automaticamente quando assume il ruolo.

1. **(Facoltativo) Attiva **Configure session policy** per configurare una policy IAM per applicare restrizioni aggiuntive a questa associazione di identità Pod oltre alle autorizzazioni definite nella policy IAM allegata al ruolo IAM di Target.**
**Nota**  
1. Una policy di sessione può essere applicata solo quando l'impostazione **Disabilita i tag di sessione** è selezionata. 2. Se specifichi una policy di sessione, le restrizioni della policy si applicano alle autorizzazioni del **ruolo IAM di Target** e non al **ruolo IAM** associato a questa associazione Pod Identity.

1. Scegli **Crea** per creare l’associazione.

# Configura i pod per accedere ai AWS servizi con account di servizio
<a name="pod-id-configure-pods"></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).
+ Un account di servizio Kubernetes esistente e un’associazione EKS Pod Identity che associa l’account di servizio a un 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 [Assegnazione di un ruolo IAM a un account di servizio Kubernetes](pod-id-association.md).
+ La versione più recente della AWS CLI installata e configurata sul dispositivo o. AWS CloudShell È possibile verificare la versione corrente con `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. Verifica che il pod abbia il file di token dell’account di servizio montato.

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

        Di seguito viene riportato un output di esempio.

        ```
        AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE:  /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token
        ```

  1. Verifica che i tuoi Pod possano interagire con i AWS servizi utilizzando le autorizzazioni che hai assegnato 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'associazione EKS Pod Identity. Per ulteriori informazioni, consulta [Utilizzo di Pod Identity con SDK AWS](pod-id-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
        ```

# Concedi ai Pods l'accesso alle AWS risorse in base ai tag
<a name="pod-id-abac"></a>

Il controllo degli accessi basato su attributi (ABAC) concede diritti agli utenti attraverso policy che combinano gli attributi. EKS Pod Identity allega i tag alle credenziali temporanee di ciascun pod con attributi come nome cluster, namespace e nome account di servizio. Questi tag di sessione di ruolo consentono agli amministratori di creare un singolo ruolo che può funzionare su più account di servizio, consentendo l'accesso alle risorse in base ai tag corrispondenti. AWS Aggiungendo il supporto per i tag di sessione dei ruoli, puoi imporre limiti di sicurezza più rigorosi tra i cluster e i carichi di lavoro all’interno dei cluster, riutilizzando al contempo gli stessi ruoli IAM e le stesse policy IAM.

## Policy esemplificativa con tag
<a name="_sample_policy_with_tags"></a>

Di seguito è riportato un esempio di policy IAM che concede a `s3:GetObject` autorizzazioni quando l’oggetto corrispondente è etichettato con il nome del cluster EKS.

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectTagging"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}"
                }
            }
        }
    ]
}
```

## Abilitare o disabilitare i tag di sessione
<a name="pod-id-abac-tags"></a>

EKS Pod Identity aggiunge un set predefinito di tag di sessione quando assume il ruolo. Questi tag di sessione consentono agli amministratori di creare un singolo ruolo in grado di funzionare su più risorse, consentendo l'accesso alle AWS risorse in base ai tag corrispondenti.

### Disattivare i tag di sessione
<a name="_enable_session_tags"></a>

I tag di sessione sono abilitati automaticamente con EKS Pod Identity: non è richiesta alcuna azione da parte dell’utente. Per impostazione predefinita, EKS Pod Identity allega una serie di tag predefiniti alla sessione. Per fare riferimento a tali tag nelle politiche, utilizza la sintassi `${aws:PrincipalTag/` seguita dalla chiave del tag. Ad esempio, `${aws:PrincipalTag/kubernetes-namespace}`.
+  `eks-cluster-arn` 
+  `eks-cluster-name` 
+  `kubernetes-namespace` 
+  `kubernetes-service-account` 
+  `kubernetes-pod-name` 
+  `kubernetes-pod-uid` 

### Disattiva i tag di sessione
<a name="_disable_session_tags"></a>

 AWS comprime i criteri di sessione in linea, i criteri ARNs gestiti e i tag di sessione in un formato binario compresso con un limite separato. Se ricevi un errore `PackedPolicyTooLarge` che indica che il formato binario compresso ha superato il limite di dimensione, puoi tentare ridurlo disattivando i tag di sessione aggiunti da EKS Pod Identity. Per disattivare questi tag di sessione, procedi nel seguente modo:

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

1. Nel riquadro di navigazione a sinistra, seleziona **Cluster**, quindi seleziona il nome del cluster che desideri modificare.

1. Scegliere la scheda **Accesso**.

1. Nelle **associazioni Pod Identity**, scegli l’ID di associazione che desideri modificare in **ID di associazione**, quindi scegli **Modifica**.

1. In **Tag di sessione**, scegli **Disattiva i tag di sessione**.

1. Scegli **Save changes** (Salva modifiche).

## Tag tra account
<a name="pod-id-abac-chaining"></a>

Tutti i tag di sessione aggiunti da EKS Pod Identity sono *transitivi*; le chiavi e i valori dei tag vengono passati a tutte le azioni `AssumeRole` utilizzate dai carichi di lavoro per cambiare ruolo in un altro account. È possibile utilizzare questi tag nelle policy di altri account per limitare l'accesso in scenari tra account. Per ulteriori informazioni, consulta [Concatenamento di ruoli con i tag di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining) nella *Guida per l'utente di IAM*.

## Tag personalizzati
<a name="pod-id-abac-custom-tags"></a>

EKS Pod Identity non può aggiungere tag personalizzati supplementari all’azione `AssumeRole` che esegue. Tuttavia, i tag applicati al ruolo IAM sono sempre disponibili nello stesso formato: `${aws:PrincipalTag/` seguito dalla chiave, ad esempio `${aws:PrincipalTag/MyCustomTag}`.

**Nota**  
I tag aggiunti alla sessione tramite la richiesta `sts:AssumeRole` hanno la precedenza in caso di conflitto. Ad esempio, supponiamo che:  
Amazon EKS aggiunge una chiave `eks-cluster-name` e un valore `my-cluster` alla sessione quando EKS assume il ruolo di cliente e
Hai aggiunto anche un tag `eks-cluster-name` al ruolo IAM con valore `my-own-cluster`.
In questo caso, il primo ha la precedenza e il valore del tag per `eks-cluster-name` sarà `my-cluster`.

# Utilizzo di Pod Identity con SDK AWS
<a name="pod-id-minimum-sdk"></a>

## Utilizzo delle credenziali EKS Pod Identity
<a name="pod-id-using-creds"></a>

Per utilizzare le credenziali di un’associazione EKS Pod Identity, il codice può utilizzare qualsiasi SDK AWS per creare un client per un servizio AWS con un SDK e, per impostazione predefinita, l’SDK cerca le credenziali AWS Identity and Access Management da utilizzare in una catena di posizioni. Si utilizzano le credenziali EKS Pod Identity se non si specifica un provider di credenziali quando si crea il client o si inizializza in altro modo l’SDK.

Questo avviene perché le associazioni EKS Pod Identity sono state aggiunte al *provider di credenziali del container*, che viene cercato in un passaggio nella catena di credenziali predefinita. Se i carichi di lavoro utilizzano attualmente credenziali che si trovano all'inizio della catena di credenziali, quest'ultime continuano a essere utilizzate anche se configuri un'associazione EKS Pod Identity per lo stesso carico di lavoro.

Per ulteriori informazioni sul funzionamento delle associazioni EKS Pod Identity, consulta [Comprensione di come funziona EKS Pod Identity](pod-id-how-it-works.md).

Quando utilizzi [Ulteriori informazioni su come EKS Pod Identity concede ai pod l’accesso ai servizi AWS](pod-identities.md), i container nei tuoi pod devono utilizzare una versione di AWS SDK che supporta l’assunzione di un ruolo IAM dall’agente EKS Pod Identity. Accertati di utilizzare le seguenti versioni, o successive, per il tuo SDK AWS:
+ Java (Versione 2) – [2.21.30](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.21.30) 
+ Java – [1.12.746](https://github.com/aws/aws-sdk-java/releases/tag/1.12.746) 
+ Vai a v1 – [v1.47.11](https://github.com/aws/aws-sdk-go/releases/tag/v1.47.11) 
+ Vai a v2 – [release-2023-11-14](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2023-11-14) 
+ Python (Boto3) – [1.34.41](https://github.com/boto/boto3/releases/tag/1.34.41) 
+ Python (botocore) – [1.34.41](https://github.com/boto/botocore/releases/tag/1.34.41) 
+  AWS CLI – [1.30.0](https://github.com/aws/aws-cli/releases/tag/1.30.0) 

   AWS CLI – [2.15.0](https://github.com/aws/aws-cli/releases/tag/2.15.0) 
+ JavaScript v2 – [2.1550.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.1550.0) 
+ JavaScript v3 – [v3.458.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.458.0) 
+ Kotlin – [v1.0.1](https://github.com/awslabs/aws-sdk-kotlin/releases/tag/v1.0.1) 
+ Ruby – [3.188.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#31880-2023-11-22) 
+ Rust – [release-2024-03-13](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-03-13) 
+ C\$1\$1 – [1.11.263](https://github.com/aws/aws-sdk-cpp/releases/tag/1.11.263) 
+ .NET – [3.7.734.0](https://github.com/aws/aws-sdk-net/releases/tag/3.7.734.0) 
+ PowerShell – [4.1.502](https://www.powershellgallery.com/packages/AWS.Tools.Common/4.1.502) 
+ PHP – [3.289.0](https://github.com/aws/aws-sdk-php/releases/tag/3.287.1) 

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/).

Per un elenco di componenti aggiuntivi che supportano EKS Pod Identity, consulta [Riferimento di supporto Pod Identity](retreive-iam-info.md#pod-id-add-on-versions).

# Disabilitazione di `IPv6` nell’agente EKS Pod Identity
<a name="pod-id-agent-config-ipv6"></a>

## Console di gestione AWS
<a name="pod-id-console"></a>

1. Per disabilitare `IPv6` nell’agente EKS Pod Identity, aggiungi la seguente configurazione alle **Impostazioni di configurazione opzionali** del componente aggiuntivo EKS.

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

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

   1. Seleziona la scheda **Componenti aggiuntivi**.

   1. Seleziona la casella nella parte superiore destra di quella del componente aggiuntivo relativo all’agente EKS Pod Identity, quindi scegli **Modifica**.

   1. Nella pagina **Configura agente EKS Pod Identity**:

      1. Seleziona la **Versione** da utilizzare. Si consiglia di mantenere la stessa versione rispetto al passaggio precedente e di aggiornare la versione e la configurazione con operazioni separate.

      1. Scegli **Impostazioni di configurazione facoltative**.

      1. Inserisci la chiave JSON `"agent":` e il valore di un oggetto JSON annidato con una chiave `"additionalArgs":` in **Valori di configurazione**. Il testo risultante deve essere un oggetto JSON valido. Se questa chiave e questo valore sono gli unici dati nella casella di testo, racchiudi la chiave e il valore tra parentesi graffe `{ }`. Di seguito è riportato l’esempio dell’abilitazione della policy di rete:

         ```
         {
             "agent": {
                 "additionalArgs": {
                     "-b": "169.254.170.23"
                 }
             }
         }
         ```

         Questa configurazione imposta l’indirizzo `IPv4` come unico indirizzo utilizzato dall’agente.

   1. Per applicare la nuova configurazione sostituendo i pod dell’agente EKS Pod Identity, scegli **Salva modifiche**.

      Amazon EKS applica le modifiche ai componenti aggiuntivi EKS utilizzando un*rollout* di Kubernetes `DaemonSet` per l’agente EKS Pod Identity. È possibile monitorare lo stato del rollout nella **Cronologia degli aggiornamenti** del componente aggiuntivo nella Console di gestione AWS e con `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`.

       `kubectl rollout` dispone dei seguenti comandi:

      ```
      $ kubectl rollout
      
      history  -- View rollout history
      pause    -- Mark the provided resource as paused
      restart  -- Restart a resource
      resume   -- Resume a paused resource
      status   -- Show the status of the rollout
      undo     -- Undo a previous rollout
      ```

      Se il rollout richiede troppo tempo, Amazon EKS annullerà l’operazione e un messaggio contenente il tipo di **Aggiornamento del componente aggiuntivo** e lo stato **Non riuscito** sarà aggiunto alla **Cronologia degli aggiornamenti** del componente aggiuntivo. Per esaminare eventuali problemi, inizia dalla cronologia del rollout ed esegui `kubectl logs` su un pod dell’agente EKS Pod Identity per visualizzare i log dell’agente EKS Pod Identity.

1. Se la nuova voce nella **Cronologia degli aggiornamenti** ha lo stato **Riuscito**, il rollout è stato completato e il componente aggiuntivo utilizza la nuova configurazione in tutti i pod dell’agente EKS Pod Identity.

## CLI AWS
<a name="pod-id-cli"></a>

1. Per disabilitare `IPv6` nell’agente EKS Pod Identity, aggiungi la seguente configurazione ai **valori di configurazione** del componente aggiuntivo EKS.

   Esegui il seguente comando AWS CLI. Sostituisci `my-cluster` con il nome del cluster e l'ARN del ruolo IAM con il ruolo che stai utilizzando.

   ```
   aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent \
       --resolve-conflicts PRESERVE --configuration-values '{"agent":{"additionalArgs": { "-b": "169.254.170.23"}}}'
   ```

   Questa configurazione imposta l’indirizzo `IPv4` come unico indirizzo utilizzato dall’agente.

   Amazon EKS applica le modifiche ai componenti aggiuntivi EKS utilizzando un *rollout* di DaemonSet Kubernetes per l’agente EKS Pod Identity. È possibile monitorare lo stato del rollout nella **Cronologia degli aggiornamenti** del componente aggiuntivo nella Console di gestione AWS e con `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`.

    `kubectl rollout` dispone dei seguenti comandi:

   ```
   kubectl rollout
   
   history  -- View rollout history
   pause    -- Mark the provided resource as paused
   restart  -- Restart a resource
   resume   -- Resume a paused resource
   status   -- Show the status of the rollout
   undo     -- Undo a previous rollout
   ```

   Se il rollout richiede troppo tempo, Amazon EKS annullerà l’operazione e un messaggio contenente il tipo di **Aggiornamento del componente aggiuntivo** e lo stato **Non riuscito** sarà aggiunto alla **Cronologia degli aggiornamenti** del componente aggiuntivo. Per esaminare eventuali problemi, inizia dalla cronologia del rollout ed esegui `kubectl logs` su un pod dell’agente EKS Pod Identity per visualizzare i log dell’agente EKS Pod Identity.

# Creazione di un ruolo IAM con la policy di fiducia richiesta da EKS Pod Identity
<a name="pod-id-role"></a>

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

 ** `sts:AssumeRole` **   
EKS Pod Identity utilizza `AssumeRole` per assumere il ruolo IAM prima di passare le credenziali temporanee ai pod.

 ** `sts:TagSession` **   
EKS Pod Identity utilizza `TagSession` per includere i *tag di sessione* nelle richieste a STS. AWS 

 **Impostazione delle condizioni**   
È possibile utilizzare questi tag nelle *chiavi di condizione* nella policy di attendibilità per limitare gli account di servizio, i namespace e i cluster che possono utilizzare questo ruolo. Per l’elenco dei tag di richiesta aggiunti da Pod Identity, consulta [Abilitare o disabilitare i tag di sessione](pod-id-abac.md#pod-id-abac-tags).  
Ad esempio, è possibile limitare i pod che possono assumere il ruolo di un ruolo IAM di Pod Identity a `ServiceAccount` e `Namespace` specifici con la seguente policy di fiducia con l’aggiunta di `Condition`:

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/kubernetes-namespace": [
                        "Namespace"
                    ],
                    "aws:RequestTag/kubernetes-service-account": [
                        "ServiceAccount"
                    ]
                }
            }
        }
    ]
}
```

Per un elenco di chiavi di condizione di Amazon EKS, consultare [Condizioni per Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) in *Service Authorization Reference*. Per informazioni su operazioni e risorse con cui è possibile utilizzare una chiave di condizione, consultare [Operazioni definite da Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).