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