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