**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 funziona il controllo degli accessi in Amazon EKS
Scopri come gestire l’accesso al tuo cluster Amazon EKS. L'utilizzo di Amazon EKS richiede la conoscenza di come Kubernetes e AWS Identity and Access Management (AWS IAM) gestiscono il controllo degli accessi.
**Questa sezione include:**
**[Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs](grant-k8s-access.md)**: scopri come permettere alle applicazioni o agli utenti di autenticarsi nell’API Kubernetes. Puoi utilizzare access entry, aws-auth ConfigMap o un provider OIDC esterno.
**[Visualizza le risorse Kubernetes nel Console di gestione AWS](view-kubernetes-resources.md)**— Scopri come configurare la comunicazione con Console di gestione AWS il tuo cluster Amazon EKS. Utilizza la console per visualizzare le risorse Kubernetes nel cluster, come namespace, nodi e pod.
**[Concedi AWS ai servizi l'accesso in scrittura a Kubernetes APIs](mutate-kubernetes-resources.md)**— Scopri le autorizzazioni necessarie per modificare le risorse Kubernetes.
** [Connettere kubectl a un cluster EKS creando un file kubeconfig](create-kubeconfig.md) ** : scopri come configurare kubectl per comunicare con il tuo cluster Amazon EKS. Usa la AWS CLI per creare un file kubeconfig.
**[Concessione ai carichi di lavoro Kubernetes dell’accesso a AWS utilizzando gli account di servizio Kubernetes](service-accounts.md)**— Scopri come associare un account di servizio Kubernetes a IAM Roles. AWS Puoi usare Pod Identity o i ruoli IAM per gli account di servizio (IRSA).
## Attività comuni
+ Concedi l’accesso all’API Kubernetes agli sviluppatori. Visualizza le risorse Kubernetes in. Console di gestione AWS
+ Soluzione: [utilizza le voci di accesso](access-entries.md) per associare le autorizzazioni RBAC di Kubernetes agli utenti o ai ruoli IAM. AWS
+ Configura kubectl per comunicare con un cluster Amazon EKS utilizzando le credenziali. AWS
+ Soluzione: utilizzate la AWS CLI per [creare un file kubeconfig](create-kubeconfig.md).
+ Usa un provider di identità esterno, come Ping Identity, per autenticare gli utenti nell’API Kubernetes.
+ Soluzione: [collega un provider OIDC esterno](authenticate-oidc-identity-provider.md).
+ Concedi ai carichi di lavoro sul tuo cluster Kubernetes la possibilità di chiamare. AWS APIs
+ Soluzione: [utilizza Pod Identity](pod-identities.md) per associare un ruolo AWS IAM a un account di servizio Kubernetes.
## Contesto
+ [Scopri come funzionano gli account di servizio Kubernetes.](https://kubernetes.io/docs/concepts/security/service-accounts/)
+ [Esamina il modello di controllo degli accessi basato sui ruoli (Role Based Access Control, RBAC) di Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+ Per ulteriori informazioni sulla gestione dell'accesso alle AWS risorse, consulta la [AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html) User Guide. In alternativa, segui un [corso introduttivo gratuito sull'uso AWS di](https://explore.skillbuilder.aws/learn/course/external/view/elearning/120/introduction-to-aws-identity-and-access-management-iam) IAM.
## Considerazioni relative alla modalità automatica di EKS
La modalità automatica di EKS si integra con le voci di accesso EKS Pod Identity ed EKS EKS.
+ La modalità automatica di EKS usa le voci di accesso per concedere le autorizzazioni Kubernetes del piano di controllo di EKS. Ad esempio, le policy di accesso consentono alla modalità automatica di EKS di leggere informazioni sugli endpoint e sui servizi di rete.
+ Non puoi disabilitare le voci di accesso su un cluster della modalità automatica di EKS.
+ Facoltativamente, puoi abilitare `aws-auth` `ConfigMap`.
+ Le voci di accesso per la modalità automatica di EKS sono configurate automaticamente. Puoi visualizzare queste voci di accesso, ma non puoi modificarle.
+ Se utilizzi un NodeClass ruolo Node IAM personalizzato, devi creare una voce di accesso per il ruolo utilizzando la policy di EKSAuto NodePolicy accesso Amazon.
+ Se desideri concedere ai carichi di lavoro le autorizzazioni per AWS i servizi, usa EKS Pod Identity.
+ Non è necessario installare l’agente Pod Identity sui cluster della modalità automatica di EKS.
# Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs
Il tuo cluster dispone di un endpoint dell’API Kubernetes. Kubectl utilizza questa API. Puoi autenticarti su questa API usando due tipi di identità:
+ **Un principale (ruolo o utente) di AWS Identity and Access Management (IAM***): questo tipo richiede l'autenticazione su IAM.* Gli utenti possono accedere AWS come utenti [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) o con un'[identità federata](https://aws.amazon.com/identity/federation/) utilizzando le credenziali fornite tramite una fonte di identità. Gli utenti possono accedere solo con un’identità federata se l’amministratore ha configurato in precedenza la federazione delle identità utilizzando i ruoli IAM. Quando gli utenti accedono AWS utilizzando la federazione, [assumono](https://docs.aws.amazon.com/IAM/latest/UserGuide/when-to-use-iam.html#security-iam-authentication-iamrole) indirettamente un ruolo. Quando gli utenti utilizzano questo tipo di identità:
+ Puoi assegnare loro autorizzazioni Kubernetes in modo che possano lavorare con gli oggetti Kubernetes sul tuo cluster. Per ulteriori informazioni su come assegnare le autorizzazioni ai principali IAM in modo che possano accedere agli oggetti Kubernetes sul cluster, consulta la sezione [Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS](access-entries.md).
+ Puoi assegnare loro le autorizzazioni IAM in modo che possano lavorare con il tuo cluster Amazon EKS e le sue risorse utilizzando l'API Amazon EKS, la AWS CLI,, AWS CloudFormation o. Console di gestione AWS`eksctl` Per ulteriori informazioni, consulta [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) nella Documentazione di riferimento per l’autorizzazione ai servizi.
+ I nodi si aggiungono al cluster assumendo un ruolo IAM. La capacità di accedere al cluster utilizzando i principali (IAM) è abilitata dall’[autenticatore AWS IAM per Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme), che viene eseguito sul piano di controllo di Amazon EKS.
+ **Un utente del tuo provider OpenID Connect (OIDC)**: questo tipo richiede l’autenticazione al tuo provider [OIDC](https://openid.net/connect/). Per ulteriori informazioni sulla configurazione del provider OIDC con il cluster Amazon EKS, consulta [Concedere agli utenti l’accesso a Kubernetes con un provider OIDC esterno](authenticate-oidc-identity-provider.md). Quando gli utenti utilizzano questo tipo di identità:
+ Puoi assegnare loro autorizzazioni Kubernetes in modo che possano lavorare con gli oggetti Kubernetes sul tuo cluster.
+ Non puoi assegnare loro autorizzazioni IAM in modo che possano lavorare con il tuo cluster Amazon EKS e le sue risorse utilizzando l'API Amazon EKS, la AWS CLI,, AWS CloudFormation o. Console di gestione AWS`eksctl`
Puoi utilizzare entrambi i tipi di identità con il tuo cluster. Il metodo di autenticazione IAM non può essere disabilitato. Il metodo di autenticazione OIDC è facoltativo.
## Associa le identità IAM alle autorizzazioni Kubernetes
L’[Autenticatore AWS IAM per Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) è installato sul piano di controllo del tuo cluster. Abilita i principali [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) (ruoli e utenti) a cui consenti di accedere alle risorse Kubernetes sul tuo cluster. Puoi consentire ai principali IAM di accedere agli oggetti Kubernetes sul tuo cluster utilizzando uno dei metodi seguenti:
+ **Creazione di voci di accesso**: se la versione del cluster corrisponde o è successiva alla versione della piattaforma elencata nella sezione [Prerequisiti](access-entries.md) per la versione del cluster, ti consigliamo di utilizzare questa opzione.
Utilizza le *voci di accesso* per gestire le autorizzazioni Kubernetes dei principali IAM dall’esterno del cluster. Puoi aggiungere e gestire l'accesso al cluster utilizzando l'API EKS, l'interfaccia a riga di AWS comando e AWS SDKs. AWS CloudFormation Console di gestione AWS Ciò significa che puoi gestire gli utenti con gli stessi strumenti con cui hai creato il cluster.
Per iniziare, segui [Cambia la modalità di autenticazione per utilizzare le voci di accesso](setting-up-access-entries.md), quindi [Migrazione delle voci aws-auth esistenti alle ConfigMap voci](migrating-access-entries.md) di accesso.
+ **Aggiunta di voci a `aws-auth` `ConfigMap`**: se la versione della piattaforma del cluster è precedente alla versione elencata nella sezione [Prerequisiti](access-entries.md), è necessario utilizzare questa opzione. Se la versione della piattaforma del cluster corrisponde o è successiva a quella elencata nella sezione [Prerequisiti](access-entries.md) per la versione di Kubernetes del cluster e hai aggiunto delle voci a `ConfigMap`, ti consigliamo di eseguire la migrazione di tali voci per potervi accedere. Tuttavia, non puoi migrare le voci aggiunte da Amazon EKS a `ConfigMap`, come le voci per i ruoli IAM utilizzati con gruppi di nodi gestiti o profili Fargate. Per ulteriori informazioni, consulta [Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs](#grant-k8s-access).
+ Se è necessario utilizzare l’opzione `aws-auth` `ConfigMap`, è possibile aggiungere voci a `ConfigMap` utilizzando il comando `eksctl create iamidentitymapping`. Per ulteriori informazioni, consulta [Manage IAM users and roles](https://eksctl.io/usage/iam-identity-mappings/) nella documentazione di `eksctl`.
## Set Cluster Authentication Mode
Ogni cluster dispone di una *modalità di autenticazione*. La modalità di autenticazione determina quali metodi è possibile utilizzare per consentire ai principali IAM di accedere agli oggetti Kubernetes sul cluster. Sono disponibili tre modalità di autenticazione.
**Importante**
Una volta abilitato, il metodo di immissione dell’accesso non può essere disabilitato.
Se il metodo `ConfigMap` non è abilitato durante la creazione del cluster, non può essere abilitato in seguito. Tutti i cluster creati prima dell’introduzione delle voci di accesso hanno il metodo `ConfigMap` abilitato.
Se si utilizzano nodi ibridi con il cluster, è necessario utilizzare le modalità di autenticazione del cluster `API` o `API_AND_CONFIG_MAP`.
**Il `aws-auth` `ConfigMap` all’interno del cluster**
Questa è la modalità di autenticazione originale per i cluster Amazon EKS. Il principale IAM che ha creato il cluster è l’utente iniziale che può accedere al cluster utilizzando `kubectl`. L’utente iniziale deve aggiungere altri utenti all’elenco in `aws-auth` `ConfigMap` e assegnare autorizzazioni che influiscono sugli altri utenti all’interno del cluster. Questi altri utenti non possono gestire o rimuovere l’utente iniziale, poiché non c’è una voce da gestire in `ConfigMap`.
**Sia le voci di accesso che quelle di accesso `ConfigMap`**
Con questa modalità di autenticazione, è possibile utilizzare entrambi i metodi per aggiungere i principali IAM al cluster. Si noti che ogni metodo memorizza voci separate; ad esempio, se si aggiunge una voce di accesso dalla AWS CLI, non `aws-auth` `ConfigMap` viene aggiornata.
**Accedi solo alle voci**
Con questa modalità di autenticazione, puoi utilizzare l'API EKS, l'interfaccia Console di gestione AWS a riga di AWS comando e gestire l'accesso al cluster per i principali IAM. AWS SDKs AWS CloudFormation
Ogni voce di accesso include un *tipo*, che consente di utilizzare la combinazione di un *ambito di accesso* per limitare il principale a un namespace specifico e una *policy di accesso* per definire policy di autorizzazione riutilizzabili preconfigurate. In alternativa, è possibile utilizzare il tipo STANDARD e i gruppi Kubernetes RBAC per assegnare autorizzazioni personalizzate.
| Modalità di autenticazione | Metodi |
| --- | --- |
| Solo `ConfigMap` (`CONFIG_MAP`) | `aws-auth` `ConfigMap` |
| API EKS e `ConfigMap` (`API_AND_CONFIG_MAP`) | accedere alle voci nell'API EKS, AWS nell'interfaccia a riga di comando AWS SDKs AWS CloudFormation, e e Console di gestione AWS `aws-auth` `ConfigMap` |
| Solo API EKS (`API`) | accedere alle voci nell'API EKS, AWS nell'interfaccia a riga di comando AWS SDKs, AWS CloudFormation, e Console di gestione AWS |
**Nota**
La modalità automatica di Amazon EKS richiede le voci di accesso.
# Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS
Questa sezione è progettata per mostrarti come gestire l’accesso principale IAM ai cluster di Kubernetes in Amazon Elastic Kubernetes Service (EKS) utilizzando voci di accesso e policy. Sono disponibili dettagli sulla modifica delle modalità di autenticazione, la migrazione da voci `aws-auth` ConfigMap precedenti, la creazione, l’aggiornamento e l’eliminazione delle voci di accesso, l’associazione delle policy alle voci, la revisione delle autorizzazioni delle policy predefinite e i prerequisiti e le considerazioni chiave per la gestione sicura degli accessi.
## Panoramica
Le voci di accesso EKS sono il modo migliore per concedere agli utenti l’accesso all’API Kubernetes. Ad esempio, puoi utilizzare le voci di accesso per concedere agli sviluppatori l’accesso all’uso di kubectl. Fondamentalmente, una voce di accesso EKS associa un set di autorizzazioni di Kubernetes a un’identità IAM, ad esempio un ruolo IAM. Ad esempio, uno sviluppatore può assumere un ruolo IAM e utilizzarlo per autenticarsi in un cluster EKS.
## Funzionalità
+ **Autenticazione e autorizzazione centralizzate**: controlla l’accesso ai cluster di Kubernetes direttamente tramite le API di Amazon EKS, eliminando la necessità di passare fra AWS e le API Kubernetes per le autorizzazioni utente.
+ **Gestione granulare delle autorizzazioni**: utilizza le voci e le policy di accesso per definire autorizzazioni granulari per i principali IAM AWS, inclusa la modifica o la revoca dell’accesso da amministratore del cluster dal creatore.
+ **Integrazione con strumenti IaC**: supporta l’infrastruttura sotto forma di strumenti di codice come AWS CloudFormation, Terraform e AWS CDK per definire le configurazioni di accesso durante la creazione del cluster.
+ **Ripristino della configurazione errata**: consente di ripristinare l’accesso al cluster tramite l’API Amazon EKS senza accesso diretto all’API Kubernetes.
+ **Sovraccarico ridotto e sicurezza avanzata**: centralizza le operazioni per ridurre il sovraccarico sfruttando al contempo funzionalità IAM AWS come la registrazione degli audit CloudTrail e l’autenticazione a più fattori.
## Come allegare le autorizzazioni
Puoi allegare le autorizzazioni Kubernetes per accedere alle voci in due modi:
+ Utilizzare una policy di accesso. Le policy di accesso sono modelli di autorizzazioni di Kubernetes predefiniti gestiti da AWS. Per ulteriori informazioni, consulta [Rivedere le autorizzazioni della policy di accesso](access-policy-permissions.md).
+ Fare riferimento a un gruppo di Kubernetes. Se associ un’identità IAM a un gruppo di Kubernetes, puoi creare risorse di Kubernetes che concedono le autorizzazioni al gruppo. Per ulteriori informazioni, consulta [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) nella documentazione di Kubernetes.
## Considerazioni
Quando si abilitano le voci di accesso EKS sui cluster esistenti, tenere presente quanto segue:
+ **Comportamento legacy dei cluster**: per i cluster creati prima dell’introduzione delle voci di accesso (quelli con versioni iniziali della piattaforma precedenti a quelle specificate in [Platform version requirements](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)), EKS crea automaticamente una voce di accesso che riflette le autorizzazioni preesistenti. Questa voce include l’identità IAM che ha originariamente creato il cluster e le autorizzazioni amministrative concesse a tale identità durante la creazione del cluster.
+ **Gestione di `aws-auth` ConfigMap legacy**: se il cluster si basa su `aws-auth` ConfigMap legacy per la gestione degli accessi, dopo aver abilitato le voci di accesso, viene creata automaticamente solo la voce di accesso per il creatore del cluster originale. I ruoli o le autorizzazioni aggiuntivi aggiunti a ConfigMap (ad esempio, ruoli IAM personalizzati per sviluppatori o servizi) non vengono migrati automaticamente. Per risolvere questo problema, creare manualmente le voci di accesso corrispondenti.
## Inizia a usare
1. Determina l’identità IAM e la policy di accesso che desideri utilizzare.
+ [Rivedere le autorizzazioni della policy di accesso](access-policy-permissions.md)
1. Abilita le voci di accesso EKS sul cluster. Conferma di avere una versione della piattaforma supportata.
+ [Cambia la modalità di autenticazione per utilizzare le voci di accesso](setting-up-access-entries.md)
1. Creare una voce di accesso che associ un’identità IAM all’autorizzazione di Kubernetes.
+ [Creare voci di accesso](creating-access-entries.md)
1. Effettuare l’autenticazione nel cluster utilizzando l’identità IAM.
+ [Configurazione di AWS CLI](install-awscli.md)
+ [Impostazione di `kubectl` e `eksctl`](install-kubectl.md)
# Associare le policy di accesso alle voci di accesso
È possibile assegnare una o più policy di accesso alle *voci di accesso* di *tipo* `STANDARD`. Amazon EKS concede automaticamente agli altri tipi di voci di accesso le autorizzazioni necessarie per funzionare correttamente nel cluster. Le policy di accesso di Amazon EKS includono le autorizzazioni di Kubernetes, non le autorizzazioni IAM. Prima di associare una policy di accesso a una voce di accesso, assicurati di conoscere le autorizzazioni di Kubernetes incluse in ogni policy di accesso. Per ulteriori informazioni, consulta [Rivedere le autorizzazioni della policy di accesso](access-policy-permissions.md). Se nessuna delle policy di accesso soddisfa i requisiti, non associarne alcuna a una voce di accesso. Specificare invece uno o più *nomi dei gruppi* per la voce di accesso, e creare e gestire oggetti di controllo degli accessi basato sui ruoli di Kubernetes. Per ulteriori informazioni, consulta [Creare voci di accesso](creating-access-entries.md).
+ Una voce di accesso esistente. Per crearne uno, consulta [Creare voci di accesso](creating-access-entries.md).
+ Un ruolo o un utente AWS Identity and Access Management con le seguenti autorizzazioni: `ListAccessEntries`, `DescribeAccessEntry`, `UpdateAccessEntry`, `ListAccessPolicies`, `AssociateAccessPolicy` e `DisassociateAccessPolicy`. Per ulteriori informazioni, consulta [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) in *Service Authorization Reference*.
Prima di associare policy di accesso a voci di accesso, considera i seguenti requisiti:
+ È possibile associare più policy di accesso a ciascuna voce di accesso, ma è possibile associare ogni policy a una voce di accesso solo una volta. Se associ più policy di accesso, il principale IAM della voce di accesso dispone di tutte le autorizzazioni incluse in tutte le policy di accesso associate.
+ Puoi applicare una policy di accesso a tutte le risorse di un cluster o specificando il nome di uno o più namespace di Kubernetes. Puoi utilizzare caratteri jolly per il nome di un namespace. Ad esempio, se desideri applicare una policy di accesso a tutti i namespace che iniziano con `dev-`, puoi specificare `dev-*` come nome del namespace. Assicurati che i namespace siano presenti sul cluster e che quanto digitato corrisponda esattamente al nome reale del namespace sul cluster. Amazon EKS, infatti, non conferma l’ortografia o l’esistenza dei namespace sul cluster.
+ È possibile modificare l’*ambito di accesso* per una policy di accesso dopo averla associata a una voce di accesso. Se hai limitato l’ambito della policy di accesso ai namespace di Kubernetes, puoi aggiungere e rimuovere i namespace per l’associazione, secondo necessità.
+ Se associ una policy di accesso a una voce di accesso in cui sono specificati anche i *nomi dei gruppi*, il principale IAM dispone di tutte le autorizzazioni in tutte le policy di accesso associate. Inoltre, dispone di tutte le autorizzazioni in qualsiasi oggetto `Role` o `ClusterRole` di Kubernetes specificato in qualsiasi oggetto `Role` e `RoleBinding` di Kubernetes che specifica i nomi dei gruppi.
+ Se esegui il comando `kubectl auth can-i --list`, non vedrai alcun permesso di Kubernetes assegnato dalle policy di accesso associate a una voce di accesso per il principale IAM che stai utilizzando quando viene eseguito il comando. Il comando mostra le autorizzazioni di Kubernetes solo se le hai concesse a oggetti `Role` o `ClusterRole` di Kubernetes associati ai nomi dei gruppi o al nome utente specificato per una voce di accesso.
+ Se impersoni un utente o un gruppo di Kubernetes durante l’interazione con oggetti di Kubernetes sul cluster, ad esempio utilizzando il comando `kubectl` con `--as username ` o `--as-group group-name `, stai forzando l’uso dell’autorizzazione RBAC di Kubernetes. Di conseguenza, il principale IAM non dispone di autorizzazioni assegnate da alcuna policy di accesso associata alla voce di accesso. Le uniche autorizzazioni di Kubernetes di cui dispone l’utente o il gruppo che il principale IAM sta impersonando sono quelle di Kubernetes che hai concesso negli oggetti `Role` o `ClusterRole` di Kubernetes associati ai nomi dei gruppi o al nome utente. Per garantire che il principale IAM abbia le autorizzazioni nelle policy di accesso associate, evitare di impersonare un utente o un gruppo di Kubernetes. Il principale IAM avrà comunque anche tutte le autorizzazioni concesse negli oggetti `Role` o `ClusterRole` di Kubernetes associati ai nomi dei gruppi o al nome utente specificato per la voce di accesso. Per ulteriori informazioni, consulta [User impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) nella documentazione di Kubernetes.
Puoi associare una policy di accesso a una voce di accesso utilizzando Console di gestione AWS o AWS CLI.
## Console di gestione AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il nome del cluster con una voce di accesso da associare a una policy di accesso.
1. Scegliere la scheda **Accesso**.
1. Se il tipo di voce di accesso è **Standard**, puoi associare o dissociare **le policy di accesso** di Amazon EKS. Se il tipo di voce di accesso è diverso da **Standard**, questa opzione non è disponibile.
1. Scegliere **Associa policy di accesso**.
1. Per **Nome della policy**, seleziona la policy con le autorizzazioni che desideri assegnare al principale IAM. Per visualizzare i permessi inclusi in ciascuna policy, consulta [Rivedere le autorizzazioni della policy di accesso](access-policy-permissions.md).
1. Per **Ambito di accesso**, scegli un ambito di accesso. Se scegli **Cluster**, le autorizzazioni nella policy di accesso vengono concesse al principale IAM per le risorse in tutti i namespace di Kubernetes. Se scegli **Namespace di Kubernetes**, puoi scegliere **Aggiungi nuovo namespace**. Nel campo **Namespace** che appare, puoi inserire il nome di un namespace di Kubernetes sul cluster. Se desideri che il principale IAM disponga delle autorizzazioni su più namespace, puoi inserirne più di uno.
1. Scegliere **Aggiungi policy di accesso**.
## CLI AWS
1. La versione `2.12.3` o successive oppure `1.27.160` o successive dell’interfaccia a riga di comando AWS (AWS CLI) installata e configurata sul dispositivo o in AWS CloudShell. Per verificare la versione attuale, usa `aws --version | cut -d / -f2 | cut -d ' ' -f1`. I programmi di gestione dei pacchetti, come `yum`, `apt-get` o Homebrew per macOS, spesso sono aggiornati a versioni precedenti di AWS CLI. Per installare la versione più recente, consulta [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [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 dell’interfaccia a riga di comando AWS*. La versione della AWS CLI installata in AWS CloudShell potrebbe anche essere precedente di diverse versioni rispetto alla più recente. Per aggiornarla, consulta [Installing AWS CLI to your home directory](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) nella *Guida per l’utente di AWS CloudShell*.
1. Visualizza le policy di accesso disponibili.
```
aws eks list-access-policies --output table
```
Di seguito viene riportato un output di esempio.
```
---------------------------------------------------------------------------------------------------------
| ListAccessPolicies |
+-------------------------------------------------------------------------------------------------------+
|| accessPolicies ||
|+---------------------------------------------------------------------+-------------------------------+|
|| arn | name ||
|+---------------------------------------------------------------------+-------------------------------+|
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSAdminPolicy | AmazonEKSAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy | AmazonEKSClusterAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSEditPolicy | AmazonEKSEditPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSViewPolicy | AmazonEKSViewPolicy ||
|+---------------------------------------------------------------------+-------------------------------+|
```
Per visualizzare i permessi inclusi in ciascuna policy, consulta [Rivedere le autorizzazioni della policy di accesso](access-policy-permissions.md).
1. Visualizza le voci di accesso esistenti. Sostituisci *my-cluster* con il nome del cluster.
```
aws eks list-access-entries --cluster-name my-cluster
```
Di seguito viene riportato un output di esempio.
```
{
"accessEntries": [
"arn:aws:iam::111122223333:role/my-role",
"arn:aws:iam::111122223333:user/my-user"
]
}
```
1. Associa una policy di accesso a una voce di accesso. L’esempio seguente associa la policy di accesso `AmazonEKSViewPolicy` a una voce di accesso. Ogni volta che il ruolo IAM *my-role* tenta di accedere agli oggetti di Kubernetes sul cluster, Amazon EKS autorizzerà il ruolo a utilizzare le autorizzazioni della policy per accedere agli oggetti di Kubernetes solo nei namespace *my-namespace1* e *my-namespace2* di Kubernetes. Sostituisci *my-cluster* con il nome del cluster, *111122223333* con l’ID dell’account AWS e *my-role* con il nome del ruolo IAM che desideri che Amazon EKS autorizzi ad accedere agli oggetti del cluster di Kubernetes.
```
aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy
```
Se desideri che il principale IAM disponga delle autorizzazioni a livello di cluster, sostituisci `type=namespace,namespaces=my-namespace1,my-namespace2 ` con `type=cluster`. Se desideri associare più policy di accesso alla voce di accesso, esegui il comando più volte, ogni volta con una policy di accesso unica. Ogni policy di accesso associata ha il proprio ambito.
**Nota**
Se in seguito desideri modificare l’ambito di una policy di accesso associata, esegui nuovamente il comando precedente con il nuovo ambito. Ad esempio, se desideri rimuovere *my-namespace2*, eseguiresti nuovamente il comando utilizzando solo `type=namespace,namespaces=my-namespace1 `. Se desidera modificare l’ambito da `namespace` a `cluster`, esegui nuovamente il comando utilizzando `type=cluster` e rimuovendo `type=namespace,namespaces=my-namespace1,my-namespace2 `.
1. Determina quali policy di accesso sono associate a una voce di accesso.
```
aws eks list-associated-access-policies --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
Di seguito viene riportato un output di esempio.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333",
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster",
"namespaces": []
},
"associatedAt": "2023-04-17T15:25:21.675000-04:00",
"modifiedAt": "2023-04-17T15:25:21.675000-04:00"
},
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy",
"accessScope": {
"type": "namespace",
"namespaces": [
"my-namespace1",
"my-namespace2"
]
},
"associatedAt": "2023-04-17T15:02:06.511000-04:00",
"modifiedAt": "2023-04-17T15:02:06.511000-04:00"
}
]
}
```
Nell’esempio precedente, il principale IAM per questa voce di accesso ha permessi di visualizzazione in tutti i namespace del cluster e permessi di amministratore per due namespace di Kubernetes.
1. Dissociazione di una policy di accesso da una voce di accesso. In questo esempio, la policy `AmazonEKSAdminPolicy` è dissociata da una voce di accesso. Tuttavia, il principale IAM mantiene le autorizzazioni nella policy di accesso di `AmazonEKSViewPolicy` per gli oggetti nei namespace *my-namespace1* e *my-namespace2*, poiché tale policy di accesso non è dissociata dalla voce di accesso.
```
aws eks disassociate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy
```
Per elencare le policy di accesso disponibili, consultare [Rivedere le autorizzazioni della policy di accesso](access-policy-permissions.md).
# Migrazione delle voci `aws-auth ConfigMap` esistenti alle voci di accesso
Se hai aggiunto voci a `aws-auth` `ConfigMap` sul tuo cluster, ti consigliamo di creare voci di accesso per quelle esistenti in `aws-auth` `ConfigMap`. Dopo aver creato le voci di accesso, puoi rimuovere le voci da `ConfigMap`. Non puoi associare le [policy di accesso](access-policies.md) alle voci presenti in `aws-auth` `ConfigMap`. Se desideri associare policy di accesso ai tuoi principali IAM, crea voci di accesso.
**Importante**
Quando un cluster è in modalità di autenticazione `API_AND_CONFIGMAP` ed è presente una mappatura per lo stesso ruolo IAM sia in `aws-auth` `ConfigMap` che nelle voci di accesso, il ruolo utilizzerà la mappatura della voce di accesso per l’autenticazione. Le voci di accesso hanno la precedenza sulle voci `ConfigMap` dello stesso principale IAM.
Prima di rimuovere le voci `aws-auth` `ConfigMap` esistenti create da Amazon EKS per un [gruppo di nodi gestiti](managed-node-groups.md) o un [profilo Fargate](fargate-profile.md) nel tuo cluster, ricontrolla se nel tuo cluster Amazon EKS esistono le voci di accesso corrette per quelle risorse specifiche. Se rimuovi le voci che Amazon EKS ha creato in `ConfigMap` senza avere le voci di accesso equivalenti, il cluster non funzionerà correttamente.
## Prerequisiti
+ Familiarità con le voci di accesso e le policy di accesso. Per ulteriori informazioni, consulta [Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS](access-entries.md) e [Associare le policy di accesso alle voci di accesso](access-policies.md).
+ Un cluster esistente con una versione della piattaforma corrispondente o successiva alle versioni elencate nei Prerequisiti dell’argomento [Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS](access-entries.md).
+ 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`.
+ Le autorizzazioni di Kubernetes per modificare `aws-auth` `ConfigMap` nel namespace `kube-system`.
+ Un ruolo o un utente di AWS Identity and Access Management con le seguenti autorizzazioni: `CreateAccessEntry` e`ListAccessEntries`. Per ulteriori informazioni, consulta [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) nella Documentazione di riferimento per l’autorizzazione ai servizi.
## `eksctl`
1. Verifica le voci esistenti in `aws-auth ConfigMap`. Sostituisci *my-cluster* con il nome del cluster.
```
eksctl get iamidentitymapping --cluster my-cluster
```
Di seguito viene riportato un output di esempio.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/EKS-my-cluster-Admins Admins system:masters
arn:aws: iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers my-namespace-Viewers Viewers
arn:aws: iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws: iam::111122223333:user/my-user my-user
arn:aws: iam::111122223333:role/EKS-my-cluster-fargateprofile1 system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier
arn:aws: iam::111122223333:role/EKS-my-cluster-managed-ng system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. [Creare voci di accesso](creating-access-entries.md) per tutte le voci `ConfigMap` che hai creato e che sono state restituite nell’output precedente. Quando crei le voci di accesso, assicurati di specificare gli stessi valori per `ARN`, `USERNAME`, `GROUPS` e `ACCOUNT` restituiti nell’output. Nell’output di esempio, dovresti creare voci di accesso per tutte le voci tranne le ultime due, poiché tali voci sono state create da Amazon EKS per un profilo Fargate e un gruppo di nodi gestito.
1. Elimina le voci da `ConfigMap` per tutte le voci di accesso che hai creato. Se non elimini la voce da `ConfigMap`, le impostazioni per la voce di accesso per l’ARN principale IAM hanno la precedenza sulla voce `ConfigMap`. Sostituiscilo *111122223333* con l'ID del tuo AWS account e *EKS-my-cluster-my-namespace-Viewers* con il nome del ruolo nella voce del tuo`ConfigMap`. Se la voce che stai rimuovendo riguarda un utente IAM, anziché un ruolo IAM, `role` sostituiscila con `user` e *EKS-my-cluster-my-namespace-Viewers* con il nome utente.
```
eksctl delete iamidentitymapping --arn arn:aws: iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --cluster my-cluster
```
# Rivedere le autorizzazioni della policy di accesso
Le policy di accesso includono `rules` che contengono `verbs` di Kubernetes (autorizzazioni) e `resources`. Le policy di accesso non includono le autorizzazioni o le risorse IAM. Analogamente agli oggetti `Role` e `ClusterRole` di Kubernetes, le policy di accesso includono solo `allow` `rules`. Non puoi modificare il contenuto di una policy di accesso. Non puoi creare policy di accesso personalizzate. Se le autorizzazioni nelle policy di accesso non soddisfano le tue esigenze, crea oggetti RBAC di Kubernetes e specificare *nomi dei gruppi* per le voci di accesso. Per ulteriori informazioni, consulta [Creare voci di accesso](creating-access-entries.md). Le autorizzazioni contenute nelle policy di accesso sono simili a quelle nei ruoli del cluster rivolti agli utenti di Kubernetes. Per ulteriori informazioni, consulta [User-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) nella documentazione di Kubernetes.
## Elencare tutte le policy
Utilizza una delle politiche di accesso elencate in questa pagina o recupera un elenco di tutte le politiche di accesso disponibili utilizzando la AWS CLI:
```
aws eks list-access-policies
```
L’output previsto dovrebbe essere simile al seguente (abbreviato per brevità):
```
{
"accessPolicies": [
{
"name": "AmazonAIOpsAssistantPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonAIOpsAssistantPolicy"
},
{
"name": "AmazonARCRegionSwitchScalingPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy"
},
{
"name": "AmazonEKSAdminPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
},
{
"name": "AmazonEKSAdminViewPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy"
},
{
"name": "AmazonEKSAutoNodePolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy"
}
// Additional policies omitted
]
}
```
## EKSAdminPolitica di Amazon
Questa policy di accesso include autorizzazioni che concedono a un principale IAM la maggior parte delle autorizzazioni per le risorse. Quando è associato a una voce di accesso, il relativo ambito di accesso è in genere uno o più namespace di Kubernetes. Se invece desideri che un principale IAM disponga dell’accesso di amministratore a tutte le risorse del cluster, allora associa la policy di accesso [Amazon EKSCluster AdminPolicy](#access-policy-permissions-amazoneksclusteradminpolicy) alla voce di accesso.
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAdminPolicy`
| Gruppi di API Kubernetes | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `authorization.k8s.io` | `localsubjectaccessreviews` | `create` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| `rbac.authorization.k8s.io` | `rolebindings`, `roles` | `create`, `delete`, `deletecollection`, `get`, `list`, `patch`, `update`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`,`list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `serviceaccounts` | `impersonate` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`,`list`, `watch` |
## Amazon EKSCluster AdminPolicy
Questa policy di accesso include le autorizzazioni che concedono a un principale IAM l’accesso di amministratore per un cluster. Quando è associato a una voce di accesso, il relativo ambito di accesso è in genere il cluster, anziché un namespace di Kubernetes. Se desideri che un principale IAM abbia un ambito amministrativo più limitato, valuta invece la possibilità di associare la policy di accesso [EKSAdminPolitica di Amazon](#access-policy-permissions-amazoneksadminpolicy) alla voce di accesso.
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`
| Gruppi di API Kubernetes | Kubernetes NonResource URLs | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- | --- |
| `*` | | `*` | `*` |
| | `*` | | `*` |
## Amazon EKSAdmin ViewPolicy
Questa politica di accesso include autorizzazioni che garantiscono un accesso principale IAM a list/view tutte le risorse di un cluster. Questo include [Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/).
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy`
| Gruppi di API Kubernetes | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- |
| `*` | `*` | `get`, `list`, `watch` |
## EKSEditPolitica di Amazon
Questa policy di accesso include autorizzazioni che consentono a un principale IAM di modificare la maggior parte delle risorse di Kubernetes.
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSEditPolicy`
| Gruppi di API Kubernetes | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `serviceaccounts` | `impersonate` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
## EKSViewPolitica di Amazon
Questa policy di accesso include autorizzazioni che consentono a un principale IAM di visualizzare la maggior parte delle risorse di Kubernetes.
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy`
| Gruppi di API Kubernetes | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, r`esourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
## Amazon EKSSecret ReaderPolicy
Questa politica di accesso include autorizzazioni che consentono a un preside IAM di leggere [Kubernetes](https://kubernetes.io/docs/concepts/configuration/secret/) Secrets.
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy`
| Gruppi di API Kubernetes | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- |
| | `secrets` | `get`, `list`, `watch` |
## Amazon EKSAuto NodePolicy
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy`
Questa policy include le seguenti autorizzazioni che consentono ai componenti di Amazon EKS di completare le attività seguenti:
+ `kube-proxy`: monitorare gli endpoint e i servizi di rete e gestire gli eventi correlati. Ciò consente la funzionalità proxy di rete a livello di cluster.
+ `ipamd`— Gestione delle risorse di rete AWS VPC e delle interfacce di rete container (CNI). Ciò consente al daemon di gestione degli indirizzi IP di gestire il networking dei pod.
+ `coredns`: accedere a risorse di rilevamento servizi come endpoint e servizi. Ciò consente la risoluzione DNS all’interno del cluster.
+ `ebs-csi-driver`: lavorare con risorse relative all’archiviazione per i volumi Amazon EBS. Ciò consente il provisioning e il collegamento dinamico di volumi persistenti.
+ `neuron`— Monitora nodi e pod per i dispositivi Neuron. AWS Ciò consente la gestione degli acceleratori AWS Inferentia e Trainium.
+ `node-monitoring-agent`: accedere alla diagnostica dei nodi e agli eventi. Ciò consente il monitoraggio dell’integrità del cluster e la raccolta della diagnostica.
Ogni componente utilizza un account di servizio dedicato ed è limitato alle sole autorizzazioni necessarie per la sua funzione specifica.
Se specifichi manualmente un ruolo Node IAM in a NodeClass, devi creare un Access Entry che associ il nuovo ruolo Node IAM a questa policy di accesso.
## Amazon EKSBlock StoragePolicy
**Nota**
Questa politica è destinata solo ai ruoli AWS collegati ai servizi e non può essere utilizzata con ruoli gestiti dal cliente.
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSBlockStoragePolicy`
Questa policy include le autorizzazioni che consentono ad Amazon EKS di gestire le risorse per l’elezione e il coordinamento dei leader per le operazioni di archiviazione:
+ `coordination.k8s.io`: creare e gestire oggetti in leasing per l’elezione dei leader. Ciò consente ai componenti di archiviazione EKS di coordinare le proprie attività all’interno del cluster attraverso un meccanismo di elezione dei leader.
La policy si applica a specifiche risorse di leasing utilizzate dai componenti di archiviazione EKS per prevenire conflitti di accesso ad altre risorse di coordinamento del cluster.
Amazon EKS crea automaticamente una voce di accesso con questa policy di accesso per il ruolo IAM del cluster quando Auto Mode è abilitata, garantendo che siano disponibili le autorizzazioni necessarie per il corretto funzionamento della capacità di storage a blocchi.
## Amazon EKSLoad BalancingPolicy
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSLoadBalancingPolicy`
Questa policy include le autorizzazioni che consentono ad Amazon EKS di gestire le risorse per le elezioni per i leader per il bilanciamento del carico:
+ `coordination.k8s.io`: creare e gestire oggetti in leasing per l’elezione dei leader. Ciò consente ai componenti di bilanciamento del carico EKS di coordinare le attività su più repliche eleggendo un leader.
La policy riguarda specificamente il bilanciamento del carico delle risorse di leasing per garantire un coordinamento adeguato impedendo al contempo l’accesso ad altre risorse di leasing del cluster.
Amazon EKS crea automaticamente una voce di accesso con questa policy di accesso per il ruolo IAM del cluster quando Auto Mode è abilitata, garantendo che siano disponibili le autorizzazioni necessarie per il corretto funzionamento della capacità di rete.
## EKSNetworkingPolitica di Amazon
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSNetworkingPolicy`
Questa policy include le autorizzazioni che consentono ad Amazon EKS di gestire le risorse per le elezioni dei leader per le reti:
+ `coordination.k8s.io`: creare e gestire oggetti in leasing per l’elezione dei leader. Ciò consente ai componenti di rete EKS di coordinare le attività di allocazione degli indirizzi IP eleggendo un leader.
La policy riguarda specificamente le reti delle risorse di leasing per garantire un coordinamento adeguato impedendo al contempo l’accesso ad altre risorse di leasing del cluster.
Amazon EKS crea automaticamente una voce di accesso con questa policy di accesso per il ruolo IAM del cluster quando Auto Mode è abilitata, garantendo che siano disponibili le autorizzazioni necessarie per il corretto funzionamento della capacità di rete.
## EKSComputePolitica di Amazon
**Nota**
Questa politica è destinata solo ai ruoli AWS collegati ai servizi e non può essere utilizzata con ruoli gestiti dal cliente.
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSComputePolicy`
Questa policy include le autorizzazioni che consentono ad Amazon EKS di gestire le risorse per l’elezione dei leader per le operazioni di elaborazione:
+ `coordination.k8s.io`: creare e gestire oggetti in leasing per l’elezione dei leader. Ciò consente ai componenti di elaborazione EKS di coordinare le attività di scalabilità dei nodi eleggendo un leader.
La policy riguarda specificamente la gestione delle risorse di elaborazione in leasing e consente al contempo l’accesso di base in lettura (`get`, `watch`) a tutte le risorse di leasing del cluster.
Amazon EKS crea automaticamente una voce di accesso con questa policy di accesso per il ruolo IAM del cluster quando Auto Mode è abilitata, garantendo che siano disponibili le autorizzazioni necessarie per il corretto funzionamento della capacità di rete.
## Amazon EKSBlock StorageClusterPolicy
**Nota**
Questa politica è destinata solo ai ruoli AWS collegati ai servizi e non può essere utilizzata con ruoli gestiti dal cliente.
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSBlockStorageClusterPolicy`
Questa policy concede le autorizzazioni necessarie per la funzionalità di storage a blocchi della modalità automatica di Amazon EKS. Consente una gestione efficiente delle risorse di archiviazione a blocchi all’interno dei cluster Amazon EKS. La policy include le seguenti autorizzazioni:
Gestione del driver CSI:
+ Creare, leggere, aggiornare ed eliminare i driver CSI, in particolare per l’archiviazione a blocchi.
Gestione dei volumi:
+ Elencare, guardare, creare, aggiornare, applicare patch ed eliminare i volumi persistenti.
+ Elencare, guardare e aggiornare le dichiarazioni di volume persistenti.
+ Applicare patch agli stati di dichiarazione di volume persistente.
Interazione tra nodi e pod:
+ Leggere le informazioni su nodi e pod.
+ Gestire gli eventi relativi alle operazioni di archiviazione.
Classi e attributi di archiviazione:
+ Leggere le classi di archiviazione e i nodi CSI.
+ Leggere le classi di attributi del volume.
Allegati dei volumi:
+ Elencare, guardare e modificare gli allegati del volume e il relativo stato.
Operazioni di snapshot:
+ Gestire snapshot di volume, contenuti di snapshot e classi di snapshot.
+ Gestire le operazioni per gli snapshot dei gruppi di volumi e le risorse correlate.
Questa policy è progettata per supportare la gestione completa dell’archiviazione a blocchi all’interno dei cluster Amazon EKS in esecuzione in Auto Mode. Combina le autorizzazioni per varie operazioni, tra cui il provisioning, il collegamento, il ridimensionamento e la creazione di snapshot di volumi di archiviazione a blocchi.
Amazon EKS crea automaticamente una voce di accesso con questa policy di accesso per il ruolo IAM del cluster quando Auto Mode è abilitata, garantendo che siano disponibili le autorizzazioni necessarie per il corretto funzionamento della capacità di storage a blocchi.
## Amazon EKSCompute ClusterPolicy
**Nota**
Questa politica è destinata solo ai ruoli AWS collegati ai servizi e non può essere utilizzata con ruoli gestiti dal cliente.
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSComputeClusterPolicy`
Questa policy concede le autorizzazioni necessarie per la funzionalità di gestione dell’elaborazione della modalità automatica di Amazon EKS. Consente l’orchestrazione e la scalabilità efficienti delle risorse di elaborazione all’interno dei cluster Amazon EKS. La policy include le seguenti autorizzazioni:
Gestione dei nodi:
+ Crea, leggi, aggiorna, elimina e gestisci lo stato di e. NodePools NodeClaims
+ Gestione NodeClasses, inclusa la creazione, la modifica e l'eliminazione.
Pianificazione e gestione delle risorse:
+ Accesso in lettura a pod, nodi, volumi persistenti, attestazioni di volume persistenti, controller di replica e namespace.
+ Accesso in lettura alle classi di archiviazione, ai nodi CSI e agli allegati dei volumi.
+ Elencare e controllare implementazioni, set di daemon, set di repliche e set stateful.
+ Leggere i budget di interruzione dei pod.
Gestione degli eventi:
+ Creare, leggere e gestire gli eventi del cluster.
Revoca del provisioning dei nodi ed espulsione dei pod:
+ Aggiornare, applicare patch ed eliminare i nodi.
+ Creare espulsioni dei pod ed eliminarli quando necessario.
Gestione di definizione di risorse personalizzate (CRD):
+ Crea nuovo CRDs.
+ Gestisci specifiche CRDs relative alla gestione dei nodi (NodeClasses NodePools, NodeClaims, e NodeDiagnostics).
Questa policy è progettata per supportare la gestione completa dell’elaborazione all’interno dei cluster Amazon EKS in esecuzione in Auto Mode. Combina le autorizzazioni per varie operazioni, tra cui il provisioning dei nodi, la pianificazione, la scalabilità e l’ottimizzazione delle risorse.
Amazon EKS crea automaticamente una voce di accesso con questa policy di accesso per il ruolo IAM del cluster quando Auto Mode è abilitata, garantendo che siano disponibili le autorizzazioni necessarie per il corretto funzionamento della capacità di gestione di elaborazione.
## Amazon EKSLoad BalancingClusterPolicy
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSLoadBalancingClusterPolicy`
Questa policy concede le autorizzazioni necessarie per la funzionalità di bilanciamento del carico della modalità automatica di Amazon EKS. Consente una configurazione e una gestione efficiente delle risorse di bilanciamento del carico all’interno dei cluster Amazon EKS. La policy include le seguenti autorizzazioni:
Gestione di eventi e risorse:
+ Creare e applicare patch agli eventi.
+ Accesso in lettura a pod, nodi, endpoint e namespace.
+ Aggiornare gli stati dei pod.
Gestione dei servizi e degli ingressi:
+ Gestione completa dei servizi e dei relativi stati.
+ Controllo completo sugli ingressi e sui relativi stati.
+ Accesso in lettura alle sezioni degli endpoint e alle classi di ingresso.
Associazioni per gruppi di destinazione:
+ Creare e modificare le associazioni per gruppi di destinazione e i relativi stati.
+ Accesso in lettura ai parametri della classe di ingresso.
Gestione di definizione di risorse personalizzate (CRD):
+ Crea e leggi tutto CRDs.
+ Gestione specifica di targetgroupbindings.eks.amazonaws.com e ingressclassparams.eks.amazonaws.com. CRDs
Configurazione Webhook:
+ Creare e leggere configurazioni webhook mutanti e convalidanti.
+ eks-load-balancing-webhookGestisci la configurazione.
Questa policy è progettata per supportare la gestione completa del bilanciamento del carico all’interno dei cluster Amazon EKS in esecuzione in Auto Mode. Combina le autorizzazioni per varie operazioni, tra cui esposizione del servizio, routing in ingresso e integrazione con i servizi di bilanciamento AWS del carico.
Amazon EKS crea automaticamente una voce di accesso con questa policy di accesso per il ruolo IAM del cluster quando Auto Mode è abilitata, garantendo che siano disponibili le autorizzazioni necessarie per il corretto funzionamento della capacità di bilanciamento del carico.
## Amazon EKSNetworking ClusterPolicy
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSNetworkingClusterPolicy`
Amazon EKSNetworking ClusterPolicy
Questa policy concede le autorizzazioni necessarie per la funzionalità di rete della modalità automatica di Amazon EKS. Consente una configurazione e una gestione efficiente delle risorse di rete all’interno dei cluster Amazon EKS. La policy include le seguenti autorizzazioni:
Gestione di nodi e pod:
+ Leggi gli accessi NodeClasses e i relativi stati.
+ Leggi gli accessi NodeClaims e i relativi stati.
+ Accesso in lettura ai pod.
Gestione dei nodi CNI:
+ Autorizzazioni CNINodes e relativi stati, tra cui creazione, lettura, aggiornamento, eliminazione e patch.
Gestione di definizione di risorse personalizzate (CRD):
+ Crea e leggi tutto. CRDs
+ Gestione specifica (aggiornamento, applicazione di patch, eliminazione) della CRD cninodes.eks.amazonaws.com.
Gestione degli eventi:
+ Creare e applicare patch agli eventi.
Questa policy è progettata per supportare la gestione completa della rete all’interno dei cluster Amazon EKS in esecuzione in Auto Mode. Combina le autorizzazioni per varie operazioni, tra cui la configurazione di rete dei nodi, la gestione della CNI (Container Network Interface) e la relativa gestione personalizzata delle risorse.
La policy consente ai componenti di rete di interagire con le risorse relative ai nodi, gestire le configurazioni dei nodi specifiche per CNI e gestire le risorse personalizzate fondamentali per le operazioni di rete nel cluster.
Amazon EKS crea automaticamente una voce di accesso con questa policy di accesso per il ruolo IAM del cluster quando Auto Mode è abilitata, garantendo che siano disponibili le autorizzazioni necessarie per il corretto funzionamento della capacità di rete.
## EKSHybridPolitica di Amazon
**Nota**
Questa politica è destinata solo ai ruoli AWS collegati ai servizi e non può essere utilizzata con ruoli gestiti dal cliente.
Questa policy di accesso include le autorizzazioni che concedono a EKS l’accesso di EKS ai nodi di un cluster. Quando è associato a una voce di accesso, il relativo ambito di accesso è in genere il cluster, anziché un namespace di Kubernetes. Questa policy viene utilizzata da Amazon EKS Hybrid Nodes.
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSHybridPolicy`
| Gruppi di API Kubernetes | Kubernetes NonResource URLs | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- | --- |
| `*` | | `nodes` | `list` |
## Amazon EKSCluster InsightsPolicy
**Nota**
Questa politica è destinata solo ai ruoli AWS collegati ai servizi e non può essere utilizzata con ruoli gestiti dal cliente.
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSClusterInsightsPolicy`
Questa policy concede le autorizzazioni di sola lettura alla funzionalità di approfondimenti del cluster di Amazon EKS. La policy include le seguenti autorizzazioni:
Accesso ai nodi: - Elencare e visualizzare i nodi del cluster - Leggere le informazioni sullo stato dei nodi
DaemonSet Accesso: - Accesso in lettura alla configurazione kube-proxy
Questa policy viene gestita automaticamente dal servizio EKS per gli approfondimenti del cluster. Per ulteriori informazioni, consulta [Prepararsi agli aggiornamenti delle versioni di Kubernetes e risolvere i problemi di configurazione errata con gli approfondimenti sui cluster](cluster-insights.md).
## AWSBackupFullAccessPolicyForBackup
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForBackup`
AWSBackupFullAccessPolicyForBackup
Questa politica concede le autorizzazioni necessarie a AWS Backup per gestire e creare backup del cluster EKS. Questa policy include le seguenti autorizzazioni:
| Gruppi di API Kubernetes | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- |
| `*` | `*` | `list`, `get` |
## AWSBackupFullAccessPolicyForRestore
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForRestore`
AWSBackupFullAccessPolicyForRestore
Questa politica concede le autorizzazioni necessarie a AWS Backup per gestire e ripristinare i backup del cluster EKS. Questa policy include le seguenti autorizzazioni:
| Gruppi di API Kubernetes | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- |
| `*` | `*` | `list`, `get`, `create` |
## Amazon EKSACKPolicy
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSACKPolicy`
Questa politica concede le autorizzazioni necessarie per consentire AWS ai Controllers for Kubernetes (ACK) di gestire le risorse di Kubernetes. AWS La policy include le seguenti autorizzazioni:
Gestione personalizzata delle risorse ACK:
+ Accesso completo a tutte le risorse personalizzate del servizio ACK su oltre 50 AWS servizi tra cui S3, RDS, DynamoDB, Lambda, EC2 e altri.
+ Crea, leggi, aggiorna ed elimina le definizioni delle risorse personalizzate ACK.
Accesso al namespace:
+ Accesso in lettura ai namespace per l'organizzazione delle risorse.
Elezione del leader:
+ Crea e leggi i contratti di coordinamento per l'elezione del leader.
+ Aggiorna ed elimina i leasing specifici dei controller di servizio ACK.
Gestione degli eventi:
+ Crea e correggi eventi per le operazioni ACK.
Questa policy è progettata per supportare la gestione completa AWS delle risorse tramite Kubernetes APIs. Amazon EKS crea automaticamente una voce di accesso con questa policy di accesso per la funzionalità (ruolo IAM) che fornisci quando viene creata la funzionalità ACK.
| Gruppi di API Kubernetes | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- |
| | `namespaces` | `get`, `watch`, `list` |
| `services.k8s.aws`, `acm.services.k8s.aws`, `acmpca.services.k8s.aws`, `apigateway.services.k8s.aws`, `apigatewayv2.services.k8s.aws`, `applicationautoscaling.services.k8s.aws`, `athena.services.k8s.aws`, `bedrock.services.k8s.aws`, `bedrockagent.services.k8s.aws`, `bedrockagentcorecontrol.services.k8s.aws`, `cloudfront.services.k8s.aws`, `cloudtrail.services.k8s.aws`, `cloudwatch.services.k8s.aws`, `cloudwatchlogs.services.k8s.aws`, `codeartifact.services.k8s.aws`, `cognitoidentityprovider.services.k8s.aws`, `documentdb.services.k8s.aws`, `dynamodb.services.k8s.aws`, `ec2.services.k8s.aws`, `ecr.services.k8s.aws`, `ecrpublic.services.k8s.aws`, `ecs.services.k8s.aws`, `efs.services.k8s.aws`, `eks.services.k8s.aws`, `elasticache.services.k8s.aws`, `elbv2.services.k8s.aws`, `emrcontainers.services.k8s.aws`, `eventbridge.services.k8s.aws`, `iam.services.k8s.aws`, `kafka.services.k8s.aws`, `keyspaces.services.k8s.aws`, `kinesis.services.k8s.aws`, `kms.services.k8s.aws`, `lambda.services.k8s.aws`, `memorydb.services.k8s.aws`, `mq.services.k8s.aws`, `networkfirewall.services.k8s.aws`, `opensearchservice.services.k8s.aws`, `organizations.services.k8s.aws`, `pipes.services.k8s.aws`, `prometheusservice.services.k8s.aws`, `ram.services.k8s.aws`, `rds.services.k8s.aws`, `recyclebin.services.k8s.aws`, `route53.services.k8s.aws`, `route53resolver.services.k8s.aws`, `s3.services.k8s.aws`, `s3control.services.k8s.aws`, `sagemaker.services.k8s.aws`, `secretsmanager.services.k8s.aws`, `ses.services.k8s.aws`, `sfn.services.k8s.aws`, `sns.services.k8s.aws`, `sqs.services.k8s.aws`, `ssm.services.k8s.aws`, `wafv2.services.k8s.aws` | `*` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`(solo leasing di controller di servizio ACK specifici) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
## EKSArgoCDClusterPolitica di Amazon
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`
Questa politica concede le autorizzazioni a livello di cluster necessarie per consentire alla funzionalità di Argo CD di scoprire risorse e gestire oggetti con ambito cluster. La policy include le seguenti autorizzazioni:
Gestione del namespace:
+ Crea, leggi, aggiorna ed elimina i namespace per la gestione dei namespace delle applicazioni.
Gestione personalizzata delle definizioni delle risorse:
+ Gestione di Argo CD specifici CRDs (applicazioni,, AppProjects). ApplicationSets
Scoperta delle API:
+ Accesso in lettura agli endpoint dell'API Kubernetes per la scoperta delle risorse.
Questa policy è progettata per supportare le operazioni Argo CD a livello di cluster, tra cui la gestione dei namespace e l'installazione di CRD. Amazon EKS crea automaticamente una voce di accesso con questa politica di accesso per la funzionalità (ruolo IAM) che fornisci quando viene creata la funzionalità Argo CD.
| Gruppi di API Kubernetes | Kubernetes NonResource URLs | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- | --- |
| | | `namespaces` | `create`, `get`, `update`, `patch`, `delete` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` | `create` |
| `apiextensions.k8s.io` | | `customresourcedefinitions`(Solo Argo CD) CRDs | `get`, `update`, `patch`, `delete` |
| | `/api`, `/api/*`, `/apis`, `/apis/*` | | `get` |
## Amazon EKSArgo CDPolicy
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`
Questa politica concede le autorizzazioni a livello di namespace necessarie per consentire alla funzionalità di Argo CD di distribuire e gestire le applicazioni. La policy include le seguenti autorizzazioni:
Gestione segreta:
+ Accesso completo ai segreti per le credenziali Git e i segreti del cluster.
ConfigMap Accesso:
+ Accesso in lettura per ConfigMaps inviare avvisi se i clienti cercano di utilizzare un CD Argo non supportato. ConfigMaps
Gestione degli eventi:
+ Leggi e crea eventi per il monitoraggio del ciclo di vita delle applicazioni.
Gestione delle risorse Argo CD:
+ Accesso completo alle applicazioni ApplicationSets, e AppProjects.
+ Gestisci i finalizzatori e lo stato delle risorse Argo CD.
Questa policy è progettata per supportare le operazioni di Argo CD a livello di namespace, tra cui la distribuzione e la gestione delle applicazioni. Amazon EKS crea automaticamente una voce di accesso con questa policy di accesso per la funzionalità (ruolo IAM) che fornisci al momento della creazione della funzionalità Argo CD, nell'ambito dello spazio dei nomi Argo CD.
| Gruppi di API Kubernetes | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- |
| | `secrets` | `*` |
| | `configmaps` | `get`, `list`, `watch` |
| | `events` | `get`, `list`, `watch`, `patch`, `create` |
| `argoproj.io` | `applications`, `applications/finalizers`, `applications/status`, `applicationsets`, `applicationsets/finalizers`, `applicationsets/status`, `appprojects`, `appprojects/finalizers`, `appprojects/status` | `*` |
## Amazon EKSKROPolicy
**ARN**: ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSKROPolicy`
Questa politica concede le autorizzazioni necessarie per consentire a kro (Kube Resource Orchestrator) di creare e gestire Kubernetes personalizzati. APIs La policy include le seguenti autorizzazioni:
Gestione delle risorse kro:
+ Accesso completo a tutte le risorse kro, comprese le istanze ResourceGraphDefinitions di risorse personalizzate.
Gestione personalizzata della definizione delle risorse:
+ Crea, leggi, aggiorna ed elimina CRDs per impostazioni personalizzate APIs definite da ResourceGraphDefinitions.
Elezione del leader:
+ Crea e leggi i contratti di coordinamento per l'elezione del leader.
+ Aggiorna ed elimina il contratto di locazione del controller kro.
Gestione degli eventi:
+ Crea e correggi eventi per le operazioni kro.
Questa politica è progettata per supportare la composizione completa delle risorse e la gestione personalizzata delle API tramite kro. Amazon EKS crea automaticamente una voce di accesso con questa policy di accesso per la funzionalità (ruolo IAM) che fornisci quando viene creata la funzionalità kro.
| Gruppi di API Kubernetes | Risorse di Kubernetes | Verbi di Kubernetes (autorizzazioni) |
| --- | --- | --- |
| `kro.run` | `*` | `*` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`(solo controller kro lease) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
## Aggiornamenti della policy di accesso
Visualizza i dettagli sugli aggiornamenti alle policy di accesso, da quando sono stati introdotti. Per gli avvisi automatici sulle modifiche apportate a questa pagina, iscriviti al feed RSS in [Cronologia dei documenti](doc-history.md).
| Modifica | Descrizione | Data |
| --- | --- | --- |
| Aggiungi politiche per EKS Capabilities | Pubblica `AmazonEKSACKPolicy` `AmazonEKSArgoCDClusterPolicy``AmazonEKSArgoCDPolicy`, e `AmazonEKSKROPolicy` per la gestione delle funzionalità EKS | 22 novembre 2025 |
| Add `AmazonEKSSecretReaderPolicy` | Aggiungi una nuova politica per l'accesso in sola lettura ai segreti | 6 novembre 2025 |
| Aggiungi una policy per gli approfondimenti sui cluster di EKS | Pubblica `AmazonEKSClusterInsightsPolicy` | 2 dicembre 2024 |
| Aggiungi policy per Amazon EKS Hybrid | Pubblica `AmazonEKSHybridPolicy` | 2 dicembre 2024 |
| Aggiungi policy per la modalità automatica di Amazon EKS | Queste policy di accesso autorizzano Cluster IAM Role e Node IAM Role a chiamare APIs Kubernetes. AWS li utilizza per automatizzare le attività di routine per le risorse di archiviazione, elaborazione e rete. | 2 dicembre 2024 |
| Add `AmazonEKSAdminViewPolicy` | Aggiungi una nuova policy per un accesso esteso alle visualizzazioni, incluse risorse come Secrets. | 23 aprile 2024 |
| Policy di accesso introdotte. | Amazon EKS ha introdotto policy di accesso. | 29 maggio 2023 |
# Cambia la modalità di autenticazione per utilizzare le voci di accesso
Per iniziare a utilizzare le voci di accesso, è necessario modificare la modalità di autenticazione del cluster nelle modalità `API_AND_CONFIG_MAP` o `API`. Questa operazione aggiunge l'API per le voci di accesso.
## Console AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il nome del cluster in cui desideri creare una voce di accesso.
1. Scegli la scheda **Accesso**.
1. **Modalità di autenticazione** mostra la modalità corrente di autenticazione del cluster. Se la modalità mostra API EKS, puoi già aggiungere voci di accesso e puoi saltare i passaggi rimanenti.
1. Scegli **Gestisci accesso**.
1. Per **Modalità di autenticazione del cluster**, seleziona una modalità con l’API EKS. Nota che non è possibile ripristinare la modalità di autenticazione in una modalità che rimuove l’API EKS e le voci di accesso.
1. Scegli **Save changes** (Salva modifiche). Amazon EKS inizia ad aggiornare il cluster, lo stato del cluster cambia in In aggiornamento e la modifica è registrata nella scheda **Cronologia degli aggiornamenti**.
1. Attendi che lo stato del cluster ritorni su Attivo. Quando il cluster è Attivo, è possibile seguire i passaggi indicati in [Creare voci di accesso](creating-access-entries.md) per aggiungere l’accesso al cluster per i principali IAM.
## CLI AWS
1. Installa AWS CLI come descritto in [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) nella *Guida per l’utente dell’interfaccia a riga di comando AWS*.
1. Esegui il comando seguente. Sostituisci *my-cluster* con il nome del tuo cluster. Se desideri disabilitare il metodo `ConfigMap` in modo permanente, sostituisci `API_AND_CONFIG_MAP` con `API`.
Amazon EKS inizia ad aggiornare il cluster, lo stato del cluster cambia in IN AGGIORNAMENTO e la modifica è registrata negli ** aggiornamenti dell’elenco eks aws **.
```
aws eks update-cluster-config --name my-cluster --access-config authenticationMode=API_AND_CONFIG_MAP
```
1. Attendi che lo stato del cluster ritorni su Attivo. Quando il cluster è Attivo, è possibile seguire i passaggi indicati in [Creare voci di accesso](creating-access-entries.md) per aggiungere l’accesso al cluster per i principali IAM.
## Versione della piattaforma richiesta
Per utilizzare le *voci di accesso*, 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. Se la tua versione di Kubernetes non è elencata, tutte le versioni della piattaforma supportano le voci di accesso.
| Versione di Kubernetes 1.15 | Versione della piattaforma |
| --- | --- |
| Non elencata | Tutte supportate |
| `1.30` | `eks.2` |
| `1.29` | `eks.1` |
| `1.28` | `eks.6` |
Per ulteriori informazioni, consulta [Versioni della piattaforma ](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
# Creare voci di accesso
Prima di creare voci di accesso, considera quanto segue:
+ Una modalità di autenticazione impostata in modo corretto. Consultare [Cambia la modalità di autenticazione per utilizzare le voci di accesso](setting-up-access-entries.md).
+ Una *voce di accesso* include il nome della risorsa Amazon (ARN) di un principale (e solo di uno) IAM esistente. Un principale IAM non può essere incluso in più di una voce di accesso. Considerazioni aggiuntive per l'ARN specificato:
+ Le best practice IAM consigliano di accedere al cluster utilizzando *ruoli* IAM con credenziali a breve termine, anziché *utenti* IAM con credenziali a lungo termine. Per maggiori informazioni, consulta [Richiedere utenti umani per usare la federazione con un provider di identità per accedere a AWS utilizzando credenziali temporanee](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) nella *Guida per l’utente IAM*.
+ Se l'ARN è per un ruolo IAM, *può* includere un percorso. Gli ARN nelle voci `aws-auth` `ConfigMap`, *non possono* includere un percorso. Ad esempio, il tuo ARN può essere ` arn:aws:iam::<111122223333>:role/` o ` arn:aws:iam::<111122223333>:role/`.
+ Se il tipo di voce di accesso è diverso da `STANDARD` (vedi la prossima considerazione sui tipi), l’ARN deve trovarsi nello stesso account AWS in cui si trova il cluster. Se il tipo è `STANDARD`, l’ARN può essere nell’account AWS uguale o diverso dall’account in cui si trova il cluster.
+ Non è possibile modificare il principale IAM dopo aver creato la voce di accesso.
+ Se elimini il principale IAM con questo ARN, la voce di accesso non viene eliminata automaticamente. Ti consigliamo di eliminare la voce di accesso con un ARN per un principale IAM che elimini. Se non cancelli la voce di accesso e in futuro ricrei il principale IAM, anche se ha lo stesso ARN, la voce di accesso non funzionerà. Questo perché, anche se l’ARN è lo stesso per il principale IAM ricreato, il `roleID` o `userID` (puoi vederlo con il comando CLI `aws sts get-caller-identity` AWS) è diverso per il principale IAM ricreato rispetto al principale IAM originale. Anche se non visualizzi il `roleID` o il `userID` del principale IAM per una voce di accesso, Amazon EKS lo memorizza insieme alla voce di accesso.
+ Ogni voce di accesso ha un *tipo*. Il tipo di voce di accesso dipende dal tipo di risorsa a cui viene associata e non definisce le autorizzazioni. Se non specifichi un tipo, Amazon EKS lo imposta automaticamente su `STANDARD`
+ `EC2_LINUX`: per un ruolo IAM usato con nodi Linux o Bottlerocket autogestiti
+ `EC2_WINDOWS`: per un ruolo IAM usato con nodi autogestiti di Windows
+ `FARGATE_LINUX`: per un ruolo IAM usato con AWS Fargate (Fargate)
+ `HYBRID_LINUX`: per un ruolo IAM usato con nodi ibridi
+ `STANDARD`: tipo predefinito se non specificato
+ `EC2`: per le classi di nodi personalizzate EKS Auto Mode. Per ulteriori informazioni, consulta [Creazione di una voce di accesso alla classe di nodi](create-node-class.md#auto-node-access-entry).
+ Non è possibile modificare il tipo dopo aver creato la voce di accesso.
+ Non è necessario creare una voce di accesso per un ruolo IAM utilizzato per un gruppo di nodi gestiti o un profilo Fargate. EKS creerà voci di accesso (se abilitate) o aggiornerà la mappa di configurazione dell’autenticazione (se non sono disponibili le voci di accesso)
+ Se il tipo di voce di accesso è `STANDARD`, puoi specificare un *nome utente* per la voce di accesso. Se non specifichi un valore per il nome utente, Amazon EKS assegnerà automaticamente uno dei valori seguenti, in funzione del tipo di voce di accesso e del principale IAM da te indicato, che si tratti di un ruolo IAM o di un utente IAM. A meno che tu non abbia un motivo particolare per specificare il tuo nome utente, consigliamo di non specificarne uno e di lasciare che Amazon EKS lo generi automaticamente. Se decidi di specificare il tuo nome utente:
+ Tieni presente che non può iniziare con `system:`, `eks:`, `aws:`, `amazon:` o `iam:`.
+ Se il nome utente è per un ruolo IAM, ti consigliamo di aggiungere `{{SessionName}}` o `{{SessionNameRaw}}` alla fine del nome utente. Se aggiungi `{{SessionName}}` o `{{SessionNameRaw}}` al tuo nome utente, il nome utente deve includere i due punti *prima* di \$1\$1sessionName\$1\$1. Quando si assume questo ruolo, il nome della sessione AWS STS specificata al momento dell’assunzione del ruolo viene passato automaticamente al cluster e verrà visualizzato nei log di CloudTrail. Ad esempio, non puoi avere un nome utente del tipo `john{{SessionName}}`. Il nome utente deve essere `:john{{SessionName}}` o `jo:hn{{SessionName}}`. Solo i due punti devono essere prima di `{{SessionName}}`. Il nome utente generato da Amazon EKS nella tabella seguente include un ARN. Poiché un ARN include i due punti, soddisfa questo requisito. I due punti non sono obbligatori se non includi `{{SessionName}}` nel nome utente. Nota che in `{{SessionName}}` il carattere speciale “@” viene sostituito con “-” nel nome della sessione. `{{SessionNameRaw}}` mantiene tutti i caratteri speciali nel nome della sessione.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/creating-access-entries.html)
Puoi modificare il nome utente dopo aver creato la voce di accesso.
+ Se il tipo di una voce di accesso è `STANDARD` e desideri utilizzare l’autorizzazione RBAC di Kubernetes, puoi aggiungere uno o più *nomi dei gruppi* alla voce di accesso. Dopo aver creato una voce di accesso, puoi aggiungere e rimuovere i nomi dei gruppi. Affinché il principale IAM abbia accesso agli oggetti Kubernetes sul cluster, è necessario creare e gestire oggetti di autorizzazione basati sui ruoli (RBAC) Kubernetes. Creare oggetti Kubernetes `RoleBinding` o `ClusterRoleBinding` nel cluster che specificano il nome del gruppo come `subject` per `kind: Group`. Kubernetes autorizza l’accesso del principale IAM a qualsiasi oggetto del cluster specificato in un oggetto `Role` Kubernetes o `ClusterRole` specificato anche nel `roleRef` delle tue associazioni. Se specifichi nomi di gruppo, ti consigliamo di acquisire familiarità con gli oggetti di autorizzazione basata sui ruoli (RBAC) di Kubernetes. Per ulteriori informazioni, consulta [Utilizzo dell'autorizzazione RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) nella documentazione di Kubernetes.
**Importante**
Amazon EKS non conferma che gli oggetti RBAC Kubernetes presenti nel cluster includano uno dei nomi di gruppo specificati. Ad esempio, se si crea una voce di accesso per un gruppo che attualmente non esiste, EKS creerà il gruppo invece di restituire un errore.
Puoi collegare *policy di accesso* Amazon EKS a una voce di accesso, come alternativa o complemento all’autorizzazione concessa da Kubernetes al principale IAM per accedere agli oggetti Kubernetes sul tuo cluster. Amazon EKS autorizza i principali IAM ad accedere agli oggetti Kubernetes sul tuo cluster con le autorizzazioni previste dalla policy di accesso. Puoi definire l’ambito delle autorizzazioni di una policy di accesso ai namespace di Kubernetes che specifichi. L’uso delle policy di accesso non richiede la gestione degli oggetti RBAC di Kubernetes. Per ulteriori informazioni, consulta [Associare le policy di accesso alle voci di accesso](access-policies.md).
+ Se crei una voce di accesso con tipo `EC2_LINUX` o `EC2_Windows`, il principale IAM che crea la voce di accesso deve disporre dell'autorizzazione `iam:PassRole`. Per ulteriori informazioni, consulta [Concessione di autorizzazioni utente per il passaggio di un ruolo a un servizio AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) nella *Guida per l'utente di IAM*.
+ Analogamente al [comportamento di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency) standard, la creazione e gli aggiornamenti delle voci di accesso alla fine sono coerenti e potrebbero essere necessari alcuni secondi prima che la chiamata API iniziale risulti completata con successo. È necessario progettare le applicazioni in modo da tenere in considerazione questi potenziali ritardi Si consiglia di non includere creazioni o aggiornamenti degli accessi nei percorsi critici e ad alta disponibilità del codice dell’applicazione. Al contrario, apportare modifiche in un'inizializzazione separata o in una routine di configurazione che si esegue meno frequentemente. Inoltre, assicurarsi di verificare che le modifiche siano state propagate prima che i flussi di lavoro di produzione dipendano da esse.
+ Le voci di accesso non supportano [i ruoli collegati al servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html). Non puoi creare voci di accesso in cui l’ARN principale è un ruolo collegato al servizio. Puoi identificare i ruoli collegati al servizio in base al relativo ARN, che è nel formato ` arn:aws:iam::*:role/aws-service-role/*`.
È possibile creare una voce di accesso utilizzando la Console di gestione AWS o la AWS CLI.
## Console di gestione AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il nome del cluster in cui desideri creare una voce di accesso.
1. Scegli la scheda **Accesso**.
1. Seleziona **Crea voce di accesso**.
1. Per **Principale IAM**, seleziona un ruolo o un utente IAM esistente. Le best practice IAM consigliano di accedere al cluster utilizzando *ruoli* IAM con credenziali a breve termine, anziché *utenti* IAM con credenziali a lungo termine. Per maggiori informazioni, consulta [Richiedere utenti umani per usare la federazione con un provider di identità per accedere a AWS utilizzando credenziali temporanee](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) nella *Guida per l’utente IAM*.
1. Per **Tipo**, se la voce di accesso è per il ruolo del nodo utilizzato per i nodi Amazon EC2 autogestiti, seleziona **EC2 Linux** o **EC2 Windows**. Altrimenti, accetta l'impostazione predefinita (**Standard**).
1. Se il **Tipo** che hai scelto è **Standard** e desideri specificare un **Nome utente**, inserisci il nome utente.
1. Se il **Tipo** che hai scelto è **Standard** e desideri utilizzare l’autorizzazione RBAC di Kubernetes per il principale IAM, specifica uno o più nomi per i **Gruppi**. Se non specifichi nomi dei gruppi e desideri utilizzare l’autorizzazione Amazon EKS, puoi associare una policy di accesso in un passaggio successivo o dopo la creazione della voce di accesso.
1. (Facoltativo) Per **Tag**, assegna etichette alla voce di accesso. Ad esempio, per facilitare la ricerca di tutte le risorse con lo stesso tag.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Aggiungi policy di accesso**, se il tipo che hai scelto era **Standard** e desideri che Amazon EKS autorizzi il principale IAM a disporre delle autorizzazioni per gli oggetti Kubernetes sul tuo cluster, completa i seguenti passaggi. Altrimenti, scegli **Next** (Successivo).
1. Per **Nome della policy**, scegli una policy di accesso. Non puoi visualizzare le autorizzazioni delle policy di accesso, tuttavia includono autorizzazioni simili a quelle degli oggetti `ClusterRole` di Kubernetes rivolti all’utente. Per ulteriori informazioni, consulta [User-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) nella documentazione di Kubernetes.
1. Selezionare una delle seguenti opzioni:
+ **Cluster**: scegli questa opzione se desideri che Amazon EKS autorizzi il principale IAM a disporre delle autorizzazioni nella policy di accesso per tutti gli oggetti Kubernetes sul tuo cluster.
+ **Namespace Kubernetes**: scegli questa opzione se desideri che Amazon EKS autorizzi il principale IAM a disporre delle autorizzazioni nella policy di accesso per tutti gli oggetti Kubernetes in uno specifico namespace Kubernetes sul tuo cluster. Per **Namespace**, inserisci il nome del namespace Kubernetes sul tuo cluster. Se desideri aggiungere altri spazi dei nomi, scegli **Aggiungi nuovo spazio dei nomi** e inserisci il nome dello spazio dei nomi.
1. Se desideri aggiungere ulteriori policy, scegli **Aggiungi policy**. Puoi definire l'ambito di ciascuna policy in modo diverso, ma puoi aggiungere ogni policy solo una volta.
1. Scegli **Next (Successivo)**.
1. Verifica la configurazione per la tua voce di accesso. Se noti qualcosa di errato, scegli **Precedente** per tornare indietro e correggere l'errore. Se la configurazione è corretta, scegli **Crea**.
## CLI AWS
1. Installare e configurare AWS CLI come descritto nella pagina [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) della Guida per l’utente dell’Interfaccia della linea di comando AWS.
1. Per creare una voce di accesso Per creare voci di accesso è possibile utilizzare uno qualsiasi degli esempi seguenti:
+ Crea una voce di accesso per un gruppo di nodi Amazon EC2 Linux autogestito. [Sostituisci *my-cluster* con il nome del cluster, *111122223333* con l’ID del tuo account AWS e *EKS-my-cluster-self-managed-ng-1* con il nome del ruolo IAM del nodo](create-node-role.md). Nel caso in cui il tuo gruppo di nodi operi su Windows, sostituisci *EC2\$1LINUX* con `EC2_Windows`.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX
```
Non puoi utilizzare l’opzione `--kubernetes-groups` quando specifichi un tipo diverso da `STANDARD`. Non puoi associare una policy di accesso a questa voce di accesso, perché il suo tipo è un valore diverso da `STANDARD`.
+ Crea una voce di accesso che permetta a un ruolo IAM, non utilizzato per un gruppo di nodi autogestiti di Amazon EC2, di essere autorizzato da Kubernetes per accedere al tuo cluster. Sostituisci *my-cluster* con il nome del cluster, *111122223333* con l’ID del tuo account AWS e *my-role-name* con il nome del tuo ruolo IAM. Sostituisci *Visualizzatori* con il nome di un gruppo che hai specificato in un oggetto Kubernetes `RoleBinding` o `ClusterRoleBinding` sul tuo cluster.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
```
+ Crea una voce di accesso che consenta a un utente IAM di autenticarsi nel tuo cluster. Questo esempio viene fornito perché è possibile, anche se le best practice IAM consigliano di accedere al cluster utilizzando *ruoli* IAM con credenziali a breve termine, anziché *utenti* IAM con credenziali a lungo termine. Per maggiori informazioni, consulta [Richiedere utenti umani per usare la federazione con un provider di identità per accedere a AWS utilizzando credenziali temporanee](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) nella *Guida per l’utente IAM*.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user
```
Se desideri che questo utente abbia un accesso al tuo cluster maggiore rispetto alle autorizzazioni nei ruoli di rilevamento delle API Kubernetes, è necessario associare una policy di accesso alla voce di accesso, poiché l’opzione `--kubernetes-groups` non viene utilizzata. Per ulteriori informazioni, consulta [Associare le policy di accesso alle voci di accesso](access-policies.md) e [API discovery roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles) nella documentazione di Kubernetes.
# Aggiornamento delle voci di accesso
È possibile aggiornare una voce di accesso utilizzando Console di gestione AWS o AWS CLI.
## Console di gestione AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il nome del cluster in cui desideri creare una voce di accesso.
1. Scegli la scheda **Accesso**.
1. Scegli la voce di accesso che desideri aggiornare.
1. Scegli **Modifica**.
1. Per **Nome utente**, puoi modificare il valore esistente.
1. Per **Gruppi**, puoi rimuovere i nomi dei gruppi esistenti o aggiungere nuovi nomi dei gruppi. Se esistono i seguenti nomi di gruppi, non rimuoverli: **system:nodes** o **system:bootstrappers**. La rimozione di questi gruppi può causare un malfunzionamento del cluster. Se non specifichi nomi dei gruppi e desideri utilizzare l’autorizzazione Amazon EKS, associa una [policy di accesso](access-policies.md) in un passaggio successivo.
1. Per **Tag**, puoi assegnare etichette alla voce di accesso. Ad esempio, per facilitare la ricerca di tutte le risorse con lo stesso tag. Puoi anche rimuovere i tag esistenti.
1. Scegli **Save changes** (Salva modifiche).
1. Se desideri associare una policy di accesso alla voce, consulta la sezione [Associare le policy di accesso alle voci di accesso](access-policies.md).
## CLI AWS
1. Installa AWS CLI come descritto in [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) nella Guida per l’utente dell’interfaccia a riga di comando AWS.
1. Per aggiornare una voce di accesso, sostituisci *my-cluster* con il nome del cluster, *111122223333* con l’ID del tuo account AWS e *EKS-my-cluster-my-namespace-Viewers* con il nome di un ruolo IAM.
```
aws eks update-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --kubernetes-groups Viewers
```
Non è possibile utilizzare l’opzione `--kubernetes-groups` se il tipo di voce di accesso è un valore diverso da `STANDARD`. Inoltre, non è possibile associare una policy di accesso a una voce di accesso con un tipo diverso da `STANDARD`.
# Eliminare le voci di accesso
Se scopri di aver eliminato una voce di accesso per errore, puoi sempre ricrearla. Se la voce di accesso da eliminare è associata a policy di accesso, le associazioni vengono eliminate automaticamente. Non è necessario dissociare le policy di accesso da una voce di accesso prima di eliminarla.
È possibile eliminare una voce di accesso utilizzando la Console di gestione AWS o AWS CLI.
## Console di gestione AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il nome del cluster da cui desideri eliminare una voce di accesso.
1. Scegli la scheda **Accesso**.
1. Nell'elenco **Voci di accesso**, seleziona la voce di accesso da eliminare.
1. Scegliere Delete (Elimina).
1. Nella finestra di dialogo di conferma, seleziona **Elimina**.
## CLI AWS
1. Installare AWS CLI come descritto nella pagina [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) della Guida per l’utente dell’Interfaccia della linea di comando AWS.
1. Per eliminare una voce di accesso, sostituire *my-cluster* con il nome del cluster, *111122223333* con l’ID dell’account AWS e *my-role* con il nome del ruolo IAM a cui si desidera revocare l’accesso al cluster.
```
aws eks delete-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
# Impostazione di un nome utente personalizzato per le voci di accesso EKS
Quando crei voci di accesso per Amazon EKS, è possibile utilizzare il nome utente generato automaticamente o specificare un nome utente personalizzato. Questa pagina spiega entrambe le opzioni e ti guida nell’impostazione di un nome utente personalizzato.
## Panoramica di
Il nome utente in una voce di accesso è utilizzato per identificare il principale IAM nei log e negli audit trail di Kubernetes. Per impostazione predefinita, Amazon EKS genera un nome utente basato sull’ARN dell’identità IAM, ma è possibile specificare un nome utente personalizzato se necessario.
## Generazione di un nome utente predefinito
Se non specifichi un valore per il nome utente, Amazon EKS genera automaticamente un nome utente basato sull’identità IAM:
+ **Per un utente IAM:**
+ EKS imposta il nome utente Kubernetes sull’ARN dell’utente IAM
+ Esempio:
```
{arn-aws}iam::<111122223333>:user/
```
+ **Per ruoli IAM**:
+ EKS imposta il nome utente Kubernetes in base all’ARN del ruolo IAM
+ L’ARN STS del ruolo quando è assunto. Amazon EKS aggiunge `{{SessionName}}` al ruolo. Se l'ARN del ruolo che hai specificato conteneva un percorso, Amazon EKS lo rimuove nel nome utente generato.
+ Esempio:
```
{arn-aws}sts::<111122223333>:assumed-role//{{SessionName}}
```
A meno che tu non abbia un motivo particolare per specificare il tuo nome utente, consigliamo di non specificarne uno e di lasciare che Amazon EKS lo generi automaticamente.
## Impostare un nome utente personalizzato
Quando si crea una voce di accesso, è possibile specificare un nome utente personalizzato utilizzando il parametro `--username`:
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --username
```
### Requisiti per nomi utente personalizzati
Se decidi specificare un nome utente personalizzato:
+ Il nome utente non può iniziare con `system:`, `eks:`, `aws:`, `amazon:` o `iam:`.
+ Se il nome utente è per un ruolo IAM, ti consigliamo di aggiungere `{{SessionName}}` o `{{SessionNameRaw}}` alla fine del nome utente.
+ Se aggiungi uno dei due `{{SessionName}}` o `{{SessionNameRaw}}` al tuo nome utente, il nome utente deve includere i due punti *prima di* \$1\$1SessionName\$1\$1.
# Crea una voce di accesso per un utente o un ruolo IAM usando una policy di accesso e la AWS CLI
Crea voci di accesso Amazon EKS che usano le policy di accesso EKS gestite da AWS per dare alle identità IAM autorizzazioni standardizzate per accedere e gestire i cluster Kubernetes.
## Panoramica
Le voci di accesso in Amazon EKS definiscono il modo in cui le identità IAM (utenti e ruoli) possono accedere ai cluster Kubernetes e interagire con essi. Creando voci di accesso con le policy di accesso EKS, puoi:
+ Concedere a utenti o a ruoli IAM specifici l’autorizzazione ad accedere al tuo cluster EKS
+ Controllare le autorizzazioni usando policy di accesso EKS gestite da AWS che forniscono set di autorizzazioni standardizzati e predefiniti
+ Limitare le autorizzazioni a namespace specifici o a tutto il cluster
+ Semplificare la gestione degli accessi senza modificare il ConfigMap `aws-auth` o creare risorse Kubernetes RBAC
+ Usare l’approccio integrato con AWS al controllo degli accessi Kubernetes che copre i casi d’uso più comuni, mantenendo al contempo le migliori pratiche di sicurezza.
Questo approccio è consigliato per la maggior parte dei casi d’uso perché fornisce autorizzazioni standardizzate gestite da AWS senza richiedere la configurazione manuale di Kubernetes RBAC. Le policy di accesso EKS eliminano la necessità di configurare manualmente le risorse Kubernetes RBAC e forniscono set di autorizzazioni predefiniti che coprono casi d’uso comuni.
## Prerequisiti
+ La *modalità di autenticazione* del cluster deve essere configurata per abilitare le *voci di accesso*. Per ulteriori informazioni, consulta [Cambia la modalità di autenticazione per utilizzare le voci di accesso](setting-up-access-entries.md).
+ Installare e configurare AWS CLI come descritto nella pagina [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) della Guida per l’utente dell’Interfaccia della linea di comando AWS.
## Fase 1: definire la voce di accesso
1. Trovare l’ARN dell’identità IAM, come un utente o un ruolo, a cui concedere le autorizzazioni.
+ Ogni identità IAM può disporre di una sola voce di accesso EKS.
1. Stabilisci se vuoi che le autorizzazioni della policy di accesso Amazon EKS si applichino solo a uno specifico namespace Kubernetes o all’intero cluster.
+ Se vuoi limitare le autorizzazioni a un namespace specifico, prendi nota del nome del namespace.
1. Seleziona la policy di accesso EKS che desideri per l’identità IAM. Questa policy fornisce le autorizzazioni all’interno del cluster. Annota l’ARN della policy.
+ Per un elenco delle policy, consulta le [policy di accesso disponibili](access-policy-permissions.md).
1. Stabilire se il nome utente generato automaticamente è adeguato per la voce di accesso o se è necessario specificarne uno manualmente.
+ AWS genera questo valore automaticamente in base all’identità IAM. È possibile impostare un nome utente personalizzato. Tale nome è visibile nei log di Kubernetes.
+ Per ulteriori informazioni, consulta [Impostazione di un nome utente personalizzato per le voci di accesso EKS](set-custom-username.md).
## Fase 2: creare una voce di accesso
Dopo aver pianificato la voce di accesso, usa la AWS CLI per crearla.
L’esempio seguente copre la maggior parte dei casi d’uso. [Visualizzare il riferimento CLI per tutte le opzioni di configurazione](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
Nella fase successiva allegherai la policy di accesso.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD
```
## Fase 3: associare la policy di accesso
Il comando varia a seconda che si voglia limitare la policy a un namespace Kubernetes specificato.
È necessario l’ARN della policy di accesso. Visualizza le [policy di accesso disponibili](access-policy-permissions.md).
### Crea una policy senza l’ambito del namespace
```
aws eks associate-access-policy --cluster-name --principal-arn --policy-arn
```
### Crea con l’ambito del namespace
```
aws eks associate-access-policy --cluster-name --principal-arn \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn
```
## Passaggi successivi
+ [Crea un kubeconfig in modo da poter utilizzare kubectl con un’identità IAM](create-kubeconfig.md)
# Creare una voce di accesso utilizzando i gruppi Kubernetes con AWS CLI
Creare voci di accesso Amazon EKS che utilizzano gruppi Kubernetes per l’autorizzazione e richiedono una configurazione di controllo degli accessi basato sul ruolo (RBAC) manuale.
**Nota**
Per la maggior parte dei casi d’uso, consigliamo di utilizzare le policy di accesso EKS anziché l’approccio con gruppi Kubernetes descritto in questa pagina. Le policy di accesso EKS offrono un modo più semplice e integrato con AWS per gestire l’accesso senza richiedere la configurazione RBAC manuale. Utilizzare l’approccio con gruppi Kubernetes solo quando è necessario un controllo più granulare di quello offerto dalle policy di accesso EKS.
## Panoramica
Le voci di accesso definiscono il modo in cui le identità IAM (utenti e ruoli) accedono ai cluster Kubernetes. L’approccio con gruppi Kubernetes concede agli utenti o ai ruoli IAM l’autorizzazione ad accedere al cluster EKS tramite gruppi Kubernetes RBAC standard. Questo metodo richiede la creazione e la gestione di risorse Kubernetes RBAC (Roles, RoleBindings, ClusterRoles e ClusterRoleBindings) ed è consigliato quando sono necessari set di autorizzazioni altamente personalizzati, requisiti di autorizzazione complessi o quando si desidera mantenere modelli di controllo degli accessi coerenti in ambienti Kubernetes ibridi.
Questo argomento non tratta la creazione di voci di accesso per le identità IAM utilizzate dalle istanze Amazon EC2 per unirsi ai cluster EKS.
## Prerequisiti
+ La *modalità di autenticazione* del cluster deve essere configurata per abilitare le *voci di accesso*. Per ulteriori informazioni, consulta [Cambia la modalità di autenticazione per utilizzare le voci di accesso](setting-up-access-entries.md).
+ Installare e configurare AWS CLI come descritto nella pagina [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) della Guida per l’utente dell’Interfaccia della linea di comando AWS.
+ Si consiglia di avere familiarità con il controllo RBAC Kubernetes. Per ulteriori informazioni, consulta [Utilizzo dell'autorizzazione RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) nella documentazione di Kubernetes.
## Fase 1: definire la voce di accesso
1. Trovare l’ARN dell’identità IAM, come un utente o un ruolo, a cui concedere le autorizzazioni.
+ Ogni identità IAM può disporre di una sola voce di accesso EKS.
1. Determinare quali gruppi Kubernetes devono essere associati a tale identità IAM.
+ Sarà necessario creare o utilizzare le risorse Kubernetes `Role`/`ClusterRole` e `RoleBinding`/`ClusterRoleBinding` esistenti che fanno riferimento a tali gruppi.
1. Stabilire se il nome utente generato automaticamente è adeguato per la voce di accesso o se è necessario specificarne uno manualmente.
+ AWS genera questo valore automaticamente in base all’identità IAM. È possibile impostare un nome utente personalizzato. Tale nome è visibile nei log di Kubernetes.
+ Per ulteriori informazioni, consulta [Impostazione di un nome utente personalizzato per le voci di accesso EKS](set-custom-username.md).
## Fase 2: creare una voce di accesso con i gruppi Kubernetes
Dopo aver definito la voce di accesso, utilizzare AWS CLI per crearla con i gruppi Kubernetes adeguati.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --kubernetes-groups
```
Sostituire:
+ `` con il nome del cluster EKS.
+ `` con l’ARN del ruolo o dell’utente IAM.
+ `` con un elenco separato da virgole di gruppi Kubernetes (ad esempio, “system:developers,system:readers”).
[Visualizzare il riferimento CLI per tutte le opzioni di configurazione](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
## Fase 3: configurazione del controllo RBAC Kubernetes
Affinché il principale IAM abbia accesso agli oggetti Kubernetes nel cluster, è necessario creare e gestire oggetti del controllo degli accessi basato sul ruolo (RBAC) Kubernetes:
1. Creare oggetti Kubernetes `Role` o `ClusterRole` che definiscono le autorizzazioni.
1. Creare oggetti Kubernetes `RoleBinding` o `ClusterRoleBinding` nel cluster che specificano il nome del gruppo come `subject` per `kind: Group`.
Per informazioni dettagliate sulla configurazione di gruppi e autorizzazioni in Kubernetes, consultare [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) nella documentazione di Kubernetes.
## Passaggi successivi
+ [Create a kubeconfig so you can use kubectl with an IAM identity](create-kubeconfig.md)
# Concedi agli utenti IAM l'accesso a Kubernetes con un ConfigMap
**Importante**
La funzionalità `aws-auth ConfigMap` è obsoleta. Per il metodo consigliato per gestire l'accesso a Kubernetes, consulta. APIs [Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS](access-entries.md)
L’accesso al cluster utilizzando i [principali IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) è abilitato dall’[autenticatore AWS IAM per Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme), che viene eseguito sul piano di controllo di Amazon EKS. L’autenticatore riceve le informazioni di configurazione da `aws-auth` `ConfigMap`. Per tutte le impostazioni di `ConfigMap` `aws-auth`, consulta [Formato di configurazione completo](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format) su GitHub.
## Aggiunta di principali IAM al cluster Amazon EKS
Quando crei un cluster Amazon EKS, il [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) che crea il cluster riceve automaticamente le autorizzazioni `system:masters` nella configurazione del controllo degli accessi basato sul ruolo (RBAC) nel piano di controllo di Amazon EKS. Questo principale non è visualizzato in una configurazione visibile qualsiasi, quindi assicurati di tenere traccia di quale principale ha originariamente creato il cluster. Per concedere a ulteriori principali IAM la capacità di interagire con il cluster, modifica `aws-auth ConfigMap` all’interno di Kubernetes e crea `rolebinding` o `clusterrolebinding` Kubernetes con il nome di `group` specificato in `aws-auth ConfigMap`.
**Nota**
Per ulteriori informazioni sulla configurazione del controllo degli accessi basato sul ruolo (RBAC) di Kubernetes, consultare [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) nella documentazione di Kubernetes.
1. Determina quali credenziali `kubectl` vengono utilizzate per accedere al cluster. Sul computer, è possibile vedere quali credenziali `kubectl` utilizza con il seguente comando. Sostituiscilo *\$1/.kube/config* con il percorso `kubeconfig` del file se non utilizzi il percorso predefinito.
```
cat ~/.kube/config
```
Di seguito viene riportato un output di esempio.
```
[...]
contexts:
- context:
cluster: my-cluster.region-code.eksctl.io
user: admin@my-cluster.region-code.eksctl.io
name: admin@my-cluster.region-code.eksctl.io
current-context: admin@my-cluster.region-code.eksctl.io
[...]
```
Nell'output dell'esempio precedente, le credenziali per un utente denominato *admin* sono configurate per un cluster denominato *my-cluster*. Se si tratta dell’utente che ha creato il cluster, ha già accesso al cluster. Se l’utente non ha creato il cluster, devi completare i passaggi rimanenti per abilitare l’accesso al cluster per gli altri principali IAM. [Le best practice IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) consigliano di concedere le autorizzazioni ai ruoli anziché agli utenti. Per visualizzare gli altri principali che hanno attualmente accesso al cluster, esegui il comando seguente:
```
kubectl describe -n kube-system configmap/aws-auth
```
Di seguito viene riportato un output di esempio.
```
Name: aws-auth
Namespace: kube-system
Labels:
Annotations:
Data
====
mapRoles:
----
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws: iam::111122223333:role/my-node-role
username: system:node:{{EC2PrivateDNSName}}
BinaryData
====
Events:
```
L’esempio precedente è una `aws-auth` `ConfigMap` predefinita. Solo il ruolo dell’istanza del nodo ha accesso al cluster.
1. Assicurati di disporre di `roles` e `rolebindings` o `clusterroles` e `clusterrolebindings` di Kubernetes da mappare ai principali IAM. Per ulteriori informazioni su queste risorse, consulta [Utilizzo dell’autorizzazione RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) nella documentazione di Kubernetes.
1. Visualizza i `roles` o `clusterroles` Kubernetes esistenti. L’ambito di `Roles` è `namespace`, mentre l’ambito di `clusterroles` è il cluster.
```
kubectl get roles -A
```
```
kubectl get clusterroles
```
1. Visualizza i dettagli dei valori `role` o `clusterrole` restituiti nell’output precedente e verifica di disporre delle autorizzazioni (`rules`) da concedere ai principali IAM del cluster.
Sostituisci *role-name* con un nome del `role` restituito nell'output del comando precedente. Sostituisci *kube-system* con lo spazio dei nomi del `role`.
```
kubectl describe role role-name -n kube-system
```
Sostituisci *cluster-role-name* con un nome del `clusterrole` restituito nell'output del comando precedente.
```
kubectl describe clusterrole cluster-role-name
```
1. Visualizza i `rolebindings` o `clusterrolebindings` Kubernetes esistenti. L’ambito di `Rolebindings` è `namespace`, mentre l’ambito di `clusterrolebindings` è il cluster.
```
kubectl get rolebindings -A
```
```
kubectl get clusterrolebindings
```
1. Visualizza i dettagli di `rolebinding` o `clusterrolebinding` e verifica che dispongano di un `role` or `clusterrole` della fase precedente elencato come un `roleRef` e un nome di gruppo elencato per `subjects`.
Sostituisci *role-binding-name* con un nome del `rolebinding` restituito nell'output del comando precedente. Sostituisci *kube-system* con lo `namespace` del `rolebinding`.
```
kubectl describe rolebinding role-binding-name -n kube-system
```
Di seguito viene riportato un output di esempio.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-console-dashboard-restricted-access-role-binding
namespace: default
subjects:
- kind: Group
name: eks-console-dashboard-restricted-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: eks-console-dashboard-restricted-access-role
apiGroup: rbac.authorization.k8s.io
```
Sostituisci *cluster-role-binding-name* con un nome del `clusterrolebinding` restituito nell'output del comando precedente.
```
kubectl describe clusterrolebinding cluster-role-binding-name
```
Di seguito viene riportato un output di esempio.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
name: eks-console-dashboard-full-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: eks-console-dashboard-full-access-clusterrole
apiGroup: rbac.authorization.k8s.io
```
1. Modificare `aws-auth` `ConfigMap`. Per aggiornare `ConfigMap` puoi usare uno strumento adeguato, ad esempio `eksctl`, oppure puoi eseguire l’aggiornamento in modo manuale tramite modifica.
**Importante**
Ti consigliamo di utilizzare `eksctl`, o uno strumento simile, per modificare `ConfigMap`. Per informazioni su altri strumenti che puoi utilizzare, consulta [Utilizzare gli strumenti per apportare modifiche a aws- authConfigMap](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#use-tools-to-make-changes-to-the-aws-auth-configmap) nelle guide alle best practice di Amazon EKS. Una formattazione impropria di `aws-auth` `ConfigMap` può causare la perdita dell’accesso al cluster.
+ Visualizzare le fasi per [modificare configmap con eksctl](#configmap-eksctl).
+ Visualizzare le fasi per [modificare configmap manualmente](#configmap-manual).
### Modificare Configmap con Eksctl
1. È necessaria la versione `0.215.0` o una versione successiva dello strumento da riga di `eksctl` comando installata sul dispositivo o AWS CloudShell. Per l’installazione o l’aggiornamento di `eksctl`, consulta la sezione [Installation](https://eksctl.io/installation) nella documentazione di `eksctl`.
1. Visualizza le mappature correnti in `ConfigMap`. Sostituisci *my-cluster* con il nome del cluster. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
Di seguito viene riportato un output di esempio.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. Aggiungi una mappatura per un ruolo. Sostituisci *my-role* con il nome del tuo ruolo. Sostituisci *eks-console-dashboard-full-access-group* con il nome del gruppo specificato nel tuo Kubernetes `RoleBinding` o nell'oggetto. `ClusterRoleBinding` Sostituisci *111122223333* con l'ID del tuo account. Puoi sostituire *admin* con un nome a tua scelta.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws: iam::111122223333:role/my-role --username admin --group eks-console-dashboard-full-access-group \
--no-duplicate-arns
```
**Importante**
L’ARN del ruolo non può includere un percorso, ad esempio `role/my-team/developers/my-role`. Il formato dell’ARN deve essere ` arn:aws: iam::111122223333:role/my-role `. In questo esempio, `my-team/developers/` deve essere rimosso.
Di seguito viene riportato un output di esempio.
```
[...]
2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap
```
1. Aggiungi una mappatura per un utente. [Le best practice IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) consigliano di concedere le autorizzazioni ai ruoli anziché agli utenti. Sostituisci *my-user* con il tuo nome utente. Sostituisci *eks-console-dashboard-restricted-access-group* con il nome del gruppo specificato nel tuo `RoleBinding` Kubernetes o nell'oggetto. `ClusterRoleBinding` Sostituisci *111122223333* con l'ID del tuo account. Puoi sostituire *my-user* con un nome a tua scelta.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws: iam::111122223333:user/my-user --username my-user --group eks-console-dashboard-restricted-access-group \
--no-duplicate-arns
```
Di seguito viene riportato un output di esempio.
```
[...]
2022-05-09 14:53:48 [ℹ] adding identity "arn:aws: iam::111122223333:user/my-user" to auth ConfigMap
```
1. Visualizza nuovamente le mappature nella `ConfigMap`.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
Di seguito viene riportato un output di esempio.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws: iam::111122223333:role/admin my-role eks-console-dashboard-full-access-group
arn:aws: iam::111122223333:user/my-user my-user eks-console-dashboard-restricted-access-group
```
### Modificare Configmap manualmente
1. Apri `ConfigMap` per la modifica.
```
kubectl edit -n kube-system configmap/aws-auth
```
**Nota**
Se ricevi un errore che indica "`Error from server (NotFound): configmaps "aws-auth" not found`«, utilizza la procedura in [Applica l'aws-auth al tuo cluster ConfigMap per applicare lo](#aws-auth-configmap) stock. `ConfigMap`
1. Aggiungi i tuoi principali IAM alla `ConfigMap`. Un gruppo IAM non è un principale IAM, quindi non può essere aggiunto alla `ConfigMap`.
+ **Per aggiungere un ruolo IAM (ad esempio, per [utenti federati](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)):** aggiungere i dettagli del ruolo alla sezione `mapRoles` della `ConfigMap`, in `data`. Aggiungi questa sezione se non esiste già nel file. Ogni voce supporta i seguenti parametri:
+ **rolearn**: l’ARN; del ruolo IAM da aggiungere. Questo valore non può includere un percorso. Ad esempio, non puoi specificare un ARN, come ` arn:aws: iam::111122223333:role/my-team/developers/role-name `. L’ARN deve essere ` arn:aws: iam::111122223333:role/role-name `.
+ **username**: il nome utente all’interno di Kubernetes da associare al ruolo IAM.
+ **groups**: il gruppo o l’elenco dei gruppi Kubernetes a cui mappare il ruolo. Tale gruppo può essere un gruppo predefinito o un gruppo specificato in un `clusterrolebinding` o un `rolebinding`. Per ulteriori informazioni consultare [Default roles and role bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) nella documentazione di Kubernetes.
+ **Per aggiungere un utente IAM:** [le best practice IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) consigliano di concedere le autorizzazioni ai ruoli anziché agli utenti. Aggiungi i dettagli dell’utente alla sezione `mapUsers` della `ConfigMap`, in `data`. Aggiungi questa sezione se non esiste già nel file. Ogni voce supporta i seguenti parametri:
+ **userarn**: L’ARN; dell’utente IAM da aggiungere.
+ **username**: Il nome utente all’interno di Kubernetes da associare all’utente IAM.
+ **groups**: il gruppo o l’elenco dei gruppi Kubernetes a cui mappare l’utente. Tale gruppo può essere un gruppo predefinito o un gruppo specificato in un `clusterrolebinding` o un `rolebinding`. Per ulteriori informazioni consultare [Default roles and role bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) nella documentazione di Kubernetes.
1. Ad esempio, il blocco YAML seguente contiene:
+ Una sezione `mapRoles` che mappa l’istanza del nodo IAM ai gruppi Kubernetes, in modo che i nodi possano registrarsi autonomamente con il cluster e il ruolo IAM `my-console-viewer-role` mappato a un gruppo Kubernetes in grado di visualizzare tutte le risorse Kubernetes per tutti i cluster. Per un elenco delle autorizzazioni del gruppo IAM e Kubernetes necessarie per il ruolo IAM `my-console-viewer-role`, consulta [Autorizzazioni richieste](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ Una `mapUsers` sezione che mappa l'utente `admin` IAM dall' AWS account predefinito al gruppo `system:masters` Kubernetes e l'`my-user`utente di un AWS account diverso mappato a un gruppo Kubernetes in grado di visualizzare le risorse Kubernetes per uno spazio dei nomi specifico. Per un elenco delle autorizzazioni del gruppo IAM e Kubernetes necessarie per l’utente IAM `my-user`, consulta [Autorizzazioni richieste](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
Aggiungi o rimuovi righe in base alle esigenze e sostituisci tutti i valori di esempio con quelli desiderati.
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws: iam::111122223333:role/my-role
username: system:node:{{EC2PrivateDNSName}}
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws: iam::111122223333:role/my-console-viewer-role
username: my-console-viewer-role
mapUsers: |
- groups:
- system:masters
userarn: arn:aws: iam::111122223333:user/admin
username: admin
- groups:
- eks-console-dashboard-restricted-access-group
userarn: arn:aws: iam::444455556666:user/my-user
username: my-user
```
1. Salva il file ed esci dall’editor di testo.
## Applica la `aws-auth` `ConfigMap` al cluster
La `aws-auth` `ConfigMap` viene creata e applicata automaticamente al cluster quando si crea un gruppo di nodi gestito o quando si crea un gruppo di nodi utilizzando `eksctl`. È inizialmente creata per consentire ai nodi di unirsi al cluster, ma questa `ConfigMap` può essere usata anche per aggiungere l’accesso RBAC (controllo degli accessi basato sul ruolo) a principali IAM. Se non hai avviato nodi autogestiti e non hai applicato la `aws-auth` `ConfigMap` al cluster, puoi farlo utilizzando la procedura seguente.
1. Controlla per vedere se è già stata applicata la `aws-auth` `ConfigMap`.
```
kubectl describe configmap -n kube-system aws-auth
```
Se ricevi un errore di tipo "`Error from server (NotFound): configmaps "aws-auth" not found`", procedi con le fasi seguenti per applicare lo stock `ConfigMap`.
1. Scarica, modifica e applica la mappa di configurazione dell'autenticatore. AWS
1. Scarica la mappa di configurazione.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. Nel file `aws-auth-cm.yaml`, imposta il `rolearn` sul nome della risorsa Amazon (ARN) del ruolo IAM associato ai nodi. Per eseguire questa operazione, utilizza un editor di testo o sostituisci *my-node-instance-role* eseguendo il comando seguente:
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
Non modificare altre righe in questo file.
**Importante**
L’ARN del ruolo non può includere un percorso, ad esempio `role/my-team/developers/my-role`. Il formato dell’ARN deve essere ` arn:aws: iam::111122223333:role/my-role `. In questo esempio, `my-team/developers/` deve essere rimosso.
Puoi ispezionare gli output dello AWS CloudFormation stack per i tuoi gruppi di nodi e cercare i seguenti valori:
+ **InstanceRoleARN** — Per i gruppi di nodi creati con `eksctl`
+ **NodeInstanceRole**— Per i gruppi di nodi creati con i AWS CloudFormation modelli forniti da Amazon EKS nel Console di gestione AWS
1. Applica la configurazione. L’esecuzione di questo comando potrebbe richiedere alcuni minuti.
```
kubectl apply -f aws-auth-cm.yaml
```
**Nota**
Se ricevi qualsiasi altro errore di tipo di risorsa o autorizzazione, consulta la sezione [Accesso negato o non autorizzato (`kubectl`)](troubleshooting.md#unauthorized) nell’argomento relativo alla risoluzione dei problemi.
1. Guarda lo stato dei nodi e attendi che raggiungano lo stato `Ready`.
```
kubectl get nodes --watch
```
Inserisci `Ctrl`\$1`C` per tornare a un prompt della shell.
# Concedere agli utenti l’accesso a Kubernetes con un provider OIDC esterno
Amazon EKS supporta l’utilizzo di provider di identità OpenID Connect (OIDC) come metodo per autenticare gli utenti nel cluster. I provider di identità OIDC possono essere utilizzati con o in alternativa a AWS Identity and Access Management (IAM). Per ulteriori informazioni sull’utilizzo di IAM, consultare [Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs](grant-k8s-access.md). Dopo aver configurato l’autenticazione per il cluster, è possibile creare `roles` e `clusterroles` Kubernetes per assegnare autorizzazioni ai ruoli e quindi associare i ruoli alle identità utilizzando `rolebindings` e `clusterrolebindings` Kubernetes. Per ulteriori informazioni, consulta [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) nella documentazione di Kubernetes.
+ È possibile associare un provider di identità OIDC al cluster.
+ Kubernetes non fornisce un provider di identità OIDC. È possibile utilizzare un provider di identità OIDC pubblico esistente oppure eseguire il proprio provider di identità. Per un elenco dei provider certificati, consultare [OpenID Certification](https://openid.net/certification/) sul sito OpenID.
+ L’URL dell’emittente del provider di identità OIDC deve essere accessibile pubblicamente, in modo che Amazon EKS possa individuare le chiavi di firma. Amazon EKS non supporta i provider di identità OIDC con certificati autofirmati.
+ Puoi disabilitare l’autenticazione IAM nel cluster, perché sarà ancora necessaria per aggiungere i nodi a un cluster.
+ Diversamente da un utente di provider di identità, un cluster Amazon EKS deve ancora essere creato da un [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) AWS . Questo perché il creatore del cluster interagisce con Amazon EKS APIs, anziché con APIs Kubernetes.
+ Gli utenti autenticati dal provider di identità OIDC vengono elencati nel registro di controllo del cluster se i log sono attivati per il piano di controllo. CloudWatch Per ulteriori informazioni, consulta [Abilitare o disabilitare i log del piano di controllo (control-plane)](control-plane-logs.md#enabling-control-plane-log-export).
+ Non è possibile accedere a Console di gestione AWS con un account di un provider OIDC. È possibile solo [Visualizza le risorse Kubernetes nel Console di gestione AWS](view-kubernetes-resources.md) accedendo Console di gestione AWS con un account AWS Identity and Access Management.
## Associazione di un provider di identità OIDC
Prima di associare un provider di identità OIDC al cluster, è necessario ottenere dal provider le seguenti informazioni:
**URL dell’emittente**
L’URL del provider di identità OIDC che consente al server API di individuare le chiavi di firma pubbliche per la verifica dei token. L’URL deve iniziare con `https://` e deve corrispondere alla richiesta `iss` nei token ID OIDC del provider. In conformità con lo standard OIDC, i componenti del percorso sono consentiti, ma i parametri di query non lo sono. In genere l’URL è costituito solo da un nome host, come `https://server.example.org` o `https://example.com`. Questo URL dovrebbe puntare al livello sottostante `.well-known/openid-configuration` e dovrà essere accessibile pubblicamente tramite Internet.
**ID client (noto anche come *pubblico*)**
L’ID per l’applicazione client che effettua richieste di autenticazione al provider di identità OIDC.
È possibile associare un provider di identità utilizzando `eksctl` o il Console di gestione AWS.
### Associazione di un provider di identità usando eksctl
1. Crea un file denominato `associate-identity-provider.yaml` con i seguenti contenuti. Sostituire i valori di esempio con i propri valori. I valori nella sezione `identityProviders` vengono ottenuti dal provider di identità OIDC. I valori sono obbligatori solo per il `name`, `type`, `issuerUrl`, e `clientId` impostazioni in `identityProviders`.
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: your-region-code
identityProviders:
- name: my-provider
type: oidc
issuerUrl: https://example.com
clientId: kubernetes
usernameClaim: email
usernamePrefix: my-username-prefix
groupsClaim: my-claim
groupsPrefix: my-groups-prefix
requiredClaims:
string: string
tags:
env: dev
```
**Importante**
Non specificare `system:`, o qualsiasi parte di quella stringa, per `groupsPrefix` o `usernamePrefix`.
1. Creare il provider.
```
eksctl associate identityprovider -f associate-identity-provider.yaml
```
1. Per utilizzare `kubectl` per lavorare con il cluster e il provider di identità OIDC, consulta [Using kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) nella documentazione di Kubernetes.
### Associare un provider di identità utilizzando la AWS console
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Seleziona il cluster, poi seleziona la scheda **Accesso**.
1. Nella sezione **Provider di identità OIDC**, selezionare\$1 Associa provider di identità\$1.
1. Nella pagina **Associate provider di identità OIDC**, inserire o selezionare le seguenti opzioni e quindi selezionare **Associa**.
+ In **Nome**, inserire un nome univoco per il provider.
+ Per **URL dell’emittente**, inserire l’URL per il provider. Questo URL deve essere accessibile in Internet.
+ Per **ID client**, inserire l’ID client del provider di identità OIDC (noto anche come **audience**).
+ Per **Richiesta Nome Utente**, inserire la richiesta da utilizzare come nome utente.
+ Per **Richiesta di Gruppi**, inserire la richiesta da utilizzare come gruppo dell’utente.
+ (Opzionale) Selezionare **Opzioni avanzate**, inserire o selezionare le seguenti informazioni.
+ **Prefisso Nome utente**: inserire un prefisso da anteporre alle richieste del nome utente. Il prefisso viene anteposto alle richieste di nome utente per evitare conflitti con i nomi esistenti. Se non si fornisce un valore e il nome utente è un valore diverso da `email`, il prefisso viene impostato per impostazione predefinita sul valore per **URL dell’emittente**. È possibile utilizzare il valore ` -` per disabilitare tutti i prefissi. Non specificare `system:` o qualsiasi parte di quella stringa.
+ **Prefisso Gruppi**: inserire un prefisso da anteporre alle richieste di gruppo. Il prefisso viene anteposto alle richieste di gruppo per evitare conflitti con i nomi esistenti (ad esempio` system: groups`). Ad esempio, il valore `oidc:` crea nomi di gruppo come `oidc:engineering` e `oidc:infra`. Non specificare `system:` o qualsiasi parte di quella stringa.
+ **Richieste necessarie**: selezionare **Aggiungi richiesta** e inserire una o più coppie di valori chiave che descrivono le richieste necessarie nel token ID client. Le coppie descrivono le richieste necessarie nel Token ID. Se impostato, ogni richiesta viene verificata per essere presente nel token ID con un valore corrispondente.
1. Per utilizzare `kubectl` per lavorare con il cluster e il provider di identità OIDC, consulta [Using kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) nella documentazione di Kubernetes.
## Policy IAM di esempio
Se si desidera impedire che un provider di identità OIDC venga associato a un cluster, creare e associare le seguenti policy IAM agli account IAM degli amministratori Amazon EKS. Per ulteriori informazioni, consulta [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) e [Adding IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) nella *Guida per l’utente IAM* e nelle [Actions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerserviceforkubernetes.html) in Service Authorization Reference.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "denyOIDC",
"Effect": "Deny",
"Action": [
"eks:AssociateIdentityProviderConfig"
],
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/*"
},
{
"Sid": "eksAdmin",
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
}
]
}
```
La seguente policy di esempio consente l’associazione del provider di identità OIDC se il `clientID` è `kubernetes` e la `issuerUrl` è `https://cognito-idp.us-west-2amazonaws.com/*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCognitoOnly",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotLikeIfExists": {
"eks:issuerUrl": "https://cognito-idp.us-west-2.amazonaws.com/*"
}
}
},
{
"Sid": "DenyOtherClients",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotEquals": {
"eks:clientId": "kubernetes"
}
}
},
{
"Sid": "AllowOthers",
"Effect": "Allow",
"Action": "eks:*",
"Resource": "*"
}
]
}
```
# Dissociazione di un provider di identità OIDC dal cluster
Se si dissocia un provider di identità OIDC dal cluster, gli utenti inclusi nel provider non potranno più accedere al cluster. Tuttavia, è comunque possibile accedere al cluster con [principali IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal).
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nella sezione **Provider di identità OIDC**, selezionare **Dissocia**, inserire il nome del provider di identità e quindi selezionare `Disassociate`.
# Visualizza le risorse Kubernetes nel Console di gestione AWS
Puoi visualizzare le risorse Kubernetes implementate nel cluster utilizzando la Console di gestione AWS, [Non puoi visualizzare le risorse Kubernetes con la CLI o AWS eksctl.](https://eksctl.io/) Per visualizzare le risorse Kubernetes con uno strumento a riga di comando, utilizza [kubectl](install-kubectl.md).
**Nota**
Per visualizzare la scheda **Risorse** e la sezione **Nodi** nella scheda **Compute** Console di gestione AWS, il [principale IAM che stai utilizzando deve disporre di autorizzazioni IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) e Kubernetes specifiche. Per ulteriori informazioni, consulta [Autorizzazioni richieste](#view-kubernetes-resources-permissions).
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nell'elenco **Cluster**, seleziona il cluster contenente le risorse Kubernetes da visualizzare.
1. Selezionare la scheda **Risorse**.
1. Seleziona un gruppo **Resource type** (Tipi di risorse) per il quale desideri visualizzare le risorse, ad esempio **Workloads** (Carichi di lavoro). Viene visualizzato un elenco dei tipi di risorse in tale gruppo.
1. Seleziona un tipo di risorsa, ad esempio **Deployments** (Implementazioni), nel gruppo **Workloads** (Carichi di lavoro). Viene visualizzata una descrizione del tipo di risorsa, un collegamento alla documentazione Kubernetes per ulteriori informazioni sul tipo di risorsa e un elenco di risorse simili implementate nel cluster. Se l'elenco è vuoto, nel cluster non sono presenti risorse appartenenti a quel tipo specifico.
1. Per visualizzare ulteriori informazioni su una risorsa, selezionarla. Prova gli esempi seguenti:
+ Seleziona il gruppo **Workloads** (Carichi di lavoro), scegli il tipo di risorsa **Deployments** (Implementazioni), quindi seleziona la risorsa **coredns**. Per impostazione predefinita, la selezione di una risorsa avviene in una **Visualizzazione strutturata**. Per alcuni tipi di risorse, nella **Visualizzazione strutturata** è presente una sezione **Pod**, Questa sezione elenca i pod gestiti dal carico di lavoro. È possibile selezionare qualsiasi pod presente in elenco per visualizzarne le informazioni. Non tutti i tipi di risorse visualizzano le informazioni nella **Visualizzazione strutturata**. Selezionando **Raw view** (Visualizzazione non elaborata) nell'angolo in alto a destra della pagina della risorsa, viene visualizzata la risposta JSON completa dall'API Kubernetes per la risorsa.
+ Seleziona il gruppo **Cluster**, quindi il tipo di risorsa **Nodes** (Nodi). Viene visualizzato un elenco di tutti i nodi del cluster. I nodi possono appartenere a qualsiasi [tipo di nodo di Amazon EKS](eks-compute.md). Si tratta dello stesso elenco visualizzato nella sezione **Nodes** (Nodi) quando si seleziona la scheda **Compute** (Calcolo) del cluster. Seleziona una risorsa di nodo dall'elenco. Nella **Vista strutturata** è presente anche la sezione **Pod** Questa sezione mostra tutti i pod in esecuzione sul nodo.
## Autorizzazioni richieste
Per visualizzare la scheda **Risorse** e la sezione **Nodi** nella scheda **Compute** Console di gestione AWS, il [principale IAM che stai utilizzando deve disporre di autorizzazioni IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) e Kubernetes minime specifiche. È necessario che le autorizzazioni IAM e Kubernetes RBAC siano configurate correttamente. Completa i passaggi seguenti per assegnare le autorizzazioni richieste ai principali IAM.
1. Assicurati che `eks:AccessKubernetesApi` e le altre autorizzazioni IAM necessarie per visualizzare le risorse Kubernetes siano assegnati al principale IAM che stai utilizzando. Per ulteriori informazioni su come modificare le autorizzazioni per un principale IAM, consulta [Controllo dell'accesso per i principali IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-principals) nella Guida per l'utente di IAM. Per ulteriori informazioni su come modificare le autorizzazioni per un ruolo, consulta [Modifica di una policy di autorizzazioni del ruolo (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy) nella Guida per l'utente IAM.
La seguente policy esemplificativa include le autorizzazioni necessarie affinché un principale possa visualizzare le risorse Kubernetes per tutti i cluster dell’account. Sostituiscilo con l'ID del tuo account. *111122223333* AWS
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:ListUpdates",
"eks:AccessKubernetesApi",
"eks:ListAddons",
"eks:DescribeCluster",
"eks:DescribeAddonVersions",
"eks:ListClusters",
"eks:ListIdentityProviderConfigs",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:*:111122223333:parameter/*"
}
]
}
```
Per visualizzare i nodi in [cluster connessi](eks-connector.md), il [ruolo IAM del connettore Amazon EKS](connector-iam-role.md) dovrebbe essere in grado di rappresentare il principale nel cluster. Ciò consente ad [Amazon EKS Connector](eks-connector.md) di mappare il principale IAM a un utilizzatore Kubernetes.
1. Configura le autorizzazioni RBAC di Kubernetes utilizzando le voci di accesso EKS.
**Cosa sono gli EKS Access Entries?**
Le voci di accesso EKS sono un modo semplificato per concedere ai principali IAM (utenti e ruoli) l'accesso al tuo cluster Kubernetes. Invece di gestire manualmente le risorse RBAC di Kubernetes e le `aws-auth` ConfigMap, le voci di accesso gestiscono automaticamente la mappatura tra le autorizzazioni IAM e Kubernetes utilizzando le politiche gestite fornite da. AWS Per informazioni dettagliate [Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS](access-entries.md) sulle voci di accesso, consulta. Per informazioni sui criteri di accesso disponibili e sulle relative autorizzazioni, vedere [Autorizzazioni dei criteri di accesso](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html).
Puoi allegare le autorizzazioni Kubernetes per accedere alle voci in due modi:
+ **Usa una politica di accesso:** le politiche di accesso sono modelli di autorizzazioni Kubernetes predefiniti gestiti da. AWS Questi forniscono set di autorizzazioni standardizzati per casi d'uso comuni.
+ **Fai riferimento a un gruppo Kubernetes:** se associ un'identità IAM a un gruppo Kubernetes, puoi creare risorse Kubernetes che concedono le autorizzazioni al gruppo. Per ulteriori informazioni, consulta [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) nella documentazione di Kubernetes.
1. Crea una voce di accesso per il tuo principale IAM utilizzando la AWS CLI. Sostituisci *my-cluster* con il nome del cluster. Sostituisci *111122223333* con l'ID del tuo account.
```
aws eks create-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
Di seguito viene riportato un output di esempio.
```
{
"accessEntry": {
"clusterName": "my-cluster",
"principalArn": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"kubernetesGroups": [],
"accessEntryArn": "arn:aws: eks:region-code:111122223333:access-entry/my-cluster/role/111122223333/my-console-viewer-role/abc12345-1234-1234-1234-123456789012",
"createdAt": "2024-03-15T10:30:45.123000-07:00",
"modifiedAt": "2024-03-15T10:30:45.123000-07:00",
"tags": {},
"username": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"type": "STANDARD"
}
}
```
1. Associa una policy alla voce di accesso. Per visualizzare le risorse Kubernetes, utilizza: `AmazonEKSViewPolicy`
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=cluster
```
Di seguito viene riportato un output di esempio.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"associatedAt": "2024-03-15T10:31:15.456000-07:00"
}
```
Per un accesso specifico allo spazio dei nomi, puoi estendere la policy a namespace specifici:
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=namespace,namespaces=default,kube-system
```
1. Verifica che la voce di accesso sia stata creata correttamente:
```
aws eks describe-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
1. Elenca le politiche associate per confermare l'associazione delle politiche:
```
aws eks list-associated-access-policies \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
Di seguito viene riportato un output di esempio.
```
{
"associatedAccessPolicies": [
{
"policyArn": "arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster"
},
"associatedAt": "2024-03-15T10:31:15.456000-07:00",
"modifiedAt": "2024-03-15T10:31:15.456000-07:00"
}
]
}
```
## CloudTrail visibilità
Durante la visualizzazione delle risorse Kubernetes, nei log verrà visualizzato il seguente nome dell'operazione: CloudTrail
+ `AccessKubernetesApi`- Durante la lettura o la visualizzazione di risorse
Questo CloudTrail evento fornisce una traccia di controllo dell'accesso in lettura alle risorse Kubernetes.
**Nota**
Questo nome dell'operazione viene visualizzato nei CloudTrail log solo a scopo di controllo. Non è un'azione IAM e non può essere utilizzata nelle dichiarazioni delle politiche IAM. Per controllare l'accesso in lettura alle risorse Kubernetes tramite le policy IAM, utilizza l'`eks:AccessKubernetesApi`autorizzazione come mostrato nella sezione. [Autorizzazioni richieste](#view-kubernetes-resources-permissions)
# Concedi AWS ai servizi l'accesso in scrittura a Kubernetes APIs
## Autorizzazioni richieste
Per consentire ai AWS servizi di eseguire operazioni di scrittura sulle risorse Kubernetes nel tuo cluster Amazon EKS, devi concedere sia le `eks:AccessKubernetesApi` autorizzazioni che quelle IAM. `eks:MutateViaKubernetesApi`
Ad esempio, Amazon SageMaker HyperPod utilizza queste autorizzazioni per abilitare la distribuzione di modelli da SageMaker AI Studio. Per ulteriori informazioni, consulta [Configurare le autorizzazioni JavaScript SDK opzionali](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-model-deployment-setup.html#sagemaker-hyperpod-model-deployment-setup-optional-js) nella Amazon SageMaker AI Developer Guide.
**Importante**
Le operazioni di scrittura come la creazione, l'aggiornamento e l'eliminazione richiedono entrambe le autorizzazioni: se una delle due autorizzazioni è mancante, le operazioni di scrittura avranno esito negativo.
## CloudTrail visibilità
Durante l'esecuzione di operazioni di scrittura sulle risorse Kubernetes, nei log verranno visualizzati nomi di operazioni specifici: CloudTrail
+ `createKubernetesObject`- Durante la creazione di nuove risorse
+ `updateKubernetesObject`- Quando si modificano risorse esistenti
+ `deleteKubernetesObject`- Quando si rimuovono risorse
Questi CloudTrail eventi forniscono audit trail dettagliati di tutte le modifiche apportate alle risorse Kubernetes.
**Nota**
Questi nomi di operazioni vengono visualizzati nei CloudTrail log solo a scopo di controllo. Non sono azioni IAM e non possono essere utilizzate nelle dichiarazioni politiche IAM. Per controllare l'accesso in scrittura alle risorse Kubernetes tramite le policy IAM, utilizza l'`eks:MutateViaKubernetesApi`autorizzazione come mostrato nella sezione. [Autorizzazioni richieste](#mutate-kubernetes-resources-permissions)
# Connettere kubectl a un cluster EKS creando un file kubeconfig
**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.
In questo argomento viene creato un file `kubeconfig` per il cluster (o ne viene aggiornato uno esistente).
Lo strumento della linea di comando `kubectl` utilizza le informazioni di configurazione nei file `kubeconfig` per comunicare con il server API di un cluster. Per ulteriori informazioni, consulta la sezione [Organizing Cluster Access Using kubeconfig Files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) nella documentazione di Kubernetes.
Amazon EKS utilizza il comando `aws eks get-token` con `kubectl` per l'autenticazione del cluster. Per impostazione predefinita, la AWS CLI utilizza le stesse credenziali restituite con il seguente comando:
```
aws sts get-caller-identity
```
+ Un cluster Amazon EKS esistente. Per implementarne uno, consulta [Nozioni di base su Amazon EKS](getting-started.md).
+ 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):
+ 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*.
+ Un ruolo o un utente IAM con l'autorizzazione a utilizzare l'azione API `eks:DescribeCluster` per il cluster che specifichi. Per ulteriori informazioni, consulta [Esempi di policy basate su identità Amazon EKS](security-iam-id-based-policy-examples.md). Se utilizzi un’identità del tuo provider OpenID Connectper accedere al cluster, consulta la sezione [Using kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) nella documentazione di Kubernetes per creare o aggiornare il file `kube config`.
## Creazione automatica del file `kubeconfig`
+ 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*.
+ Autorizzazione a utilizzare l'operazione API `eks:DescribeCluster` per il cluster specificato. Per ulteriori informazioni, consulta [Esempi di policy basate su identità Amazon EKS](security-iam-id-based-policy-examples.md).
1. Crea o aggiorna un file `kubeconfig` per il cluster. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster e sostituiscilo *my-cluster* con il nome del cluster.
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
Per impostazione predefinita, il file di configurazione risultante viene creato nel percorso `kubeconfig` predefinito (`.kube`) nella home directory o unito a un file `config` esistente in quel percorso. È possibile specificare un altro percorso con l'opzione `--kubeconfig`.
Puoi specificare un ARN del ruolo IAM con l'opzione `--role-arn` da utilizzare per l'autenticazione quando esegui comandi `kubectl`. Altrimenti, viene utilizzato il [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) nella catena di credenziali AWS CLI o SDK predefinita. È possibile visualizzare l'identità AWS CLI o SDK predefinita eseguendo il comando. `aws sts get-caller-identity`
*Per tutte le opzioni disponibili, esegui il `aws eks update-kubeconfig help` comando o consulta [update-kubeconfig](https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html) nella CLI AWS Command Reference.*
1. Prova la configurazione.
```
kubectl get svc
```
Di seguito viene riportato un output di esempio:
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes ClusterIP 10.100.0.1 443/TCP 1m
```
Se ricevi qualsiasi altro errore di tipo di risorsa o autorizzazione, consulta la sezione [Accesso negato o non autorizzato (`kubectl`)](troubleshooting.md#unauthorized) nell’argomento relativo alla risoluzione dei problemi.
# Concessione ai carichi di lavoro Kubernetes dell’accesso a AWS utilizzando gli account di servizio Kubernetes
[Gestione degli account di servizio](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin)[Ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md)[Informazioni su come EKS Pod Identity consente ai pod di accedere ai servizi AWS](pod-identities.md)
## Token dell'account di servizio
La funzionalità [BoundServiceAccountTokenVolume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) è abilitata per impostazione predefinita nelle versioni di Kubernetes. Questa funzionalità migliora la sicurezza dei token dell'account di servizio, consentendo ai carichi di lavoro in esecuzione su Kubernetes di richiedere token Web JSON associati a pubblico, tempo e chiavi. I token dell'account di servizio scadono entro un'ora, Nelle versioni precedenti di Kubernetes, i token non avevano scadenza. Di conseguenza, i client che si basano su questi token devono aggiornarli entro un'ora. Gli [SDK client Kubernetes](https://kubernetes.io/docs/reference/using-api/client-libraries/) seguenti aggiornano automaticamente i token entro il periodo di tempo richiesto:
+ Go versione `0.15.7` e successive
+ Python versione `12.0.0` e successive
+ Java versione `9.0.0` e successive
+ JavaScript versione `0.10.3` e successive
+ Ramo `master` di Ruby
+ Haskell versione `0.3.0.0`
+ Versione C\$1 `7.0.5` e successive
Se il carico di lavoro utilizza una versione precedente del client, è necessario aggiornarla. Per consentire una migrazione agevole dei client verso i più recenti token dell’account di servizio con limite di tempo, Kubernetes proroga il periodo di scadenza dei token, rispetto a quello predefinito di un’ora. Per i cluster Amazon EKS, il periodo di scadenza è prorogato a 90 giorni. Il server API Kubernetes del cluster Amazon EKS rifiuta le richieste con token che sono più vecchi di 90 giorni. Consigliamo di controllare le applicazioni e le relative dipendenze per assicurarti che gli SDK del client Kubernetes corrispondano o siano successivi alle versioni elencate sopra.
Quando il server API riceve richieste con token più vecchie di un'ora, le annota nel log eventi di controllo API con `annotations.authentication.k8s.io/stale-token`. Il valore dell'annotazione è simile a quello riportato di seguito:
```
subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.
```
Se nel cluster è abilitata la [registrazione del piano di controllo (control-plane)](control-plane-logs.md), le annotazioni di trovano nei registri di controllo. Per identificare tutti i pod del cluster Amazon EKS che utilizzano token obsoleti, è possibile utilizzare la seguente query di [Log Insights di Cloudwatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html):
```
fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime
```
`subject` si riferisce all’account di servizio utilizzato dal pod. `elapsedtime` indica in secondi il tempo trascorso dalla lettura dell'ultimo token. Le richieste al server API vengono negate quando `elapsedtime` supera i 90 giorni (7.776.000 secondi). Per utilizzare una delle versioni elencate sopra e aggiornare automaticamente il token, devi aggiornare in modo proattivo l’SDK client Kubernetes delle applicazioni. Se il token dell’account di servizio utilizzato è prossimo ai 90 giorni e non si ha tempo sufficiente per aggiornare le versioni dell’SDK client prima della scadenza, è possibile terminare i pod esistenti e crearne di nuovi. Ciò comporta una ridefinizione del token dell'account di servizio, concedendo agli utenti altri 90 giorni per aggiornare gli SDK della versione client.
Se il pod fa parte di un’implementazione, è consigliabile terminare i pod eseguendo un rollout in modo da mantenere un’elevata disponibilità. Per eseguire questa operazione, utilizzare il comando seguente. Sostituisci *my-deployment* con il nome dell'implementazione.
```
kubectl rollout restart deployment/my-deployment
```
## Componenti aggiuntivi del cluster
I componenti aggiuntivi del cluster seguenti sono stati aggiornati per utilizzare gli SDK client Kubernetes che riconfigurano automaticamente i token dell’account di servizio. Assicurati che le versioni elencate, o versioni successive, siano installate sul tuo cluster.
+ Plugin helper per le metriche e plugin CNI di Amazon VPC per Kubernetes versione `1.8.0` e successive. Per verificare la versione attuale o aggiornarla, consulta [Assegna IPs ai pod con Amazon VPC CNI](managing-vpc-cni.md) e [cni-metrics-helper](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md).
+ Versione CoredNS `1.8.4` e successive. Per verificare la versione attuale o aggiornarla, consulta [Gestisci CoredNS per DNS nei cluster Amazon EKS](managing-coredns.md).
+ AWS Load Balancer Controller versione `2.0.0` e successive. Per verificare la versione attuale o aggiornarla, consulta [Indirizza il traffico Internet con AWS Load Balancer Controller](aws-load-balancer-controller.md).
+ Versione `kube-proxy` attuale. Per verificare la versione attuale o aggiornarla, consulta [Gestisci `kube-proxy` nei cluster Amazon EKS](managing-kube-proxy.md).
+ AWS per Fluent Bit versione `2.25.0` o successive. Per aggiornare la versione attuale, consulta [Versioni](https://github.com/aws/aws-for-fluent-bit/releases) su GitHub.
+ Versione dell'immagine di Fluentd [1.14.6-1.2](https://hub.docker.com/r/fluent/fluentd/tags?page=1&name=v1.14.6-1.2) o versione successiva e plugin di filtro Fluentd per la versione dei metadati Kubernetes [2.11.1](https://rubygems.org/gems/fluent-plugin-kubernetes_metadata_filter/versions/2.11.1) o successive.
## Concedere le autorizzazioni di AWS Identity and Access Management ai carichi di lavoro sui cluster Amazon Elastic Kubernetes Service
Amazon EKS offre due modi per concedere le autorizzazioni di AWS Identity and Access Management ai carichi di lavoro eseguiti nei cluster Amazon EKS: *ruoli IAM per gli account di servizio* ed *EKS Pod Identity*.
**Ruoli IAM per gli account di servizio**
*Ruoli IAM per gli account di servizio (IRSA)* configura le applicazioni Kubernetes in esecuzione su AWS con autorizzazioni IAM granulari per accedere a varie altre risorse AWS come bucket Amazon S3, tabelle Amazon DynamoDB e altro ancora. Puoi eseguire più applicazioni contemporaneamente nello stesso cluster Amazon EKS e assicurarti che ogni applicazione disponga solo del set minimo di autorizzazioni di cui ha bisogno. IRSA è stato creato per supportare varie opzioni di implementazione Kubernetes supportate da AWS, come Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service su AWS, e cluster autogestiti su istanze Amazon EC2. Pertanto, IRSA è stato creato utilizzando servizi AWS fondamentali come IAM e non ha assunto alcuna dipendenza diretta dal servizio Amazon EKS e dall'API EKS. Per ulteriori informazioni, consulta [Ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md).
**EKS Pod Identity**
EKS Pod Identity offre agli amministratori dei cluster un flusso di lavoro semplificato per l'autenticazione delle applicazioni al fine di accedere a varie altre risorse AWS come bucket Amazon S3, tabelle Amazon DynamoDB e altro ancora. EKS Pod Identity è solo per EKS e, di conseguenza, semplifica il modo in cui gli amministratori dei cluster possono configurare le applicazioni Kubernetes per ottenere le autorizzazioni IAM. Queste autorizzazioni possono ora essere facilmente configurate con meno passaggi direttamente tramite Console di gestione AWS, API EKS e AWS CLI e non è necessario eseguire alcuna operazione all’interno del cluster su nessun oggetto Kubernetes. Gli amministratori del cluster non devono passare dai servizi EKS ai servizi IAM o utilizzare operazioni IAM privilegiate per configurare le autorizzazioni richieste dalle applicazioni. I ruoli IAM possono ora essere utilizzati su più cluster senza la necessità di aggiornare la policy di attendibilità dei ruoli durante la creazione di nuovi cluster. Le credenziali IAM fornite da EKS Pod Identity includono tag di sessione dei ruoli, con attributi come nome del cluster, namespace, nome dell'account di servizio. I tag di sessione di ruolo consentono agli amministratori di creare un singolo ruolo che può funzionare su più account di servizio, permettendo l'accesso alle risorse AWS in base ai tag corrispondenti. Per ulteriori informazioni, consulta [Informazioni su come EKS Pod Identity consente ai pod di accedere ai servizi AWS](pod-identities.md).
### Confronto tra EKS Pod Identity e IRSA
A un livello superiore, sia EKS Pod Identity che IRSA concedono autorizzazioni IAM alle applicazioni in esecuzione su cluster Kubernetes. Ma sono fondamentalmente diversi nel modo in cui vengono configurati, nei limiti supportati e nelle funzionalità abilitate. Di seguito, confrontiamo alcuni degli aspetti chiave di entrambe le soluzioni.
**Nota**
AWS consiglia di utilizzare EKS Pod Identity per concedere l’accesso alle risorse AWS dei pod ogni volta che è possibile. Per ulteriori informazioni, consulta [Informazioni su come EKS Pod Identity consente ai pod di accedere ai servizi AWS](pod-identities.md).
| Attributo | EKS Pod Identity | IRSA |
| --- | --- | --- |
| Estensibilità dei ruoli | È necessario configurare ogni ruolo una volta per instaurare un rapporto di attendibilità con il principale di servizio Amazon EKS introdotto di recente, `pods.eks.amazonaws.com`. Dopo questo passaggio una tantum, non è necessario aggiornare la policy di attendibilità del ruolo ogni volta che è utilizzato in un nuovo cluster. | È necessario aggiornare la policy di attendibilità del ruolo IAM con il nuovo endpoint del provider OIDC del cluster EKS ogni volta che si desidera utilizzare il ruolo in un nuovo cluster. |
| Scalabilità del cluster | EKS Pod Identity non richiede agli utenti di configurare il provider OIDC di IAM, quindi questo limite non si applica. | Ciascun cluster EKS ha un URL emittente OpenID Connect (OIDC) associato ad esso. Per utilizzare IRSA, è necessario creare un provider OpenID Connect univoco per ogni cluster EKS in IAM. IAM ha un limite globale predefinito di 100 provider OIDC per ciascun account AWS. Se prevedi di avere più di 100 cluster EKS per ciascun account AWS con IRSA, raggiungerai il limite del provider OIDC di IAM. |
| Scalabilità dei ruoli | EKS Pod Identity non richiede agli utenti di definire una relazione di attendibilità tra il ruolo IAM e l’account di servizio nella policy di attendibilità, quindi questo limite non è applicato. | In IRSA, definisci la relazione di attendibilità tra un ruolo IAM e un account di servizio nella policy di attendibilità del ruolo. Per impostazione predefinita, la lunghezza della dimensione della policy di attendibilità è `2048`. Ciò significa che in genere è possibile definire 4 relazioni di attendibilità in un'unica policy di attendibilità. Sebbene sia possibile aumentare il limite di lunghezza della policy di attendibilità, in genere si è limitati a un massimo di 8 relazioni di attendibilità all'interno di una singola policy di attendibilità. |
| Utilizzo della quota API di STS | EKS Pod Identity semplifica l’invio delle credenziali AWS ai pod e non richiede il codice per effettuare chiamate direttamente con il AWS Security Token Service (STS). Il servizio EKS gestisce l’assunzione dei ruoli e fornisce le credenziali alle applicazioni scritte utilizzando AWS SDK nei pod senza che i pod comunichino con AWS STS o utilizzino una quota API di STS. | In IRSA, le applicazioni scritte utilizzando AWS SDK nei pod utilizzano i token per chiamare l’API `AssumeRoleWithWebIdentity` su AWS Security Token Service (STS). A seconda della logica del codice di AWS SDK, è possibile che il codice effettui chiamate non necessarie a AWS STS e riceva errori di limitazione (della larghezza di banda della rete). |
| Riutilizzabilità dei ruoli | Le credenziali temporanee AWS STS fornite da EKS Pod Identity includono tag di sessione dei ruoli, come nome del cluster, namespace e nome dell’account di servizio. I tag di sessione dei ruoli permettono agli amministratori di creare un singolo ruolo IAM che può essere utilizzato con più account di servizio, con diverse autorizzazioni effettive, consentendo l'accesso alle risorse AWS in base ai tag ad essi collegati. Questo ruolo è chiamato anche controllo degli accessi basato su attributi (ABAC). Per ulteriori informazioni, consulta [Concedi ai Pods l'accesso alle AWS risorse in base ai tag](pod-id-abac.md). | I tag di sessione AWS STS non sono supportati. È possibile riutilizzare un ruolo tra i cluster, ma ogni pod riceve tutte le autorizzazioni del ruolo. |
| Ambienti supportati | EKS Pod Identity è disponibile solo su Amazon EKS. | IRSA può essere utilizzato su cluster Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service su AWS e su cluster Kubernetes autogestiti su istanze Amazon EC2. |
| Versioni EKS supportate | Tutte le versioni del cluster EKS supportate. Per le versioni delle piattaforme specifiche, consulta [Versioni del cluster EKS Pod Identity](pod-identities.md#pod-id-cluster-versions). | Tutte le versioni del cluster EKS supportate. |
# Ruoli IAM per gli account di servizio
**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)
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
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
+ 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)
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 `` con il proprio valore.
```
cluster_name=
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..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
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
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
+ 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
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
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)
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)
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 <
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:
Mountable secrets: my-service-account-token-qqjfl
Tokens: my-service-account-token-qqjfl
[...]
```
## Fasi successive
+ [Configurazione di pod per utilizzare un account di servizio Kubernetes](pod-configuration.md)
# Configurazione di pod per utilizzare un account di servizio Kubernetes
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 <
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
Ѐ 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
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
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
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
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
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
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
**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
### Java
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
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
+ 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
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"}]}
```
# Informazioni su come EKS Pod Identity consente ai pod di accedere ai servizi AWS
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.
[](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
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
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
+ Sono supportate fino a 5.000 associazioni EKS Pod Identity per cluster per mappare i ruoli IAM agli account di servizio Kubernetes.
## Considerazioni
+ **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
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
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
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
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
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
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
+ 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
### Prerequisiti dell'agente
+ 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
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
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
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)
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)
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 <
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
[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
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
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
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
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
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
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
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
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
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
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 <
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
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
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
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
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
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
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
## Utilizzo delle credenziali EKS Pod Identity
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
## Console di gestione AWS
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
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
```
{
"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).