**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à.
# Sicurezza in Amazon EKS
La sicurezza del cloud AWS è la massima priorità. In qualità di AWS cliente, puoi beneficiare di un data center e di un'architettura di rete progettati per soddisfare i requisiti delle organizzazioni più sensibili alla sicurezza.
La sicurezza è una responsabilità condivisa tra AWS te e te. Il [modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/) descrive questo come sicurezza *del* cloud e sicurezza *nel* cloud:
+ **Sicurezza del cloud**: AWS è responsabile della protezione dell'infrastruttura che gestisce AWS i servizi nel AWS cloud. Per Amazon EKS, AWS è responsabile del piano di controllo Kubernetes, che include i nodi del piano di controllo e il database. `etcd` I revisori di terze parti testano e verificano regolarmente l'efficacia della sicurezza come parte dei [programmi di conformitàAWS](https://aws.amazon.com/compliance/programs/). Per ulteriori informazioni sui programmi di conformità che si applicano ad Amazon EKS, consultare [Servizi AWS coperti dal programma di conformità](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sicurezza nel cloud** - Le seguenti aree sono sotto la responsabilità dell'utente.
+ La configurazione di sicurezza del piano dei dati, compresa la configurazione dei gruppi di sicurezza che autorizzano il passaggio del traffico dal piano di controllo Amazon EKS al VPC del cliente
+ La configurazione dei nodi di lavoro e degli stessi container
+ Il sistema operativo che ospita il nodo di lavoro (inclusi gli aggiornamenti e le patch di sicurezza)
+ Altri software applicativi associati:
+ La configurazione e la gestione dei controlli di rete, come le regole del firewall
+ La gestione di identità a livello di piattaforma e la gestione degli accessi, con o in aggiunta alle IAM
+ La riservatezza dei dati, i requisiti dell'azienda e le leggi e le normative applicabili.
Amazon EKS è certificato da svariati programmi di conformità per applicazioni regolamentate e sensibili. Amazon EKS è conforme a [SOC](https://aws.amazon.com/compliance/soc-faqs/), [PCI](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/), [ISO](https://aws.amazon.com/compliance/iso-certified/), [FedRAMP-Moderate](https://aws.amazon.com/compliance/fedramp/), [IRAP](https://aws.amazon.com/compliance/irap/), [C5](https://aws.amazon.com/compliance/bsi-c5/), [K-ISMS](https://aws.amazon.com/compliance/k-isms/), [ENS High](https://aws.amazon.com/compliance/esquema-nacional-de-seguridad/), [OSPAR](https://aws.amazon.com/compliance/OSPAR/), [HITRUST CSF](https://aws.amazon.com/compliance/hitrust/), ed è un servizio idoneo allo standard [HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/). Per ulteriori informazioni, consulta [Informazioni su come funziona il controllo degli accessi in Amazon EKS](cluster-auth.md).
Questa documentazione aiuta a comprendere come applicare il modello di responsabilità condivisa quando si utilizza Amazon EKS. Gli argomenti seguenti descrivono come configurare Amazon EKS per soddisfare gli obiettivi di sicurezza e conformità. Scopri anche come utilizzare altri AWS servizi che ti aiutano a monitorare e proteggere le tue risorse Amazon EKS.
**Nota**
I container Linux sono costituiti da gruppi di controllo (cgroup) e namespace che aiutano a limitare l'accesso a cui un container può accedere, ma tutti i contenitori condividono lo stesso kernel Linux dell'istanza Amazon host. EC2 L'esecuzione di un container come utente root (UID 0), o la concessione di un accesso al container a risorse host o namespace, come la rete host o il namespace PID host sono fortemente sconsigliati, in quanto ciò riduce l'efficacia dell'isolamento fornito dai container.
**Topics**
+ [Protezione dei cluster Amazon EKS con le best practice](security-best-practices.md)
+ [Analizzare le vulnerabilità in Amazon EKS](configuration-vulnerability-analysis.md)
+ [Convalida della conformità per cluster di Amazon EKS](compliance.md)
+ [Considerazioni di sicurezza per Amazon Elastic Container Service per Kubernetes](security-eks.md)
+ [Considerazioni sulla sicurezza per Kubernetes](security-k8s.md)
+ [Considerazioni sulla sicurezza per Amazon EKS Auto Mode](auto-security.md)
+ [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)
+ [Identity and Access Management per Amazon EKS](security-iam.md)
# Protezione dei cluster Amazon EKS con le best practice
Le best practice di sicurezza di Amazon EKS si trovano nelle [Best practice per la sicurezza](https://docs.aws.amazon.com/eks/latest/best-practices/security.html) della *Guida delle best practice di Amazon EKS*.
# Analizzare le vulnerabilità in Amazon EKS
La sicurezza è una considerazione fondamentale per la configurazione e la manutenzione di cluster e applicazioni Kubernetes. Di seguito sono elencate le risorse per analizzare la configurazione di sicurezza dei cluster EKS, le risorse per verificare la presenza di vulnerabilità e le integrazioni con i servizi AWS che possono eseguire l’analisi.
## Il Center for Internet Security (CIS) Benchmark per Amazon EKS
Il [Center for Internet Security (CIS) Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) fornisce indicazioni per le configurazioni di sicurezza di Amazon EKS. Il benchmark:
+ È applicabile ai nodi Amazon EC2 (gestiti e autogestiti) in cui sei responsabile delle configurazioni di sicurezza dei componenti Kubernetes.
+ Fornisce un modo standard approvato dalla community per garantire di aver configurato in modo sicuro il cluster Kubernetes e i nodi quando si utilizza Amazon EKS.
+ È costituito da quattro sezioni: configurazione della registrazione del piano di controllo, configurazioni di sicurezza dei nodi, criteri e servizi gestiti.
+ Supporta tutte le versioni Kubernetes attualmente disponibili in Amazon EKS e può essere eseguito utilizzando [kube-bench](https://github.com/aquasecurity/kube-bench), uno strumento open source standard per il controllo della configurazione utilizzando il benchmark CIS sui cluster Kubernetes.
Per ulteriori informazioni, consulta [Presentazione del benchmark CIS Amazon EKS](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark).
Per una pipeline `aws-sample` automatizzata al fine di aggiornare il gruppo di nodi con un AMI con benchmark CIS, consulta [EKS-Optimized AMI Hardening Pipeline](https://github.com/aws-samples/pipeline-for-hardening-eks-nodes-and-automating-updates).
## Versioni della piattaforma Amazon EKS
Le *versioni della piattaforma* Amazon EKS rappresentano le funzionalità del piano di controllo del cluster, tra cui i flag del server API di Kubernetes abilitati e l’attuale versione della patch di Kubernetes. I nuovi cluster vengono implementati con la versione più recente della piattaforma. Per i dettagli, consulta [EKS platform-versions](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
È possibile [aggiornare un cluster Amazon EKS](update-cluster.md) alla versione più recente di Kubernetes. Man mano che nuove versioni di Kubernetes diventano disponibili in Amazon EKS, ti consigliamo di aggiornare tempestivamente i cluster in modo da usare la versione più recente disponibile. Per ulteriori informazioni sulle versioni di Kubernetes in EKS, consulta [Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
## Elenco delle vulnerabilità del sistema operativo
### Elenco vulnerabilità di AL2023
Tieni traccia degli eventi di sicurezza o di privacy per Amazon Linux 2023 nel [Centro di sicurezza di Amazon Linux](https://alas.aws.amazon.com/alas2023.html) o iscriviti al [feed RSS](https://alas.aws.amazon.com/AL2023/alas.rss) associato. Gli eventi relativi alla sicurezza e alla privacy includono una panoramica del problema, i pacchetti e le istruzioni per l’aggiornamento delle istanze per correggere il problema.
### Elenco delle vulnerabilità di Amazon Linux 2
Tieni traccia degli eventi di sicurezza o di privacy per Amazon Linux 2 nel [Centro di sicurezza di Amazon Linux](https://alas.aws.amazon.com/alas2.html) o iscriviti al [feed RSS](https://alas.aws.amazon.com/AL2/alas.rss) associato. Gli eventi relativi alla sicurezza e alla privacy includono una panoramica del problema, i pacchetti e le istruzioni per l’aggiornamento delle istanze per correggere il problema.
## Rilevamento dei nodi con Amazon Inspector
È possibile utilizzare [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) per verificare la presenza di accessibilità alla rete non intenzionale dei nodi e le vulnerabilità sulle istanze Amazon EC2.
## Rilevamento di cluster e nodi con Amazon GuardDuty
Amazon GuardDuty è un servizio di rilevamento delle minacce che monitora continuamente gli account, i container, i carichi di lavoro e i dati all’interno dell’ambiente AWS. Tra le altre funzionalità, GuardDuty offre le due funzionalità seguenti che rilevano potenziali minacce ai cluster EKS: *Protezione EKS* e *Monitoraggio del runtime*.
Per ulteriori informazioni, consulta [Rileva minacce con Amazon GuardDuty](integration-guardduty.md).
# Convalida della conformità per cluster di Amazon EKS
Per sapere se un servizio AWS è coperto da programmi di conformità specifici, consulta [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) e scegli il programma di conformità desiderato. Per informazioni generali, consulta [Programmi di conformità di AWS](https://aws.amazon.com/compliance/programs/).
Puoi scaricare i report di audit di terze parti utilizzando AWS Artifact. Per ulteriori informazioni, consulta [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
La tua responsabilità per la compliance quando si utilizzano i servizi AWS è determinata dalla riservatezza dei dati, dagli obiettivi di conformità dell’azienda e dalle normative vigenti. Per semplificare il rispetto della conformità, AWS offre i seguenti servizi:
+ [Governance e conformità per la sicurezza](https://aws.amazon.com/solutions/security/security-compliance-governance/): queste guide all’implementazione di soluzioni illustrano considerazioni relative all’architettura e i passaggi per implementare le funzionalità di sicurezza e conformità.
+ [Riferimenti sui servizi conformi ai requisiti HIPAA](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/): elenca i servizi HIPAA idonei. Non tutti i servizi AWS sono conformi ai requisiti HIPAA.
+ [Risorse per la conformità di AWS](https://aws.amazon.com/compliance/resources/): questa raccolta di workbook e guide potrebbe essere utile al settore e alla posizione.
+ [AWSGuide alla conformità dei clienti](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf): comprendi il modello di responsabilità condivisa attraverso la lente della conformità. Le guide riassumono le migliori pratiche per la protezione dei servizi AWS e mappano le linee guida per i controlli di sicurezza su più framework (tra cui il National Institute of Standards and Technology (NIST), il Payment Card Industry Security Standards Council (PCI) e l’International Organization for Standardization (ISO)).
+ [Valutazione delle risorse con le regole](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) nella *Guida per gli sviluppatori di AWS*: il servizio AWS Config valuta il livello di conformità delle configurazioni delle risorse con pratiche interne, linee guida e regolamenti industriali.
+ [AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html): questo servizio AWS fornisce una vista completa dello stato di sicurezza in AWS. Security Hub utilizza i controlli di sicurezza per valutare le risorse AWS e verificare la conformità agli standard e alle best practice del settore della sicurezza. Per un elenco dei servizi e dei controlli supportati, consulta la pagina [Documentazione di riferimento sui controlli della Centrale di sicurezza](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html).
+ [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html): questo servizio AWS rileva potenziali minacce ad account AWS, carichi di lavoro, container e dati monitorando l’ambiente alla ricerca di attività sospette e dannose. GuardDuty soddisfa i requisiti di rilevamento delle intrusioni imposti da determinati framework di conformità e garantisce il rispetto di vari standard come il PCI DSS.
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html): questo servizio AWS aiuta a controllare continuamente l’utilizzo di AWS per semplificare la gestione dei rischi e la conformità alle normative e agli standard di settore.
# Considerazioni di sicurezza per Amazon Elastic Container Service per Kubernetes
Di seguito sono riportate alcune considerazioni relative alla sicurezza del cloud, in quanto influiscono su Amazon EKS.
**Topics**
+ [Sicurezza dell’infrastruttura in Amazon EKS](infrastructure-security.md)
+ [Comprendere la resilienza nei cluster Amazon EKS](disaster-recovery-resiliency.md)
+ [Prevenzione del problema “confused deputy” tra servizi in Amazon EKS](cross-service-confused-deputy-prevention.md)
# Sicurezza dell’infrastruttura in Amazon EKS
In quanto servizio gestito, Amazon Elastic Kubernetes Service è protetto dalla sicurezza di rete globale di AWS. Per informazioni sui servizi di sicurezza AWSe su come AWSprotegge l’infrastruttura, consulta la pagina [Sicurezza del cloud AWS](https://aws.amazon.com/security/). Per progettare l’ambiente AWSutilizzando le best practice per la sicurezza dell’infrastruttura, consulta la pagina [Protezione dell’infrastruttura](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) nel *Pilastro della sicurezza di AWSWell‐Architected Framework*.
Utilizzare le chiamate API pubblicate di AWS per accedere a Amazon EKS tramite la rete. I client devono supportare quanto segue:
+ Transport Layer Security (TLS). È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Suite di cifratura con Perfect Forward Secrecy (PFS), ad esempio Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La maggior parte dei sistemi moderni, come Java 7 e versioni successive, supporta tali modalità.
Inoltre, le richieste devono essere firmate utilizzando un ID chiave di accesso e una chiave di accesso segreta associata a un principale IAM. In alternativa, puoi utilizzare [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) per generare le credenziali di sicurezza temporanee per firmare le richieste.
Quando si crea un cluster Amazon EKS, specificare anche le sottoreti VPC; che devono essere utilizzate dal cluster. Amazon EKS richiede sottoreti in almeno due zone di disponibilità. È consigliabile un VPC con sottoreti pubbliche e private in modo che Kubernetes possa creare bilanciatori del carico pubblici nelle sottoreti pubbliche, che bilancino il carico del traffico ai pod in esecuzione su nodi che si trovano in sottoreti private.
Per ulteriori informazioni sulle considerazioni per il VPC, consultare [Visualizzazione di requisiti di rete di Amazon EKS per VPC e sottoreti](network-reqs.md).
Se si crea il proprio VPC e i gruppi di nodi con i modelli AWS CloudFormation forniti nella procedura dettagliata [Get started with Amazon EKS](getting-started.md), il piano di controllo e i gruppi di sicurezza dei nodi di lavoro vengono configurati con le impostazioni consigliate.
Per ulteriori informazioni sulle considerazioni per i gruppi di sicurezza, consultare [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md).
Quando si crea un nuovo cluster, Amazon EKS crea un endpoint per il server API Kubernetes gestito utilizzato per comunicare con il cluster (usando strumenti di gestione Kubernetes, ad esempio `kubectl`). Per impostazione predefinita, questo endpoint del server API è pubblico in Internet e l’accesso al server API è protetto utilizzando una combinazione di AWS Identity and Access Management (AWS IAM) e dal [controllo degli accessi basato sul ruolo](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) Kubernetes nativo.
Puoi abilitare l’accesso privato al server API Kubernetes in modo che tutte le comunicazioni tra i nodi di lavoro e il server API rimangano all’interno del VPC. È possibile limitare gli indirizzi IP che possono accedere al server API da Internet o disabilitare completamente l’accesso a Internet al server API.
Per ulteriori informazioni sulla modifica dell’accesso all’endpoint del cluster, consultare [Modifica dell'accesso all'endpoint del cluster](cluster-endpoint.md#modify-endpoint-access).
È possibile implementare *policy di rete* Kubernetes con CNI di Amazon VPC o strumenti di terze parti come [Project Calico](https://docs.tigera.io/calico/latest/about/). Per ulteriori informazioni sull’utilizzo della CNI di Amazon VPC per le policy di rete, consulta la pagina [Limita il traffico di Pod con le policy di rete di Kubernetes](cni-network-policy.md). Project Calico è un progetto open source di terze parti. Per ulteriori informazioni, consulta la [documentazione di Project Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/).
# Accesso ad Amazon EKS tramite AWS PrivateLink
È possibile utilizzare AWS PrivateLink per creare una connessione privata tra il tuo VPC e Amazon Elastic Kubernetes Service. È possibile accedere ad Amazon EKS come se fosse nel tuo VPC, senza utilizzare un gateway Internet, un dispositivo NAT, una connessione VPN o una connessione a collegamento diretto AWS. Le istanze nel tuo VPC non richiedono indirizzi IP pubblici per l’accesso ad Amazon EKS.
Stabilisci questa connessione privata creando un endpoint di interfaccia alimentato da AWS PrivateLink. In ciascuna sottorete viene creata un'interfaccia di rete endpoint da abilitare per l'endpoint di interfaccia. Queste sono interfacce di rete gestite dal richiedente che fungono da punto di ingresso per il traffico destinato ad Amazon EKS.
Per ulteriori informazioni, consulta [Accedere ai servizi AWS tramite AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) nella *Guida AWS PrivateLink*.
## Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
+ Esamina [Accesso a un servizio AWS utilizzando un endpoint VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) nella *Guida AWS PrivateLink*
## Considerazioni
+ **Supporto e limitazioni**: gli endpoint dell’interfaccia Amazon EKS consentono l’accesso sicuro a tutte le azioni dell’API Amazon EKS dal tuo VPC, ma presentano limitazioni specifiche, ovvero non supportano l’accesso alle API Kubernetes, poiché dispongono di un endpoint privato separato né è possibile configurare Amazon EKS in modo che sia accessibile solo tramite l’endpoint di interfaccia.
+ **Prezzi**: l’utilizzo degli endpoint di interfaccia per Amazon EKS comporta tariffe AWS PrivateLink standard: tariffe orarie per ciascun endpoint fornito in ciascuna zona di disponibilità, costi di elaborazione dei dati per il traffico attraverso l’endpoint. Per ulteriori informazioni, consulta [Prezzi AWS PrivateLink](https://aws.amazon.com/privatelink/pricing/).
+ **Sicurezza e controllo degli accessi**: consigliamo di migliorare la sicurezza e il controllo dell’accesso con queste configurazioni aggiuntive: utilizza le policy degli endpoint VPC per controllare l’accesso ad Amazon EKS tramite l’endpoint dell’interfaccia, associa i gruppi di sicurezza alle interfacce di rete degli endpoint per gestire il traffico, utilizza i log di flusso VPC per acquisire e monitorare il traffico IP da e verso gli endpoint dell’interfaccia, con log pubblicabili su Amazon CloudWatch o Amazon S3. Per ulteriori informazioni, consulta [Controllare l’accesso agli endpoint VPC utilizzando le policy degli endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) e [Registrare il traffico IP utilizzando log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html).
+ **Opzioni di connettività**: gli endpoint di interfaccia offrono opzioni di connettività flessibili utilizzando **l’accesso on-premises** (connetti il data center on-premises a un VPC con l’endpoint dell’interfaccia utilizzando AWS Direct Connect o AWS VPN da sito a sito) o tramite **connettività inter-VPC** (utilizza AWS Transit Gateway o il peering VPC per connettere altri VPC al VPC con l’endpoint di interfaccia, mantenendo il traffico all’interno della rete AWS).
+ **Supporto versione IP**: gli endpoint creati prima di agosto 2024 supportano solo IPv4 utilizzando eks.region.amazonaws.com. I nuovi endpoint creati dopo agosto 2024 supportano IPv4 e IPv6 dual-stack (ad esempio, eks.region.amazonaws.com, eks.region.api.aws).
+ **Disponibilità regionale**: AWS PrivateLink per l’API EKS non è disponibile nelle regioni Asia Pacifico (Malesia) (ap-southeast-5), Asia Pacifico (Thailandia) (ap-southeast-7), Messico (Centrale) (mx-central-1) e Asia Pacifica (Taipei) (ap-east-2). AWS Il supporto PrivateLink per eks-auth (EKS Pod Identity) è disponibile nella regione Asia Pacifico (Malesia) (ap-southeast-5).
## Crea un endpoint di interfaccia per Amazon EKS
È possibile creare un endpoint di interfaccia per Amazon EKS utilizzando la console Amazon VPC o l’interfaccia a riga di comando AWS (AWS CLI). Per ulteriori informazioni, consulta [Creare un endpoint VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) nella *Guida di AWS PrivateLink*.
Crea un endpoint di interfaccia per Amazon EKS utilizzando i seguenti nomi servizio:
### API EKS
+ com.amazonaws.region-code.eks
+ com.amazonaws.region-code.eks-fips (per endpoint conformi a FIPS)
### API di autenticazione EKS (Pod Identity EKS)
+ com.amazonaws.region-code.eks-auth
## Funzionalità DNS privata per gli endpoint dell’interfaccia Amazon EKS
La funzionalità DNS privata, abilitata per impostazione predefinita per gli endpoint di interfaccia di Amazon EKS e altri servizi AWS, facilita le richieste API sicure e private utilizzando nomi DNS regionali predefiniti. Questa funzionalità garantisce che le chiamate API siano instradate attraverso l’endpoint di interfaccia sulla rete AWS privata, migliorando la sicurezza e le prestazioni.
La funzionalità DNS privata si attiva automaticamente quando si crea un endpoint di interfaccia per Amazon EKS o altri servizi AWS. Per abilitarla, devi configurare correttamente il tuo VPC impostando attributi specifici:
+ **enableDnsHostnames**: consente alle istanze all’interno del VPC di avere nomi host DNS.
+ **enableDnsSupport**: abilita la risoluzione DNS in tutto il VPC.
Per istruzioni dettagliate per verificare o modificare queste impostazioni, consulta [Visualizzare e aggiornare gli attributi DNS per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
### Nomi DNS e tipi di indirizzi IP
Con la funzionalità DNS privata abilitata, è possibile utilizzare nomi DNS specifici per connetterti ad Amazon EKS e queste opzioni si evolvono nel tempo:
+ **eks.region.amazonaws.com**: il nome DNS tradizionale, che si risolve solo negli indirizzi IPv4 prima di agosto 2024. Per gli endpoint esistenti aggiornati al dual-stack, questo nome è risolto sia in indirizzi IPv4 che IPv6.
+ **eks.region.api.aws**: disponibile per i nuovi endpoint creati dopo agosto 2024, questo nome DNS dual-stack si risolve in indirizzi IPv4 e IPv6.
Dopo agosto 2024, i nuovi endpoint di interfaccia sono forniti con due nomi DNS ed è possibile optare per il tipo di indirizzo IP dual-stack. Per gli endpoint esistenti, l’aggiornamento a dual-stack modifica **eks.region.amazonaws.com** in modo che supporti sia IPv4 che IPv6.
### Utilizzo della funzionalità DNS privata
Una volta configurata, la funzionalità DNS privata può essere integrata nei flussi di lavoro, offrendo le seguenti funzionalità:
+ **Richieste API**: utilizza i nomi DNS regionali predefiniti, `eks.region.amazonaws.com` o `eks.region.api.aws`, in base alla configurazione dell’endpoint per effettuare richieste API ad Amazon EKS.
+ **Compatibilità delle applicazioni**: le applicazioni esistenti che chiamano le API EKS non richiedono modifiche per sfruttare questa funzionalità.
+ **AWS CLI con Dual-Stack**: per utilizzare gli endpoint dual-stack con AWS CLI, consulta la configurazione degli [endpoint Dual-stack e FIPS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) nella *Guida di riferimento agli SDK e agli strumenti AWS*.
+ **Routing automatico**: qualsiasi chiamata all’endpoint del servizio predefinito di Amazon EKS è instradata automaticamente tramite l’endpoint di interfaccia, garantendo una connettività privata e sicura.
# Comprendere la resilienza nei cluster Amazon EKS
L'infrastruttura globale di AWS è basata su Regioni e zone di disponibilità AWS. Le Regioni AWS forniscono più zone di disponibilità fisicamente separate e isolate che sono connesse tramite reti altamente ridondanti, a bassa latenza e con throughput elevato. Con le zone di disponibilità, è possibile progettare e gestire applicazioni e database che eseguono il failover automatico tra zone di disponibilità senza interruzioni. Le zone di disponibilità sono più disponibili, fault tolerant e scalabili rispetto alle infrastrutture a data center singolo o multiplo.
Amazon EKS esegue ed effettua il dimensionamento di istanze del piano di controllo Kubernetes in molteplici zone di disponibilità AWS per garantire un'elevata disponibilità. Amazon EKS dimensiona automaticamente le istanze del piano di controllo in base al carico, rileva e sostituisce le istanze del piano di controllo non integre e fornisce loro le patch automaticamente. Dopo aver avviato un aggiornamento della versione, Amazon EKS aggiorna il piano di controllo per conto dell’utente, mantenendone un'elevata disponibilità durante l'aggiornamento.
Questo piano di controllo (control-plane) è costituito da almeno due istanze del server API e tre istanze `etcd` eseguite su tre zone di disponibilità all’interno di una Regione AWS. Amazon EKS:
+ Monitora attivamente il carico sulle istanze del piano di controllo e le ridimensiona automaticamente per garantire prestazioni elevate.
+ Rileva e sostituisce automaticamente le istanze del piano di controllo (control-plane) non integre, riavviandole nelle zone di disponibilità all’interno della Regione AWS in base alle esigenze.
+ Sfrutta l'architettura delle Regioni AWS al fine di mantenere elevata disponibilità. Per questo motivo, Amazon EKS è in grado di offrire un [SLA per la disponibilità dell'endpoint del server API](https://aws.amazon.com/eks/sla).
Per ulteriori informazioni sulle regioni e le zone di disponibilità AWS, consultare [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
# Prevenzione del problema “confused deputy” tra servizi in Amazon EKS
Con “confused deputy” si intende un problema di sicurezza in cui un’entità che non dispone dell’autorizzazione per eseguire una certa operazione può costringere un’entità con più privilegi a eseguire tale operazione. Nel AWS, l'impersonificazione tra servizi può portare al confuso problema del vice. La rappresentazione tra servizi può verificarsi quando un servizio (il *servizio chiamante*) effettua una chiamata a un altro servizio (il *servizio chiamato*). Il servizio chiamante può essere manipolato per utilizzare le proprie autorizzazioni e agire sulle risorse di un altro cliente, a cui normalmente non avrebbe accesso. Per evitare che ciò accada, AWS mette a disposizione strumenti che consentono di proteggere i dati relativi a tutti i servizi, con responsabili del servizio a cui è stato concesso l'accesso alle risorse del vostro account.
Consigliamo di utilizzare le chiavi di contesto delle condizioni globali [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) e [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) nelle policy delle risorse per limitare le autorizzazioni con cui Amazon Elastic Kubernetes Service (Amazon EKS) fornisce un altro servizio alla risorsa.
`aws:SourceArn`
Utilizza `aws:SourceArn` per associare una sola risorsa all'accesso tra servizi.
`aws:SourceAccount`
Utilizza `aws:SourceAccount` se desideri consentire l'associazione di qualsiasi risorsa in tale account all'uso tra servizi.
Il modo più efficace per proteggersi dal problema "confused deputy" è quello di usare la chiave di contesto della condizione globale `aws:SourceArn` con l’ARN completo della risorsa. Se l’ARN completo della risorsa non è noto o si scelgono più risorse, utilizzare la chiave di contesto della condizione globale `aws:SourceArn` con caratteri jolly (\$1) per le parti sconosciute dell’ARN. Ad esempio, ` arn:aws::*:<123456789012>:*`.
Se il valore `aws:SourceArn` non contiene l'ID account, ad esempio un ARN di un bucket Amazon S3, è necessario utilizzare sia `aws:SourceAccount` che `aws:SourceArn` per limitare le autorizzazioni.
## Prevenzione del problema “confused deputy” tra servizi nei cluster Amazon EKS
Ѐ richiesto un ruolo IAM del cluster Amazon EKS per ogni cluster. I cluster Kubernetes gestiti da Amazon EKS utilizzano questo ruolo per gestire i nodi e il [provider cloud legacy](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) utilizza questo ruolo per creare bilanciatori del carico con Elastic Load Balancing per i servizi. Queste operazioni del cluster possono influire solo sullo stesso account, quindi consigliamo di limitare ogni ruolo del cluster a quel cluster e a quell’account. Questa è un'applicazione specifica della AWS raccomandazione di seguire il *principio del privilegio minimo* nel proprio account.
**Formato dell’ARN dell’origine**
Il valore di `aws:SourceArn` deve essere l’ARN di un cluster EKS nel formato ` arn:aws: eks:region:account:cluster/cluster-name `. Ad esempio, ` arn:aws: eks:us-west-2:123456789012:cluster/my-cluster`.
**Formato della policy di attendibilità per i ruoli del cluster EKS**
L’esempio seguente mostra il modo in cui è possibile utilizzare le chiavi di contesto `aws:SourceArn` e `aws:SourceAccount` delle condizioni globali in Amazon EKS per prevenire il problema “confused deputy”.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
```
# Considerazioni sulla sicurezza per Kubernetes
Di seguito sono riportate alcune considerazioni relative alla sicurezza del cloud, in quanto influiscono su Kubernetes nei cluster Amazon EKS. Per un’analisi approfondita dei controlli e delle pratiche di sicurezza in Kubernetes, consulta [Sicurezza nativa del cloud e Kubernetes](https://kubernetes.io/docs/concepts/security/cloud-native-security/) nella documentazione di Kubernetes.
**Topics**
+ [Proteggere i carichi di lavoro con i certificati Kubernetes](cert-signing.md)
+ [Comprendere ruoli e utenti creati da Amazon EKS tramite RBAC](default-roles-users.md)
+ [Crittografia dei segreti Kubernetes con KMS su cluster esistenti](enable-kms.md)
+ [Utilizzare i segreti di AWS Secrets Manager con i pod di Amazon EKS](manage-secrets.md)
+ [Crittografia a busta predefinita per tutti i dati dell’API Kubernetes](envelope-encryption.md)
# Proteggere i carichi di lavoro con i certificati Kubernetes
L’API Kubernetes Certificates automatizza il provisioning delle credenziali [X.509](https://www.itu.int/rec/T-REC-X.509). L’API presenta un’interfaccia a riga di comando per i client API Kubernetes che consente di richiedere e ottenere i [certificati X.509](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) da parte di un’autorità di certificazione (CA). Puoi utilizzare la risorsa (CSR) `CertificateSigningRequest` per chiedere la firma del certificato da parte di un firmatario designato. Le richieste vengono approvate o negate prima della firma. Kubernetes supporta sia i firmatari integrati che personalizzati con comportamenti ben definiti. In questo modo, i client possono prevedere cosa succede alle loro CSR. Per ulteriori informazioni sulla firma dei certificati, consulta [signing requests](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/).
Uno dei firmatari integrati è `kubernetes.io/legacy-unknown`. L’API `v1beta1` della risorsa CSR ha onorato questo firmatario “legacy-unknown”. Tuttavia, l’API `v1` stabile di CSR non consente l’impostazione di `signerName` su `kubernetes.io/legacy-unknown`.
Se desideri utilizzare l’autorità di certificazione (CA) di Amazon EKS per la generazione di certificati sul tuo cluster, devi utilizzare un firmatario personalizzato. Per utilizzare la versione `v1` dell’API CSR e generare un nuovo certificato, devi eseguire la migrazione di tutti i manifesti e i client dell’API esistenti. I certificati esistenti creati con l’API `v1beta1` esistente sono validi e funzionanti fino alla scadenza dei certificati. Questo include gli output seguenti:
+ Distribuzione di attendibilità: nessuna. Non esiste alcuna distribuzione di attendibilità o standard per questo firmatario in un cluster Kubernetes.
+ Argomenti consentiti: tutti
+ Estensioni x509 consentite: rispetta le estensioni di utilizzo delle chiavi e subjectAltName, scartando le altre.
+ Utilizzo delle chiavi consentite: non devono includere altri utilizzi oltre ["key encipherment", "digital signature", "server auth"]
**Nota**
La firma dei certificati client non è supportata.
+ Scadenza/durata del certificato: 1 anno (predefinita e massima)
+ Bit CA consentito/non consentito: non consentito
## Generazione CSR di esempio con signerName
Questa procedura mostra come generare un certificato di servizio per il nome DNS `myserver.default.svc` utilizzando `signerName: beta.eks.amazonaws.com/app-serving`. Utilizzala come guida per il tuo ambiente.
1. Esegui il comando `openssl genrsa -out myserver.key 2048` per generare una chiave privata RSA.
```
openssl genrsa -out myserver.key 2048
```
1. Utilizza il comando seguente per generare una richiesta di certificato.
```
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"
```
1. Genera un valore `base64` per la richiesta CSR e memorizzalo in una variabile da utilizzare in un passaggio successivo.
```
base_64=$(cat myserver.csr | base64 -w 0 | tr -d "
")
```
1. Per creare un file denominato `mycsr.yaml`, esegui il comando di seguito. Nell’esempio seguente, `beta.eks.amazonaws.com/app-serving` è `signerName`.
```
cat >mycsr.yaml < myserver.crt
```
# Comprendere ruoli e utenti creati da Amazon EKS tramite RBAC
Quando si crea un cluster Kubernetes, su tale cluster vengono create diverse identità Kubernetes predefinite per il corretto funzionamento di Kubernetes. Amazon EKS crea identità Kubernetes per ciascuno dei suoi componenti predefiniti. Le identità offrono un controllo delle autorizzazioni basato sul ruolo (RBAC) Kubernetes per i componenti del cluster. Per ulteriori informazioni, consulta [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) nella documentazione di Kubernetes.
Quando si installano [componenti aggiuntivi](eks-add-ons.md) opzionali nel cluster, è possibile che vengano aggiunte identità Kubernetes supplementari al cluster. Per ulteriori informazioni sulle identità non trattate in questo argomento, consulta la documentazione del componente aggiuntivo.
Puoi visualizzare l'elenco delle identità Kubernetes create da Amazon EKS sul tuo cluster utilizzando lo strumento Console di gestione AWS o `kubectl` la riga di comando. Tutte le identità degli utenti vengono visualizzate nei registri di `kube` controllo disponibili tramite Amazon. CloudWatch
## Console di gestione AWS
### Prerequisito
Il [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) da utilizzare deve disporre delle autorizzazioni descritte alla pagina [Required permissions](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
### Per visualizzare le identità create da Amazon EKS utilizzando Console di gestione AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nell'elenco **Cluster**, seleziona il cluster contenente le identità da visualizzare.
1. Scegli la scheda **Risorse**.
1. In **Resource types** (Tipi di risorse), scegli **Authorization** (Autorizzazione).
1. Scegli, **ClusterRoles**, **ClusterRoleBindings**, **Ruoli** o **RoleBindings**. Tutte le risorse con il prefisso **eks** sono create da Amazon EKS. Le risorse di identità supplementari create da Amazon EKS sono:
+ La band **ClusterRole**si **ClusterRoleBinding**chiama **aws-node**. Le risorse **aws-node** supportano il [plugin CNI di Amazon VPC per Kubernetes](managing-vpc-cni.md), che Amazon EKS installa su tutti i cluster.
+ Un **ClusterRole**nome **vpc-resource-controller-role**e un **ClusterRoleBinding**nome. **vpc-resource-controller-rolebinding** Queste risorse supportano il [Amazon VPC resource controller](https://github.com/aws/amazon-vpc-resource-controller-k8s) (Controller risorse Amazon VPC), che Amazon EKS installa su tutti i cluster.
Oltre alle risorse visualizzate nella console, nel cluster esistono le seguenti identità utente speciali, anche se non sono visibili nella configurazione del cluster:
+ ** `eks:cluster-bootstrap` **: utilizzato per operazioni `kubectl` durante il bootstrap del cluster.
+ ** `eks:support-engineer` **: utilizzato per le operazioni di gestione del cluster.
1. Scegli una risorsa specifica per visualizzarne i dettagli. Per impostazione predefinita, le informazioni sono mostrate in **Vista strutturata**. Nell'angolo superiore destro della pagina dei dettagli puoi scegliere la **Raw view** (Visualizzazione non elaborata) per vedere tutte le informazioni per la risorsa.
## Kubectl
### Prerequisito
L'entità che utilizzi (AWS Identity and Access Management (IAM) o OpenID Connect (OIDC)) per elencare le risorse Kubernetes nel cluster deve essere autenticata da IAM o dal tuo provider di identità OIDC. All’entità devono essere concesse autorizzazioni per utilizzare i verbi Kubernetes `get` e `list` per le risorse `Role`, `ClusterRole`, `RoleBinding` e `ClusterRoleBinding` nel cluster che devono essere utilizzate dall’entità. Per ulteriori informazioni sulla concessione alle entità IAM dell'accesso al tuo cluster, consulta [Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs](grant-k8s-access.md). Per ulteriori informazioni sulla concessione dell’accesso al cluster alle entità autenticate dal gestore OIDC, consultare [Concedere agli utenti l’accesso a Kubernetes con un provider OIDC esterno](authenticate-oidc-identity-provider.md).
### Come visualizzare le identità create da Amazon EKS tramite `kubectl`
Esegui il comando per il tipo di risorsa da visualizzare. Tutte le risorse restituite con il prefisso **eks** sono create da Amazon EKS. Oltre alle risorse restituite nell’output dai comandi, nel cluster esistono le seguenti identità utente speciali, anche se non sono visibili nella configurazione del cluster:
+ ** `eks:cluster-bootstrap` **: utilizzato per operazioni `kubectl` durante il bootstrap del cluster.
+ ** `eks:support-engineer` **: utilizzato per le operazioni di gestione del cluster.
**ClusterRoles**— `ClusterRoles` sono limitati al cluster, quindi qualsiasi autorizzazione concessa a un ruolo si applica alle risorse in qualsiasi spazio dei nomi Kubernetes del cluster.
Il comando seguente restituisce tutti i `ClusterRoles` Kubernetes creati da Amazon EKS nel cluster.
```
kubectl get clusterroles | grep eks
```
Oltre ai `ClusterRoles` restituiti nell'output con prefisso, esistono i seguenti `ClusterRoles`.
+ ** `aws-node` **: questo `ClusterRole` supporta il [plugin CNI di Amazon VPC per Kubernetes](managing-vpc-cni.md), che Amazon EKS installa su tutti i cluster.
+ ** `vpc-resource-controller-role` **: questo `ClusterRole` supporta il [controller di risorse Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), che Amazon EKS installa su tutti i cluster.
Per visualizzare la specifica di a`ClusterRole`, sostituiscila *eks:k8s-metrics* nel comando seguente con una `ClusterRole` restituita nell'output del comando precedente. L'esempio seguente restituisce la specifica per *eks:k8s-metrics*`ClusterRole`.
```
kubectl describe clusterrole eks:k8s-metrics
```
Di seguito viene riportato un output di esempio.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
[/metrics] [] [get]
endpoints [] [] [list]
nodes [] [] [list]
pods [] [] [list]
deployments.apps [] [] [list]
```
**ClusterRoleBindings**— `ClusterRoleBindings` rientrano nell'ambito del cluster.
Il comando seguente restituisce tutti i `ClusterRoleBindings` Kubernetes creati da Amazon EKS nel cluster.
```
kubectl get clusterrolebindings | grep eks
```
Oltre ai `ClusterRoleBindings` restituiti nell'output, esistono i seguenti `ClusterRoleBindings`.
+ ** `aws-node` **: questo `ClusterRoleBinding` supporta il [plugin CNI di Amazon VPC per Kubernetes](managing-vpc-cni.md), che Amazon EKS installa su tutti i cluster.
+ ** `vpc-resource-controller-rolebinding` **: questo `ClusterRoleBinding` supporta il [controller di risorse Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), che Amazon EKS installa su tutti i cluster.
Per visualizzare la specifica di a`ClusterRoleBinding`, sostituiscila *eks:k8s-metrics* nel comando seguente con una `ClusterRoleBinding` restituita nell'output del comando precedente. L'esempio seguente restituisce la specifica per *eks:k8s-metrics*`ClusterRoleBinding`.
```
kubectl describe clusterrolebinding eks:k8s-metrics
```
Di seguito viene riportato un output di esempio.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: ClusterRole
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
**Roles**: i `Roles` sono racchiusi in un namespace Kubernetes. Tutti i `Roles` creati da Amazon EKS rientrano nell'ambito dello spazio nomi `kube-system`.
Il comando seguente restituisce tutti i `Roles` Kubernetes creati da Amazon EKS nel cluster.
```
kubectl get roles -n kube-system | grep eks
```
Per visualizzare la specifica di a`Role`, sostituiscila *eks:k8s-metrics* nel comando seguente con il nome di a `Role` restituito nell'output del comando precedente. L'esempio seguente restituisce la specifica per *eks:k8s-metrics*`Role`.
```
kubectl describe role eks:k8s-metrics -n kube-system
```
Di seguito viene riportato un output di esempio.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
daemonsets.apps [] [aws-node] [get]
deployments.apps [] [vpc-resource-controller] [get]
```
**RoleBindings**— `RoleBindings` sono riconducibili a uno spazio dei nomi Kubernetes. Tutti i `RoleBindings` creati da Amazon EKS rientrano nell'ambito dello spazio nomi `kube-system`.
Il comando seguente restituisce tutti i `RoleBindings` Kubernetes creati da Amazon EKS nel cluster.
```
kubectl get rolebindings -n kube-system | grep eks
```
Per visualizzare le specifiche di a`RoleBinding`, sostituiscilo *eks:k8s-metrics* nel comando seguente con un valore `RoleBinding` restituito nell'output del comando precedente. L'esempio seguente restituisce la specifica per *eks:k8s-metrics*`RoleBinding`.
```
kubectl describe rolebinding eks:k8s-metrics -n kube-system
```
Di seguito viene riportato un output di esempio.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: Role
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
# Crittografia dei segreti Kubernetes con KMS su cluster esistenti
**Importante**
Questa procedura si applica solo a cluster EKS che eseguono la versione 1.27 o precedente di Kubernetes. Se si esegue la versione 1.28 o successiva di Kubernetes, i segreti Kubernetes sono protetti con crittografia a busta per impostazione predefinita. Per ulteriori informazioni, consulta [Crittografia a busta predefinita per tutti i dati dell’API Kubernetes](envelope-encryption.md).
Se [abiliti la crittografia dei segreti](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/), i segreti Kubernetes vengono crittografati utilizzando la chiave KMS selezionata. AWS La chiave KMS deve soddisfare le condizioni seguenti:
+ Simmetria
+ Possibilità di crittografia e decrittografia dei dati
+ Creato nella stessa regione del cluster AWS
+ Se la chiave KMS è stata creata in un account diverso, il [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) dovrà avere accesso alla stessa.
Per ulteriori informazioni, consulta [Consentire ai responsabili IAM di altri account di utilizzare una chiave KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) nella Key *[Management Service Developer](https://docs.aws.amazon.com/kms/latest/developerguide/)* Guide.AWS
**avvertimento**
Non è possibile disabilitare la crittografia dei segreti dopo averla abilitata. Questa operazione è irreversibile.
eksctl
Questa procedura si applica solo a cluster EKS che eseguono la versione 1.27 o precedente di Kubernetes. Per ulteriori informazioni, consulta [Crittografia a busta predefinita per tutti i dati dell’API Kubernetes](envelope-encryption.md).
È possibile abilitare la crittografia in due modi:
+ Aggiungere la crittografia al cluster con un singolo comando.
Per ricrittografare automaticamente i segreti, esegui il comando seguente.
```
eksctl utils enable-secrets-encryption \
--cluster my-cluster \
--key-arn arn:aws: kms:region-code:account:key/key
```
Per disattivare la ricrittografia automatica dei segreti, esegui il comando seguente.
```
eksctl utils enable-secrets-encryption
--cluster my-cluster \
--key-arn arn:aws: kms:region-code:account:key/key \
--encrypt-existing-secrets=false
```
+ Aggiungi la crittografia al cluster con un file `kms-cluster.yaml`.
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
secretsEncryption:
keyARN: arn:aws: kms:region-code:account:key/key
```
Per ricrittografare automaticamente i segreti, esegui il comando seguente.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml
```
Per disattivare la ricrittografia automatica dei segreti, esegui il comando seguente.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false
```
Console di gestione AWS
1. Questa procedura si applica solo a cluster EKS che eseguono la versione 1.27 o precedente di Kubernetes. Per ulteriori informazioni, consulta [Crittografia a busta predefinita per tutti i dati dell’API Kubernetes](envelope-encryption.md).
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il cluster a cui aggiungere la crittografia KMS.
1. Scegli la scheda **Overview** (Panoramica) (selezionata per impostazione predefinita).
1. Scorri verso il basso fino a **Secrets encryption** (Crittografia dei segreti) e scegli **Enable** (Abilita).
1. Seleziona una chiave nell'elenco a discesa e fare clic sul pulsante **Enable** (Abilita). Se non sono elencate chiavi, è necessario crearne una prima. Per ulteriori informazioni, consultare [Creazione chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)
1. Fai clic sul pulsante **Confirm** (Conferma) per utilizzare la chiave scelta.
AWS CLI
1. Questa procedura si applica solo a cluster EKS che eseguono la versione 1.27 o precedente di Kubernetes. Per ulteriori informazioni, consulta [Crittografia a busta predefinita per tutti i dati dell’API Kubernetes](envelope-encryption.md).
1. Associa la configurazione di [crittografia segreta](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) al tuo cluster utilizzando il seguente AWS comando CLI. Sostituire i valori di esempio con i propri valori.
```
aws eks associate-encryption-config \
--cluster-name my-cluster \
--encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws: kms:region-code:account:key/key"}}]'
```
Di seguito viene riportato un output di esempio.
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "InProgress",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws: kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734,
"errors": []
}
}
```
1. È possibile monitorare lo stato dell'aggiornamento di crittografia con il comando seguente. Usa il `cluster name` specifico e il valore `update ID` restituito nell'output precedente. Quando viene visualizzato lo stato `Successful`, l'aggiornamento è completo.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id 3141b835-8103-423a-8e68-12c2521ffa4d
```
Di seguito viene riportato un output di esempio:
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "Successful",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws: kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734>,
"errors": []
}
}
```
1. Per verificare che la crittografia sia attivata nel cluster, eseguire il comando `describe-cluster`. La risposta contiene una stringa `EncryptionConfig`.
```
aws eks describe-cluster --region region-code --name my-cluster
```
Dopo aver abilitato la crittografia nel cluster, sarà necessario crittografare tutti i segreti esistenti con la nuova chiave:
**Nota**
È necessario eseguire il comando seguente soltanto se si utilizza `eksctl` e la crittografia automatica dei segreti è disattivata.
```
kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value"
```
**avvertimento**
Se si abilita la [crittografia dei segreti](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) per un cluster esistente e la chiave KMS utilizzata non viene mai eliminata, non sarà possibile ripristinare il cluster. L'eliminazione della chiave KMS metterà definitivamente il cluster in uno stato degradato. Per ulteriori informazioni, consulta [Eliminazione delle chiavi AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html).
**Nota**
Per impostazione predefinita, il `create-key` comando crea una chiave [KMS di crittografia simmetrica con una politica chiave](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html) che fornisce all'amministratore principale dell'account l'accesso alle azioni e alle AWS risorse KMS. Se si desidera ridurre l'ambito delle autorizzazioni, assicurarsi che le azioni `kms:DescribeKey` e `kms:CreateGrant` siano consentite nella policy per il principale che effettua la chiamata all'API `create-cluster`.
Per cluster che utilizzano la crittografia a busta KMS, sono necessarie le autorizzazioni `kms:CreateGrant`. La condizione non `kms:GrantIsForAWSResource` è supportata per l' CreateCluster azione e non deve essere utilizzata nelle politiche KMS per controllare `kms:CreateGrant` le autorizzazioni degli utenti che eseguono. CreateCluster
# Utilizzare i segreti di AWS Secrets Manager con i pod di Amazon EKS
Per mostrare i segreti di Secrets Manager e i parametri dall’archivio parametri come file montati in pod di Amazon EKS, è possibile utilizzare AWS Secrets e Configuration Provider (ASCP) per il [driver CSI Kubernetes Secrets Store](https://secrets-store-csi-driver.sigs.k8s.io/).
Con ASCP, è possibile archiviare e gestire i segreti in Secrets Manager e recuperarli tramite i carichi di lavoro in esecuzione su Amazon EKS. È possibile utilizzare i ruoli e i criteri IAM per limitare l’accesso ai propri segreti a specifici pod Kubernetes in un cluster. ASCP recupera la Pod identity e scambia l’identità per un ruolo IAM. ASCP assume il ruolo IAM del pod e quindi può recuperare i segreti da Secrets Manager autorizzati per tale ruolo.
Se si utilizza la rotazione automatica di Secrets Manager per i propri segreti, è anche possibile utilizzare la funzione di rotation reconciler del Driver CSI di Secrets Store, per assicurarsi di recuperare il segreto più recente da Secrets Manager.
**Nota**
I gruppi di nodi AWS Fargate (Fargate) non sono supportati.
Per ulteriori informazioni, consulta [Rotazione dei segreti di Secrets Manager in Amazon EKS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html) nella AWS Guida per l’utente di Secrets Manager.
# Crittografia a busta predefinita per tutti i dati dell’API Kubernetes
Amazon Elastic Kubernetes Service (Amazon EKS) fornisce la crittografia a busta predefinita di tutti i dati dell’API Kubernetes per i cluster EKS che eseguono Kubernetes versione 1.28 o successiva.
La crittografia a busta protegge i dati archiviati con il server API Kubernetes. Ad esempio, la crittografia a busta si applica alla configurazione del cluster Kubernetes, ad esempio. `ConfigMaps` La crittografia a busta non si applica ai dati sui nodi o sui volumi EBS. EKS in precedenza supportava la crittografia dei segreti Kubernetes, mentre ora la crittografia a busta si estende a tutti i dati dell’API Kubernetes.
Ciò fornisce un'esperienza gestita e predefinita che implementa defense-in-depth le tue applicazioni Kubernetes e non richiede alcuna azione da parte tua.
Amazon EKS utilizza AWS [Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) con il [provider Kubernetes KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#configuring-the-kms-provider-kms-v2) per questo ulteriore livello di sicurezza con una chiave di [proprietà di Amazon Web Services e la possibilità di portare la propria chiave](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) [gestita dal cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (CMK) da KMS. AWS
## Comprensione della crittografia a busta
La crittografia delle buste è il processo di crittografia dei dati in testo semplice con una chiave di crittografia dei dati (DEK) prima che vengano inviati al datastore (etcd) e quindi di crittografia del DEK con una chiave KMS principale archiviata in un sistema KMS (AWS KMS) remoto e gestito centralmente. Questa è una defense-in-depth strategia perché protegge i dati con una chiave di crittografia (DEK) e quindi aggiunge un altro livello di sicurezza proteggendo tale DEK con una chiave di crittografia separata e archiviata in modo sicuro chiamata chiave di crittografia (KEK).
## In che modo Amazon EKS abilita la crittografia predefinita delle buste con KMS v2 e KMS AWS
Amazon EKS utilizza [KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#kms-v2) per implementare la crittografia a busta predefinita per tutti i dati dell’API nel piano di controllo (control-plane) Kubernetes gestito prima che vengano conservati nel database [etcd](https://etcd.io/docs/v3.5/faq/). All’avvio, il server API del cluster genera una chiave di crittografia dei dati (DEK) da un seed segreto combinato con dati generati casualmente. Inoltre, all'avvio, il server API effettua una chiamata al plug-in KMS per crittografare il seme DEK utilizzando una chiave di crittografia a chiave remota (KEK) di KMS. AWS Si tratta di una chiamata una tantum eseguita all’avvio del server API e durante la rotazione KEK. Il server API memorizza quindi nella cache il seed della DEK crittografato. Successivamente, il server API utilizza il seed DEK memorizzato nella cache per generarne un altro monouso DEKs basato su una Key Derivation Function (KDF). Ciascuno di questi dati generati DEKs viene quindi utilizzato una sola volta per crittografare una singola risorsa Kubernetes prima che venga archiviata in etcd. Con l’uso di un seed della DEK crittografato e memorizzato nella cache in KMS v2, il processo di crittografia delle risorse Kubernetes nel server API è sia più performante che conveniente.
**Per impostazione predefinita, questa KEK è di proprietà di AWS, ma puoi opzionalmente importare la tua da KMS. AWS **
Il diagramma riportato di seguito mostra la generazione e la crittografia di una DEK all’avvio del server API.
![\[Il diagramma mostra la generazione e la crittografia di una DEK all’avvio del server API\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/security-generate-dek.png)
Il diagramma di alto livello riportato di seguito mostra la crittografia di una risorsa Kubernetes prima che venga archiviata in etcd.
![\[Il diagramma di alto livello mostra la crittografia di una risorsa Kubernetes prima che venga archiviata in etcd.\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/security-encrypt-request.png)
## Domande frequenti
### In che modo la crittografia a busta predefinita migliora il livello di sicurezza del mio cluster EKS?
Questa funzionalità riduce la superficie e il periodo di tempo in cui i metadati e i contenuti dei clienti non vengono crittografati. Con la crittografia a busta predefinita, i metadati e i contenuti dei clienti sono solo temporaneamente non crittografati nella memoria di kube-apiserver prima di essere archiviati in etcd. [La memoria del kube-apiserver è protetta tramite il sistema Nitro.](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html) Amazon EKS utilizza solo [istanze EC2 basate su Nitro](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html) per il piano di controllo (control-plane) Kubernetes gestito. Queste istanze hanno un design di controllo di sicurezza che impediscono a qualsiasi sistema o persona di accedere alla memoria.
### Quale versione di Kubernetes devo eseguire per avere questa funzionalità?
Per abilitare la crittografia a busta predefinita, il cluster Amazon EKS deve eseguire Kubernetes versione 1.28 o successiva.
### I miei dati sono comunque sicuri se utilizzo una versione del cluster Kubernetes che non supporta questa funzionalità?
Sì. [In, la sicurezza è la nostra massima priorità. AWS](https://aws.amazon.com/security/) Basiamo tutta la nostra trasformazione e innovazione digitale sulle pratiche operative di sicurezza più elevate e restiamo impegnati a innalzare tale livello.
Tutti i dati archiviati in etcd sono crittografati a livello di disco per ogni cluster EKS, indipendentemente dalla versione di Kubernetes in esecuzione. EKS utilizza chiavi root che generano chiavi di crittografia del volume gestite dal servizio EKS. Inoltre, ogni cluster Amazon EKS viene eseguito in un VPC isolato utilizzando macchine virtuali specifiche del cluster. Grazie a questa architettura e alle nostre pratiche in materia di sicurezza operativa, Amazon EKS ha [ottenuto diversi livelli e standard di conformità](https://docs.aws.amazon.com/eks/latest/userguide/compliance.html), tra cui l’idoneità SOC 1,2,3, PCI-DSS, ISO e HIPAA. Questi livelli e standard di conformità vengono mantenuti per tutti i cluster EKS con o senza crittografia a busta predefinita.
### Come funziona la crittografia a busta in Amazon EKS?
All’avvio, il server API del cluster genera una chiave di crittografia dei dati (DEK) da un seed segreto combinato con dati generati casualmente. Inoltre, all'avvio, il server API effettua una chiamata al plug-in KMS per crittografare il DEK utilizzando una chiave di crittografia a chiave remota (KEK) di KMS. AWS Si tratta di una chiamata una tantum eseguita all’avvio del server API e durante la rotazione KEK. Il server API memorizza quindi nella cache il seed della DEK crittografato. Successivamente, il server API utilizza il seed DEK memorizzato nella cache per generare un altro codice singolo DEKs basato su una Key Derivation Function (KDF). Ciascuno di questi dati generati DEKs viene quindi utilizzato una sola volta per crittografare una singola risorsa Kubernetes prima che venga archiviata in etcd.
È importante notare che sono state effettuate chiamate aggiuntive dal server API per verificare lo stato e la normale funzionalità dell'integrazione KMS. AWS Questi controlli sanitari aggiuntivi sono visibili nel tuo AWS CloudTrail.
### Devo fare qualcosa o modificare le autorizzazioni affinché questa funzionalità sia abilitata nel mio cluster EKS?
Non è necessario eseguire alcuna operazione. La crittografia a busta in Amazon EKS è ora una configurazione predefinita abilitata in tutti i cluster che eseguono Kubernetes versione 1.28 o successiva. L'integrazione AWS KMS è stabilita dal server API Kubernetes gestito da. AWS Ciò significa che non è necessario configurare alcuna autorizzazione per iniziare a utilizzare la crittografia KMS per il cluster.
### Come posso sapere se la crittografia a busta predefinita è abilitata sul mio cluster?
Se esegui la migrazione per utilizzare la tua CMK, puoi visualizzare l’ARN della chiave KMS associata al tuo cluster. Inoltre, puoi visualizzare i registri degli AWS CloudTrail eventi associati all'uso della CMK del tuo cluster.
Se il cluster utilizza una chiave AWS di proprietà, questa verrà descritta in dettaglio nella console EKS (escluso l'ARN della chiave).
### È possibile AWS accedere alla chiave AWS di proprietà utilizzata per la crittografia predefinita delle buste in Amazon EKS?
No. AWS dispone di rigorosi controlli di sicurezza in Amazon EKS che impediscono a chiunque di accedere a qualsiasi chiave di crittografia in testo semplice utilizzata per proteggere i dati nel database etcd. Queste misure di sicurezza vengono applicate anche alla chiave KMS proprietaria. AWS
### La crittografia a busta predefinita è abilitata nel mio cluster EKS esistente?
Se esegui il cluster Amazon EKS con Kubernetes versione 1.28 o successiva, la crittografia a busta predefinita di tutti i dati dell’API Kubernetes è abilitata. Per i cluster esistenti, Amazon EKS utilizza l'`eks:kms-storage-migrator`RBAC ClusterRole per migrare dati che in precedenza non erano crittografati in busta in etcd verso questo nuovo stato di crittografia.
### Cosa significa se ho già abilitato la crittografia a busta per i segreti nel mio cluster EKS?
Se disponi di una chiave gestita dal cliente (CMK) in KMS che è stata utilizzata per crittografare a busta i tuoi segreti Kubernetes, quella stessa chiave verrà utilizzata come KEK per la crittografia a busta di tutti i tipi di dati dell’API Kubernetes nel cluster.
### La gestione di un cluster EKS con crittografia a busta predefinita comporta costi aggiuntivi?
Non ci sono costi aggiuntivi associati al piano di controllo (control-plane) Kubernetes gestito se utilizzi una [chiave di proprietà di Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) per la crittografia a busta predefinita. Per impostazione predefinita, ogni cluster EKS che esegue Kubernetes versione 1.28 o successiva utilizza una [chiave di proprietà di Amazon Web Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk). [Tuttavia, se utilizzi la tua chiave KMS, verranno applicati i AWS normali prezzi KMS.](https://aws.amazon.com/kms/pricing/)
### Quanto costa utilizzare la mia chiave AWS KMS per crittografare i dati dell'API Kubernetes nel mio cluster?
Paghi 1 USD al mese per archiviare qualsiasi chiave personalizzata creata o importata in KMS. Addebiti KMS per le richieste di crittografia e decrittografia. È disponibile un piano gratuito di 20.000 richieste al mese per account e paghi 0,03 USD per 10.000 richieste superiori al piano gratuito al mese. Questo vale per tutti gli utilizzi del KMS per un account, quindi il costo dell'utilizzo della tua chiave AWS KMS sul cluster sarà influenzato dall'utilizzo di questa chiave su altri cluster o risorse all'interno del tuo account. AWS
### Gli addebiti di KMS saranno più alti ora che la mia chiave gestita dal cliente (CMK) viene utilizzata per crittografare a busta tutti i dati dell’API Kubernetes oltre ai segreti?
No. La nostra implementazione con KMS v2 riduce significativamente il numero di chiamate effettuate a AWS KMS. Ciò a sua volta ridurrà i costi associati alla CMK indipendentemente dal fatto che i dati Kubernetes aggiuntivi vengano crittografati o decrittografati nel cluster EKS.
Come spiegato in precedenza, il seed della DEK generato utilizzato per la crittografia delle risorse Kubernetes viene archiviato localmente nella cache del server API Kubernetes dopo essere stato crittografato con la KEK remota. Se il seed DEK crittografato non si trova nella cache del server API, il server API chiamerà AWS KMS per crittografare il seme DEK. Il server API memorizza quindi nella cache il seed della DEK crittografato per utilizzi futuri nel cluster senza chiamare KMS. Allo stesso modo, per le richieste di decrittografia, il server API chiamerà AWS KMS per la prima richiesta di decrittografia, dopodiché il seme DEK decrittografato verrà memorizzato nella cache e utilizzato per future operazioni di decrittografia.
[Per ulteriori informazioni, consulta KEP-3299: KMS v2 Improvements in the Kubernetes Enhancements on.](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements) GitHub
### Posso utilizzare la stessa chiave CMK per più cluster Amazon EKS?
Sì. Per utilizzare nuovamente una chiave, puoi collegarla a un cluster nella stessa regione associando l’ARN al cluster durante la creazione. Tuttavia, se utilizzi la stessa CMK per più cluster EKS, devi adottare le misure necessarie per impedire la disabilitazione arbitraria della CMK. In caso contrario, una CMK disabilitata associata a più cluster EKS avrà un ambito di impatto più ampio sui cluster a seconda di tale chiave.
### Cosa succede al mio cluster EKS se la mia CMK non è più disponibile dopo aver abilitato la crittografia a busta predefinita?
Se disabiliti una chiave KMS, non può essere utilizzata in nessuna [operazione di crittografia](https://docs.aws.amazon.com/kms/latest/developerguide/kms-cryptography.html#cryptographic-operations)riabiliti. Senza l’accesso a una CMK esistente, il server API non sarà in grado di crittografare e rendere persistenti gli oggetti Kubernetes appena creati, nonché di decrittografare qualsiasi oggetto Kubernetes precedentemente crittografato archiviato in etcd. [Se la CMK è disabilitata, il cluster verrà immediatamente messo in unhealthy/degraded uno stato, a quel punto non saremo in grado di adempiere al nostro impegno di servizio finché non riabiliterai la CMK associata.](https://aws.amazon.com/eks/sla/)
Quando una CMK è disabilitata, riceverai notifiche sullo stato di degrado del tuo cluster EKS e sulla necessità di abilitare nuovamente la CMK entro 30 giorni dalla sua disabilitazione per garantire il corretto ripristino delle risorse del piano di controllo (control-plane) Kubernetes.
### Come posso proteggere il mio cluster EKS dall'impatto di una CMK? disabled/deleted
Per proteggere i cluster EKS da tali eventi, gli amministratori della chiave devono gestire l’accesso alle operazioni della chiave KMS utilizzando policy IAM con un principio di privilegio minimo per ridurre il rischio di qualsiasi disabilitazione o eliminazione arbitraria delle chiavi associate ai cluster EKS. Inoltre, puoi impostare un [CloudWatch allarme](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html) per ricevere una notifica sullo stato della tua CMK.
### Il mio cluster EKS verrà ripristinato se abilito nuovamente la CMK?
Per garantire il corretto ripristino del cluster EKS, consigliamo vivamente di abilitare di nuovo la CMK entro i primi 30 giorni dalla sua disabilitazione. Tuttavia, il corretto ripristino del cluster EKS dipenderà anche dal fatto che subisca o meno modifiche sostanziali all'API a causa di un aggiornamento automatico di Kubernetes che può avvenire mentre il cluster è in uno stato. unhealthy/degraded
### Perché il mio cluster EKS è in unhealthy/degraded uno stato dopo aver disabilitato la CMK?
Il server API del piano di controllo EKS utilizza una chiave DEK crittografata e memorizzata nella memoria del server API per crittografare tutti gli oggetti durante le create/update operazioni prima che vengano archiviati in etcd. Quando un oggetto esistente viene recuperato da etcd, il server API utilizza la stessa chiave DEK memorizzata nella cache e decrittografa l’oggetto della risorsa Kubernetes. Se disabiliti la CMK, il server API non avrà alcun impatto immediato a causa della chiave DEK archiviata nella cache nella memoria del server API. Tuttavia, quando l'istanza del server API viene riavviata, non avrà un DEK memorizzato nella cache e dovrà chiamare KMS per le operazioni di crittografia e decrittografia. AWS Senza una CMK, questo processo fallirà con un codice di errore KMS\$1KEY\$1DISABLED, che impedisce il corretto avvio del server API.
### Cosa succede al cluster EKS se elimino la CMK?
L’eliminazione della chiave CMK associata al cluster EKS ne comprometterà lo stato di integrità in modo non ripristinabile. Senza la CMK del cluster, il server API non sarà più in grado di crittografare e rendere persistenti i nuovi oggetti Kubernetes, nonché di decrittografare gli oggetti precedentemente crittografati archiviati nel database etcd. Dovresti procedere con l’eliminazione di una chiave CMK per il cluster EKS solo quando hai la certezza di non dover più utilizzare il cluster EKS.
Tieni presente che se la CMK non viene trovata (KMS\$1KEY\$1NOT\$1FOUND) o le concessioni per la CMK associata al cluster vengono revocate (KMS\$1GRANT\$1REVOKED), il cluster non sarà ripristinabile. Per ulteriori informazioni sullo stato del cluster e sui codici di errore, consulta Integrità del cluster e codici di errore con percorsi di [risoluzione](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html#cluster-health-status). FAQs
### Mi verrà comunque addebitato il costo di un cluster degraded/unhealthy EKS perché ho disabilitato o eliminato la mia CMK?
Sì. Sebbene il piano di controllo EKS non sia utilizzabile in caso di CMK disabilitato, AWS continuerà a utilizzare risorse infrastrutturali dedicate allocate al cluster EKS fino a quando non verrà eliminato dal cliente. Inoltre, il nostro [impegno di servizio](https://aws.amazon.com/eks/sla/) non si applicherà in tali circostanze perché si tratterà di un’operazione volontaria o passiva da parte del cliente che impedisce il normale stato di integrità e il funzionamento del cluster EKS.
### Il mio cluster EKS può essere aggiornato automaticamente quando si trova in unhealthy/degraded uno stato a causa di una CMK disabilitata?
Sì. Tuttavia, se il tuo cluster ha una CMK disabilitata, avrai a disposizione un periodo di 30 giorni per abilitarla nuovamente. In questo periodo di 30 giorni, il cluster Kubernetes non verrà aggiornato automaticamente. Tuttavia, se questo periodo scade e non hai abilitato nuovamente la CMK, il cluster verrà aggiornato automaticamente alla versione successiva (n\$11) con supporto standard, seguendo il ciclo di vita della versione Kubernetes in EKS.
Ti consigliamo vivamente di riattivare rapidamente una CMK disabilitata quando vieni a conoscenza di un cluster interessato. Tieni presente che, sebbene EKS aggiorni automaticamente questi cluster interessati, non è garantito che vengano ripristinati correttamente, soprattutto se il cluster viene sottoposto a più aggiornamenti automatici, poiché ciò potrebbe includere modifiche all’API Kubernetes e comportamenti imprevisti nel processo di bootstrap del server API.
### Posso utilizzare un alias della chiave KMS?
Sì. Amazon EKS [supporta l’utilizzo di alias delle chiavi KMS](https://docs.aws.amazon.com/eks/latest/APIReference/API_EncryptionConfig.html#API_EncryptionConfig_Contents). Un alias è un nome descrittivo per una [chiave Amazon Web Service KMS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys). Ad esempio, un alias ti consente di fare riferimento a una chiave KMS come **my-key** invece di **`1234abcd-12ab-34cd-56ef-1234567890ab`**.
### Posso comunque eseguire il backup e il ripristino delle risorse del cluster utilizzando la mia soluzione di backup Kubernetes?
Sì. Puoi utilizzare una soluzione di backup Kubernetes (come [Velero](https://velero.io/)) per il disaster recovery, la migrazione e la protezione dei dati del cluster Kubernetes. Se esegui una soluzione di backup Kubernetes che accede alle risorse del cluster tramite il server API, tutti i dati recuperati dall’applicazione verranno decrittografati prima di raggiungere il client. Ciò consentirà di ripristinare le risorse del cluster in un altro cluster Kubernetes.
# Considerazioni sulla sicurezza per Amazon EKS Auto Mode
Questo argomento descrive l’architettura di sicurezza, i controlli e le best practice per Amazon EKS Auto Mode. Man mano che le organizzazioni implementano applicazioni containerizzate su scala, mantenere una solida posizione di sicurezza diventa sempre più complesso. EKS Auto Mode implementa controlli di sicurezza automatizzati e si integra con i servizi di sicurezza AWS per aiutarti a proteggere l’infrastruttura, i carichi di lavoro e i dati del cluster. Attraverso funzionalità di sicurezza integrate come la gestione forzata del ciclo di vita dei nodi e l’implementazione automatica delle patch, EKS Auto Mode ti aiuta a rispettare le best practice di sicurezza riducendo al contempo il sovraccarico operativo.
Prima di procedere con questo argomento, assicurati di conoscere i concetti base di EKS Auto Mode e di aver esaminato i prerequisiti per abilitare EKS Auto Mode sui cluster. Per informazioni generali sulla sicurezza di Amazon EKS, consulta [Sicurezza in Amazon EKS](security.md).
Amazon EKS Auto Mode si fonda sulle basi di sicurezza esistenti di Amazon EKS, introducendo al contempo controlli di sicurezza automatizzati aggiuntivi per le istanze gestite EC2.
## Sicurezza e autenticazione delle API
Amazon EKS Auto Mode utilizza meccanismi di sicurezza della piattaforma AWS per proteggere e autenticare le chiamate all’API Amazon EKS.
+ L’accesso all’API Kubernetes è protetto tramite voci di accesso EKS, che si integrano con le identità AWS IAM.
+ Per ulteriori informazioni, consulta [Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS](access-entries.md).
+ I clienti possono implementare un controllo granulare degli accessi all’endpoint dell’API Kubernetes tramite la configurazione delle voci di accesso EKS.
## Sicurezza di rete
Amazon EKS Auto Mode supporta più livelli di sicurezza di rete:
+ **Integrazione con VPC**
+ Funziona all’interno del cloud privato virtuale (VPC) di Amazon
+ Supporta configurazioni VPC personalizzate e layout di sottorete
+ Abilita la rete privata tra i componenti del cluster
+ Per ulteriori informazioni, consulta [Managing security responsibilities for Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/security.html)
+ **Policy di rete**
+ Supporto nativo per le policy di rete di Kubernetes
+ Capacità di definire regole granulari del traffico di rete
+ Per ulteriori informazioni, consulta [Limita il traffico di Pod con le policy di rete di Kubernetes](cni-network-policy.md)
## Sicurezza delle istanze gestite di EC2
Amazon EKS Auto Mode opera su istanze gestite EC2 con i seguenti controlli di sicurezza:
### Sicurezza EC2
+ Le istanze gestite di EC2 mantengono le funzionalità di sicurezza di Amazon EC2.
+ Per ulteriori informazioni sulle istanze gestite da EC2, consulta [Security in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html).
### Gestione del ciclo di vita delle istanze
Le istanze gestite EC2 operate da EKS Auto Mode hanno una durata massima di 21 giorni. Amazon EKS Auto Mode termina automaticamente le istanze che superano questa durata. Questo limite del ciclo di vita aiuta a prevenire variazioni di configurazione e mantiene il livello di sicurezza.
### Protezione dei dati
+ Amazon EC2 Instance Storage è crittografata; questa archiviazione è allegata direttamente all’istanza. Per ulteriori informazioni, consulta [Data protection in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html).
+ Amazon EKS Auto Mode gestisce i volumi collegati alle istanze EC2 al momento della creazione, compresi i volumi root e di dati. EKS Auto Mode non gestisce completamente i volumi EBS creati utilizzando le funzionalità di storage persistente di Kubernetes.
### Gestione delle patch
+ Amazon EKS Auto Mode applica automaticamente le patch alle istanze gestite.
+ Le patch includono:
+ Aggiornamenti del sistema operativo
+ Patch di sicurezza
+ Componenti di Amazon EKS Auto Mode
**Nota**
I clienti hanno la responsabilità di proteggere e aggiornare i carichi di lavoro in esecuzione su queste istanze.
### Controlli sugli accessi
+ L’accesso diretto alle istanze è limitato:
+ L’accesso SSH non è disponibile.
+ L’accesso ad AWS Systems Manager Session Manager (SSM) non è disponibile.
+ Le operazioni di gestione vengono eseguite tramite l’API Amazon EKS e l’API Kubernetes.
## Gestione automatizzata delle risorse
Amazon EKS Auto Mode non gestisce completamente i volumi di Amazon Elastic Block Store (Amazon EBS) creati utilizzando le funzionalità di storage persistente di Kubernetes. Inoltre, EKS Auto Mode non gestisce il bilanciatore del carico elastico (ELB). Amazon EKS Auto Mode automatizza le attività di routine per queste risorse.
### Sicurezza dell’archiviazione
+ AWS consiglia di abilitare la crittografia per i volumi EBS forniti dalle funzionalità di archiviazione persistente di Kubernetes. Per ulteriori informazioni, consulta [Crea una classe di archiviazione](create-storage-class.md).
+ Crittografia inattiva tramite AWS KMS
+ È possibile configurare il proprio account AWS affinché applichi la crittografia alle nuove copie di volumi e snapshot EBS create. Per ulteriori informazioni, consulta [Enable Amazon EBS encryption by default](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) nella Guida per l’utente di Amazon EBS.
+ Per ulteriori informazioni, consulta [Security in Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/security.html).
### Sicurezza del bilanciatore del carico
+ Configurazione automatizzata dei bilanciatori del carico elastico
+ Gestione dei certificati SSL/TLS tramite l’integrazione di Gestione certificati AWS
+ Automazione dei gruppi di sicurezza per il controllo degli accessi al bilanciatore del carico
+ Per ulteriori informazioni, consulta [Security in Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/security.html).
## Best practice di sicurezza
La sezione seguente descrive le best practice di sicurezza per Amazon EKS Auto Mode.
+ Esamina regolarmente le policy IAM AWS e le voci di accesso EKS.
+ Implementa schemi di accesso con privilegi minimi per i carichi di lavoro.
+ Monitora l’attività del cluster tramite AWS CloudTrail e Amazon CloudWatch. Per ulteriori informazioni, consulta [Registra le chiamate API come eventi AWS CloudTrail](logging-using-cloudtrail.md) e [Monitora i dati del cluster con Amazon CloudWatch](cloudwatch.md).
+ Usa AWS Security Hub per la valutazione del livello di sicurezza.
+ Implementa gli standard di sicurezza dei pod appropriati per i carichi di lavoro.
# Considerazioni sulla sicurezza per EKS Capabilities
Questo argomento tratta importanti considerazioni sulla sicurezza per EKS Capabilities, tra cui la configurazione dei ruoli IAM, le autorizzazioni Kubernetes e i modelli architettonici per le implementazioni multi-cluster e la gestione delle risorse tra account. AWS
EKS Capabilities utilizza una combinazione di ruoli IAM, voci di accesso EKS e Kubernetes RBAC per fornire un accesso sicuro ai AWS servizi, alle risorse Kubernetes in cluster e alle integrazioni con Secrets Manager e altri servizi. AWS CodeConnections AWS AWS
## Capacità, ruolo IAM
Quando crei una capacità, fornisci un ruolo di funzionalità IAM che EKS utilizza per eseguire azioni per tuo conto. Questo ruolo deve:
+ Avere lo stesso AWS account del cluster e della risorsa di capacità
+ Adottate una politica di fiducia che consenta al responsabile del `capabilities.eks.amazonaws.com` servizio di assumere il ruolo
+ Disponi delle autorizzazioni IAM appropriate al tipo di funzionalità e al caso d'uso, a seconda delle tue esigenze. Per informazioni dettagliate sulle autorizzazioni IAM richieste, consulta[Connect ai repository Git con AWS CodeConnections](integration-codeconnections.md), e [Gestisci i segreti delle applicazioni con AWS Secrets Manager](integration-secrets-manager.md) [Configurare le autorizzazioni ACK](ack-permissions.md)
È consigliabile considerare l'ambito dei privilegi richiesti per il caso d'uso specifico e concedere solo le autorizzazioni necessarie per soddisfare i requisiti. Ad esempio, quando si utilizza EKS Capability for Kube Resource Orchestrator, potrebbe non essere richiesta alcuna autorizzazione IAM, mentre quando si utilizza EKS Capability for AWS Controllers for Kubernetes è possibile concedere l'accesso completo a uno o più servizi. AWS
**Importante**
Sebbene alcuni casi d'uso possano giustificare l'uso di ampi privilegi amministrativi, segui il principio del privilegio minimo concedendo solo le autorizzazioni IAM minime richieste per il tuo caso d'uso specifico, limitando l'accesso a risorse specifiche utilizzando chiavi ARNs e condizioni anziché utilizzare autorizzazioni wildcard.
Per informazioni dettagliate sulla creazione e configurazione dei ruoli IAM con funzionalità, consulta. [Funzionalità Amazon EKS, ruolo IAM](capability-role.md)
## Voci di accesso EKS
Quando crei una funzionalità con un ruolo IAM, Amazon EKS crea automaticamente una voce di accesso per quel ruolo nel tuo cluster. Questa voce di accesso concede alla funzionalità di base le autorizzazioni Kubernetes per funzionare.
**Nota**
Le voci di accesso vengono create per il cluster in cui viene creata la funzionalità. Per le distribuzioni di Argo CD su cluster remoti, è necessario creare voci di accesso su tali cluster con le autorizzazioni appropriate per consentire alla funzionalità di Argo CD di distribuire e gestire le applicazioni.
La voce di accesso include:
+ Il ruolo di IAM (ARN) come principale
+ Politiche di accesso specifiche per funzionalità che concedono le autorizzazioni Kubernetes di base
+ Ambito appropriato (a livello di cluster o ambito dello spazio dei nomi) in base al tipo di funzionalità
**Nota**
Per Argo CD, le autorizzazioni relative allo spazio dei nomi vengono concesse allo spazio dei nomi specificato nella configurazione delle funzionalità (il valore predefinito è). `argocd`
**Politiche di accesso predefinite per funzionalità**
Ogni tipo di funzionalità concede al ruolo di capacità le autorizzazioni richieste, impostando diverse politiche di accesso predefinite come segue:
**kro**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`(con ambito cluster)
Concede le autorizzazioni per guardare, gestire ResourceGraphDefinitions e creare istanze di risorse personalizzate definite da. RGDs
**ACK**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`(con ambito cluster)
Concede le autorizzazioni per creare, leggere, aggiornare ed eliminare risorse personalizzate ACK in tutti i namespace.
**CD Argo**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`(con ambito cluster)
Concede autorizzazioni a livello di cluster per Argo CD per individuare risorse e gestire oggetti con ambito cluster.
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`(con ambito namespace)
Concede autorizzazioni a livello di namespace per Argo CD per distribuire e gestire applicazioni. Ha come ambito lo spazio dei nomi specificato nella configurazione delle funzionalità (il valore predefinito è). `argocd`
Per informazioni più dettagliate, vedere[Rivedere le autorizzazioni della policy di accesso](access-policy-permissions.md).
## Autorizzazioni Kubernetes aggiuntive
Alcune funzionalità potrebbero richiedere autorizzazioni Kubernetes aggiuntive oltre alle politiche di accesso predefinite. Puoi concedere queste autorizzazioni utilizzando uno dei seguenti metodi:
+ **Criteri di accesso**: Associa criteri gestiti aggiuntivi alla voce di accesso
+ **Kubernetes RBAC**: creazione `Role` di `ClusterRole` associazioni per l'utente Kubernetes della funzionalità
**Autorizzazioni di lettura segrete ACK**
Alcuni controller ACK devono leggere i segreti di Kubernetes per recuperare dati sensibili come le password dei database. I seguenti controller ACK richiedono un accesso segreto in lettura:
+ `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager`
Per concedere autorizzazioni di lettura segrete:
1. Associa la politica di `arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy` accesso alla voce di accesso della funzionalità
1. Estendi la policy a namespace specifici in cui le risorse ACK faranno riferimento ai segreti o concederanno l'accesso a livello di cluster
**Importante**
Le autorizzazioni di lettura segrete sono limitate ai namespace specificati durante l'associazione della politica di immissione degli accessi. Ciò consente di limitare i segreti a cui la funzionalità può accedere.
**o autorizzazioni arbitrarie per le risorse**
kro richiede le autorizzazioni per creare e gestire le risorse definite nel tuo. ResourceGraphDefinitions Per impostazione predefinita, kro può solo guardare e gestire se stesso. RGDs
Per concedere a kro i permessi per creare risorse:
**Opzione 1: Accedere alle politiche di accesso**
Associa politiche di accesso predefinite come `AmazonEKSAdminPolicy` o `AmazonEKSEditPolicy` all'immissione di accesso della funzionalità.
**Opzione 2: Kubernetes RBAC**
Crea un account `ClusterRoleBinding` che conceda all'utente Kubernetes della funzionalità le autorizzazioni necessarie:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kro-cluster-admin
subjects:
- kind: User
name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
```
**Nota**
Il nome utente Kubernetes per kro segue lo schema: `arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO`
Il nome della sessione `/KRO` (in maiuscolo) viene impostato automaticamente dalla funzionalità EKS kro.
## Autorizzazioni IAM richieste per funzionalità
**kro (Kube Resource Orchestrator)**
Non sono richieste autorizzazioni IAM. Puoi creare un ruolo di capacità senza policy allegate. kro richiede solo le autorizzazioni RBAC di Kubernetes.
**ACK AWS (Controller per Kubernetes)**
Richiede le autorizzazioni per gestire le AWS risorse che ACK creerà e gestirà. È necessario definire l'ambito delle autorizzazioni per servizi, azioni e risorse specifici in base alle proprie esigenze. Per informazioni dettagliate sulla configurazione delle autorizzazioni ACK, incluse le migliori pratiche di produzione con IAM Role Selectors, consulta. [Configurare le autorizzazioni ACK](ack-permissions.md)
**CD Argo**
Per impostazione predefinita, non sono richieste autorizzazioni IAM. Potrebbero essere necessarie autorizzazioni opzionali per:
+ AWS Secrets Manager: se si archiviano le credenziali del repository Git in Secrets Manager
+ AWS CodeConnections: Se si utilizza CodeConnections per l'autenticazione del repository Git
+ Amazon ECR: se si utilizzano grafici Helm archiviati in formato OCI in Amazon ECR
## Best practice di sicurezza
### Privilegio minimo IAM
Concedi alle tue risorse funzionali solo le autorizzazioni necessarie per il tuo caso d'uso. Ciò non significa che non sia possibile concedere ampie autorizzazioni amministrative alle proprie funzionalità, se necessario. In questi casi, è necessario gestire l'accesso a tali risorse in modo appropriato.
**Ruoli relativi alle capacità**:
+ **ACK**: Quando possibile, limita le autorizzazioni IAM a AWS servizi e risorse specifici di cui i tuoi team hanno bisogno, in base ai casi d'uso e ai requisiti
+ **Argo CD**: limita l'accesso a specifici repository Git e namespace Kubernetes
+ **kro**: Richiede un ruolo di capacità per la policy di fiducia, ma non sono necessarie autorizzazioni IAM (utilizza solo il cluster RBAC)
**Esempio**: invece`"Resource": "*"`, specifica modelli per risorse o gruppi di risorse specifici.
```
"Resource": [
"arn:aws:s3:::my-app-*",
"arn:aws:rds:us-west-2:111122223333:db:prod-*"
]
```
Utilizza le chiavi delle condizioni IAM per limitare ulteriormente l'accesso:
```
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "production"
}
}
```
Per ulteriori informazioni sulla configurazione IAM, consulta la sezione Considerazioni per ciascuna funzionalità.
### Isolamento dello spazio dei nomi per i segreti di Argo CD
La funzionalità gestita di Argo CD ha accesso a tutti i segreti di Kubernetes all'interno dello spazio dei nomi configurato (impostazione predefinita:). `argocd` Per mantenere una posizione di sicurezza ottimale, segui queste pratiche di isolamento dello spazio dei nomi:
+ Conserva solo i segreti relativi ad Argo CD all'interno dello spazio dei nomi Argo CD
+ Evita di archiviare segreti applicativi non correlati nello stesso spazio dei nomi di Argo CD
+ Utilizzate namespace separati per i segreti delle applicazioni che non sono necessari per le operazioni di Argo CD
Questo isolamento garantisce che l'accesso segreto di Argo CD sia limitato alle sole credenziali necessarie per l'autenticazione del repository Git e altre operazioni specifiche di Argo CD.
### RBAC Kubernetes
Controlla quali utenti e account di servizio possono creare e gestire le risorse funzionali. È consigliabile distribuire le risorse di funzionalità in namespace dedicati con politiche RBAC appropriate.
Esempio: ruolo RBAC per l'utilizzo con ACK, che consente la gestione delle risorse S3 Bucket nel namespace: `app-team`
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ack-s3-manager
namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
resources: ["buckets"]
verbs: ["get", "list", "create", "update", "delete"]
```
### Registrazione di controllo
**CloudTrail**: Tutte le operazioni dell'API EKS Capability (creazione, aggiornamento, eliminazione) vengono registrate. AWS CloudTrail
Abilita la CloudTrail registrazione per tenere traccia di:
+ Chi ha creato o modificato le funzionalità
+ Quando sono cambiate le configurazioni delle funzionalità
+ Quali ruoli di capacità sono in uso
### Accesso alla rete ed endpoint VPC
#### Accesso privato all'API Argo CD
È possibile limitare l'accesso al server API Argo CD associando uno o più endpoint VPC all'endpoint Argo CD ospitato. Ciò consente la connettività privata dall'interno del tuo VPC senza attraversare la rete Internet pubblica. L'endpoint VPC fornisce l'accesso sia all'interfaccia utente web di Argo CD che all'API Argo CD (incluso l'accesso CLI).
**Nota**
Endpoint VPC connessi agli endpoint API Argo CD ospitati (utilizzando le funzionalità eks). *region*.amazonaws.com) non supportano le politiche degli endpoint VPC.
#### Distribuzione su cluster privati
La funzionalità Argo CD può implementare applicazioni su cluster EKS completamente privati, offrendo un vantaggio operativo significativo eliminando la necessità di peering VPC o configurazioni di rete complesse. Tuttavia, nel progettare questa architettura, considerate che Argo CD estrae la configurazione dai repository Git (che possono essere pubblici) e la applica ai vostri cluster privati.
Assicuratevi di:
+ Usa repository Git privati per carichi di lavoro sensibili
+ Implementa controlli di accesso e autenticazione adeguati al repository Git
+ Rivedi e approva le modifiche tramite richieste pull prima dell'unione
+ Prendi in considerazione l'utilizzo delle finestre di sincronizzazione di Argo CD per controllare quando possono avvenire le distribuzioni
+ Monitora i registri di controllo di Argo CD per rilevare eventuali modifiche non autorizzate alla configurazione
### Conformità
Le funzionalità EKS sono completamente gestite e dispongono delle certificazioni di conformità di Amazon EKS.
Per informazioni aggiornate sulla conformità, consulta [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
## Fasi successive
+ [Configurare le autorizzazioni ACK](ack-permissions.md)- Configura le autorizzazioni IAM per ACK
+ [Configura le autorizzazioni kro](kro-permissions.md)- Configura Kubernetes RBAC per kro
+ [Configurare le autorizzazioni di Argo CD](argocd-permissions.md)- Configura l'integrazione di Identity Center per Argo CD
+ [Risoluzione dei problemi delle funzionalità EKS](capabilities-troubleshooting.md)- Risolvi i problemi di sicurezza e autorizzazione
# Identity and Access Management per Amazon EKS
AWS Identity and Access Management (IAM) è AWS un servizio che aiuta un amministratore a controllare in modo sicuro l'accesso alle AWS risorse. Gli amministratori IAM controllano chi è *autenticato* (accesso effettuato) e *autorizzato* (dispone di autorizzazioni) a utilizzare risorse Amazon EKS. IAM è un AWS servizio che puoi utilizzare senza costi aggiuntivi.
## Destinatari
Il modo in cui utilizzi AWS Identity and Access Management (IAM) varia a seconda del lavoro svolto in Amazon EKS.
**Utente del servizio:**: se si utilizza il servizio Amazon EKS per svolgere il proprio lavoro, l'amministratore fornisce le credenziali e le autorizzazioni necessarie. All'aumentare del numero di caratteristiche Amazon EKS utilizzate per il lavoro, potrebbero essere necessarie ulteriori autorizzazioni. La comprensione della gestione dell’accesso consente di richiedere le autorizzazioni corrette all’amministratore. Se non riesci ad accedere a una caratteristica in Amazon EKS, consultare [Risoluzione dei problemi di IAM](security-iam-troubleshoot.md).
**Amministratore del servizio**: se si è responsabile delle risorse Amazon EKS presso la propria azienda, probabilmente si dispone dell’accesso completo a Amazon EKS. Il compito dell’utente è determinare le caratteristiche e le risorse di Amazon EKS a cui gli utenti del servizio devono accedere. Devi quindi inviare le richieste all’amministratore IAM per modificare le autorizzazioni degli utenti del servizio. Esamina le informazioni contenute in questa pagina per comprendere i concetti di base relativi a IAM. Per ulteriori informazioni su come la propria azienda può utilizzare IAM con Amazon EKS, consulta [Funzionamento di Amazon EKS con IAM](security-iam-service-with-iam.md).
**Amministratore IAM**: se si è amministratore IAM, potrebbe essere interessante ottenere informazioni su come scrivere policy per gestire l’accesso ad Amazon EKS. Per visualizzare policy basate su identità Amazon EKS di esempio che possono essere utilizzate in IAM, consulta [Esempi di policy basate su identità Amazon EKS](security-iam-id-based-policy-examples.md).
## Autenticazione con identità
L'autenticazione è il modo in cui accedi AWS utilizzando le tue credenziali di identità. È necessario *autenticarsi* (effettuare l'accesso AWS) come utente root dell' AWS account, come utente IAM o assumendo un ruolo IAM.
Puoi accedere AWS come identità federata utilizzando le credenziali fornite tramite una fonte di identità. AWS Gli utenti di IAM Identity Center (IAM Identity Center), l'autenticazione Single Sign-On della tua azienda e le tue credenziali Google o Facebook sono esempi di identità federate. Se accedi come identità federata, l’amministratore ha configurato in precedenza la federazione delle identità utilizzando i ruoli IAM. Quando accedi AWS utilizzando la federazione, assumi indirettamente un ruolo.
A seconda del tipo di utente, puoi accedere al Console di gestione AWS o al portale di AWS accesso. Per ulteriori informazioni sull'accesso AWS, vedi [Come accedere al tuo AWS account nella](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) *Guida per l'utente di AWS accesso*.
Se accedi a AWS livello di codice, AWS fornisce un kit di sviluppo software (SDK) e un'interfaccia a riga di comando (CLI) per firmare crittograficamente le tue richieste utilizzando le tue credenziali. Se non utilizzi AWS strumenti, devi firmare tu stesso le richieste. Per ulteriori informazioni sull'utilizzo del metodo consigliato per firmare autonomamente le richieste, consulta [Signing AWS API request](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) nella *IAM User Guide*.
A prescindere dal metodo di autenticazione utilizzato, potrebbe essere necessario specificare ulteriori informazioni sulla sicurezza. Ad esempio, ti AWS consiglia di utilizzare l'autenticazione a più fattori (MFA) per aumentare la sicurezza del tuo account. *Per ulteriori informazioni, consulta [Autenticazione a più fattori](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) nella *Guida per l'utente di AWS IAM Identity Center* e [Utilizzo dell'autenticazione a più fattori (MFA) AWS nella](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) Guida per l'utente IAM.*
### AWS account (utente root)
Quando si crea un AWS account, si inizia con un'identità di accesso che ha accesso completo a tutti i AWS servizi e le risorse dell'account. Questa identità è denominata *utente root* dell' AWS account ed è accessibile effettuando l'accesso con l'indirizzo e-mail e la password utilizzati per creare l'account. Si consiglia vivamente di non utilizzare l'utente root per le attività quotidiane. Conserva le credenziali dell’utente root e utilizzale per eseguire le operazioni che solo l’utente root può eseguire. Per un elenco completo delle attività che richiedono l’accesso come utente root, consulta la sezione [Attività che richiedono le credenziali dell’utente root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) nella *Guida per l’utente IAM*.
### Utenti e gruppi IAM
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) è un'identità all'interno del tuo AWS account che dispone di autorizzazioni specifiche per una singola persona o applicazione. Ove possibile, consigliamo di fare affidamento a credenziali temporanee invece di creare utenti IAM con credenziali a lungo termine come le password e le chiavi di accesso. Tuttavia, se si hanno casi d’uso specifici che richiedono credenziali a lungo termine con utenti IAM, si consiglia di ruotare le chiavi di accesso. Per ulteriori informazioni, consulta la pagina [Rotazione periodica delle chiavi di accesso per casi d’uso che richiedono credenziali a lungo termine](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) nella *Guida per l’utente IAM*.
Un [gruppo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) è un’identità che specifica un insieme di utenti IAM. Non è possibile eseguire l'accesso come gruppo. È possibile utilizzare gruppi per specificare le autorizzazioni per più utenti alla volta. I gruppi semplificano la gestione delle autorizzazioni di set di utenti di grandi dimensioni. Ad esempio, potresti avere un gruppo denominato *IAMAdmins*e concedere a quel gruppo le autorizzazioni per amministrare le risorse IAM.
Gli utenti sono diversi dai ruoli. Un utente è associato in modo univoco a una persona o un’applicazione, mentre un ruolo è destinato a essere assunto da chiunque ne abbia bisogno. Gli utenti dispongono di credenziali a lungo termine permanenti, mentre i ruoli forniscono credenziali temporanee. Per ulteriori informazioni, consulta [Quando creare un utente IAM (invece di un ruolo)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) nella *Guida per l'utente IAM*.
### Ruoli IAM
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) è un'identità all'interno del tuo AWS account che dispone di autorizzazioni specifiche. È simile a un utente IAM, ma non è associato a una persona specifica. Puoi assumere temporaneamente un ruolo IAM in Console di gestione AWS [cambiando ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). Puoi assumere un ruolo chiamando un'operazione AWS CLI o AWS API o utilizzando un URL personalizzato. Per ulteriori informazioni sui metodi per l’utilizzo dei ruoli, consulta [Utilizzo di ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) nella *Guida per l’utente IAM*.
I ruoli IAM con credenziali temporanee sono utili nelle seguenti situazioni:
+ **Accesso utente federato** - Per assegnare le autorizzazioni a una identità federata, è possibile creare un ruolo e definire le autorizzazioni per il ruolo. Quando un'identità federata viene autenticata, l'identità viene associata al ruolo e ottiene le autorizzazioni da esso definite. Per ulteriori informazioni sulla federazione dei ruoli, consulta [Creazione di un ruolo per un provider di identità di terza parte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) nella *Guida per l'utente IAM*. Se utilizzi IAM Identity Center, configura un set di autorizzazioni. IAM Identity Center mette in correlazione il set di autorizzazioni con un ruolo in IAM per controllare a cosa possono accedere le identità dopo l’autenticazione. Per informazioni sui set di autorizzazioni, consulta Set di [autorizzazioni nella Guida](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) per l'*utente di AWS IAM Identity Center*.
+ **Autorizzazioni utente IAM temporanee**: un utente IAM o un ruolo può assumere un ruolo IAM per ottenere temporaneamente autorizzazioni diverse per un’attività specifica.
+ **Accesso multi-account**: è possibile utilizzare un ruolo IAM per permettere a un utente (un principale affidabile) con un account diverso di accedere alle risorse nell’account. I ruoli sono lo strumento principale per concedere l’accesso multi-account. Tuttavia, con alcuni AWS servizi, puoi allegare una policy direttamente a una risorsa (anziché utilizzare un ruolo come proxy). Per informazioni sulle differenze tra ruoli e policy basate su risorse per l’accesso multi-account, consulta [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente di IAM*.
+ **Accesso tra servizi**: alcuni AWS servizi utilizzano le funzionalità di altri AWS servizi. Ad esempio, quando effettui una chiamata in un servizio, è normale che quel servizio esegua applicazioni in Amazon EC2 o archivi oggetti in Amazon S3. Un servizio può eseguire questa operazione utilizzando le autorizzazioni dell'entità chiamante, un ruolo di servizio oppure un ruolo collegato al servizio.
+ **Sessioni di accesso inoltrato (FAS)**: quando utilizzi un utente o un ruolo IAM per eseguire azioni AWS, sei considerato un principale. Quando si utilizzano alcuni servizi, è possibile eseguire un’operazione che attiva un’altra operazione in un servizio diverso. FAS utilizza le autorizzazioni del principale che chiama un AWS servizio, in combinazione con il servizio richiedente per effettuare richieste ai AWS servizi a valle. Le richieste FAS vengono effettuate solo quando un servizio riceve una richiesta che richiede interazioni con altri AWS servizi o risorse per essere completata. In questo caso è necessario disporre delle autorizzazioni per eseguire entrambe le azioni. Per i dettagli delle policy relative alle richieste FAS, consulta [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
+ **Ruolo di servizio** - Un ruolo di servizio è un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che un servizio assume per eseguire operazioni per conto dell’utente. Un amministratore IAM può creare, modificare ed eliminare un ruolo di servizio dall’interno di IAM. Per ulteriori informazioni, consulta [Creazione di un ruolo per delegare le autorizzazioni a un AWS servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) nella Guida per l'utente *IAM*.
+ **Ruolo collegato al servizio: un ruolo** collegato al servizio è un tipo di ruolo di servizio collegato a un servizio. AWS Il servizio può assumere il ruolo per eseguire un’operazione per tuo conto. I ruoli collegati al servizio vengono visualizzati nell' AWS account e sono di proprietà del servizio. Un amministratore IAM può visualizzare le autorizzazioni per i ruoli collegati al servizio, ma non modificarle.
+ **Applicazioni in esecuzione su Amazon EC2**: puoi utilizzare un ruolo IAM per gestire le credenziali temporanee per le applicazioni in esecuzione su un' EC2 istanza e che effettuano richieste AWS CLI AWS o API. Questa soluzione è preferibile alla memorizzazione delle chiavi di accesso all'interno dell'istanza. EC2 Per assegnare un AWS ruolo a un' EC2 istanza e renderlo disponibile per tutte le sue applicazioni, create un profilo di istanza collegato all'istanza. Un profilo di istanza contiene il ruolo e consente ai programmi in esecuzione sull' EC2 istanza di ottenere credenziali temporanee. Per ulteriori informazioni, consulta [Usare un ruolo IAM per concedere le autorizzazioni alle applicazioni in esecuzione su EC2 istanze Amazon](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) nella *IAM User Guide*.
Per informazioni sull'utilizzo dei ruoli IAM, consulta [Quando creare un ruolo IAM (invece di un utente)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) nella *Guida per l'utente IAM*.
## Gestione dell'accesso con policy
Puoi controllare l'accesso AWS creando policy e collegandole a AWS identità o risorse. Una policy è un oggetto AWS che, se associato a un'identità o a una risorsa, ne definisce le autorizzazioni. AWS valuta queste politiche quando un principale (utente, utente root o sessione di ruolo) effettua una richiesta. Le autorizzazioni nelle policy determinano l’approvazione o il rifiuto della richiesta. La maggior parte delle politiche viene archiviata AWS come documenti JSON. Per maggiori informazioni sulla struttura e sui contenuti dei documenti delle policy JSON, consulta [Panoramica delle policy JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) nella *Guida per l’utente di IAM*.
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
Per impostazione predefinita, utenti e ruoli non dispongono di autorizzazioni. Per concedere agli utenti l’autorizzazione a eseguire operazioni sulle risorse di cui hanno bisogno, un amministratore IAM può creare policy IAM. L’amministratore può quindi aggiungere le policy IAM ai ruoli e gli utenti possono assumere i ruoli.
Le policy IAM definiscono le autorizzazioni relative a un’operazione, a prescindere dal metodo utilizzato per eseguirla. Ad esempio, supponiamo di disporre di una policy che consente l’operazione `iam:GetRole`. Un utente con tale policy può ottenere informazioni sul ruolo dalla Console di gestione AWS, dalla AWS CLI o dall' AWS API.
### Policy basate sull’identità
Le policy basate sull’identità sono documenti di policy di autorizzazione JSON che è possibile allegare a un’identità (utente, gruppo di utenti o ruolo IAM). Tali policy definiscono le azioni che utenti e ruoli possono eseguire, su quali risorse e in quali condizioni. Per informazioni su come creare una policy basata su identità, consulta [Creazione di policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) nella *Guida per l'utente IAM*.
Le policy basate su identità possono essere ulteriormente classificate come *policy inline* o *policy gestite*. Le policy inline sono integrate direttamente in un singolo utente, gruppo o ruolo. Le politiche gestite sono politiche autonome che puoi allegare a più utenti, gruppi e ruoli nel tuo AWS account. Le politiche gestite includono politiche AWS gestite e politiche gestite dai clienti. Per informazioni su come scegliere tra una policy gestita o una policy inline, consulta [Scelta fra policy gestite e policy inline](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) nella *Guida per l'utente IAM*.
### Policy basate su risorse
Le policy basate su risorse sono documenti di policy JSON che è possibile collegare a una risorsa. Esempi di policy basate sulle risorse sono le *policy di attendibilità dei ruoli* IAM e le *policy di bucket* Amazon S3. Nei servizi che supportano policy basate sulle risorse, gli amministratori dei servizi possono utilizzarli per controllare l’accesso a una risorsa specifica. Quando è collegata a una risorsa, una policy definisce le operazioni che un principale può eseguire su tale risorsa e a quali condizioni. In una policy basata sulle risorse è obbligatorio [specificare un’entità principale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). I principali possono includere account, utenti, ruoli, utenti federati o AWS servizi.
Le policy basate sulle risorse sono policy inline che si trovano in tale servizio. Non puoi utilizzare le policy AWS gestite di IAM in una policy basata sulle risorse.
### Elenchi di controllo degli accessi () ACLs
Le liste di controllo degli accessi (ACLs) controllano quali principali (membri dell'account, utenti o ruoli) dispongono delle autorizzazioni per accedere a una risorsa. ACLs sono simili alle politiche basate sulle risorse, sebbene non utilizzino il formato del documento di policy JSON.
Amazon S3, AWS WAF e Amazon VPC sono esempi di servizi che supportano. ACLs Per ulteriori informazioni ACLs, consulta la [panoramica della lista di controllo degli accessi (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) nella *Amazon Simple Storage Service Developer Guide*.
### Altri tipi di policy
AWS supporta tipi di policy aggiuntivi e meno comuni. Questi tipi di policy possono impostare il numero massimo di autorizzazioni concesse dai più tipi di policy comuni.
+ **Limiti delle autorizzazioni** - Un limite delle autorizzazioni è una funzionalità avanzata nella quale si imposta il numero massimo di autorizzazioni che una policy basata su identità può concedere a un’entità IAM (utente o ruolo IAM). È possibile impostare un limite delle autorizzazioni per un’entità. Le autorizzazioni risultanti sono l’intersezione delle policy basate sull’identità dell’entità e i relativi limiti delle autorizzazioni. Le policy basate su risorse che specificano l'utente o il ruolo nel campo `Principal` sono condizionate dal limite delle autorizzazioni. Un rifiuto esplicito in una qualsiasi di queste policy sostituisce l’autorizzazione. Per maggiori informazioni sui limiti delle autorizzazioni, consulta [Limiti delle autorizzazioni per le entità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) nella *Guida per l’utente di IAM*.
+ Policy **di controllo del servizio (SCPs)**: SCPs sono politiche JSON che specificano le autorizzazioni massime per un'organizzazione o un'unità organizzativa (OU) in Organizations AWS . AWS Organizations è un servizio per il raggruppamento e la gestione centralizzata di più AWS account di proprietà della tua azienda. Se abiliti tutte le funzionalità di un'organizzazione, puoi applicare le politiche di controllo del servizio (SCPs) a uno o tutti i tuoi account. L'SCP limita le autorizzazioni per le entità negli account dei membri, incluso ogni AWS utente root dell'account. Per ulteriori informazioni su Organizations and SCPs, consulta [le politiche di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) nella * AWS Organizations User Guide*.
+ **Policy di sessione** - Le policy di sessione sono policy avanzate che vengono trasmesse come parametro quando si crea in modo programmatico una sessione temporanea per un ruolo o un utente federato. Le autorizzazioni della sessione risultante sono l'intersezione delle policy basate sull'identità del ruolo o dell'utente e le policy di sessione. Le autorizzazioni possono anche provenire da una policy basata su risorse. Un rifiuto esplicito in una qualsiasi di queste policy sostituisce l’autorizzazione. Per ulteriori informazioni, consulta [Policy di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) nella *Guida per l’utente IAM*.
### Più tipi di policy
Quando a una richiesta si applicano più tipi di policy, le autorizzazioni risultanti sono più complicate da comprendere. Per scoprire come si AWS determina se consentire o meno una richiesta quando sono coinvolti più tipi di policy, consulta [Logica di valutazione delle policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) nella *IAM User Guide*.
# Funzionamento di Amazon EKS con IAM
Prima di utilizzare IAM per gestire l'accesso ad Amazon EKS, è necessario comprendere quali funzioni IAM sono disponibili per l'uso con Amazon EKS. Per avere una visione di alto livello di come Amazon EKS e altri AWS servizi funzionano con IAM, consulta [AWS i servizi che funzionano con IAM nella IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) *User Guide*.
**Topics**
+ [Policy basate su identità Amazon EKS](#security-iam-service-with-iam-id-based-policies)
+ [Policy basate sulle risorse Amazon EKS](#security-iam-service-with-iam-resource-based-policies)
+ [Autorizzazione basata su tag Amazon EKS](#security-iam-service-with-iam-tags)
+ [Ruoli IAM di Amazon EKS](#security-iam-service-with-iam-roles)
## Policy basate su identità Amazon EKS
Con le policy basate sull’identità di IAM, è possibile specificare quali operazioni e risorse sono consentite o respinte, nonché le condizioni in base alle quali le operazioni sono consentite o respinte. Amazon EKS supporta specifiche operazioni, risorse e chiavi di condizione. Per informazioni su tutti gli elementi utilizzati in una policy JSON, consultare [Documentazione di riferimento degli elementi delle policy JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) nella *Guida per l'utente di IAM*.
### Azioni
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L'elemento `Action` di una policy JSON descrive le operazioni che è possibile utilizzare per consentire o negare l'accesso in una policy. Le azioni politiche in genere hanno lo stesso nome dell'operazione AWS API associata. Ci sono alcune eccezioni, ad esempio le *operazioni di sola autorizzazione* che non hanno un’operazione API corrispondente. Esistono anche alcune operazioni che richiedono più operazioni in una policy. Queste operazioni aggiuntive sono denominate *operazioni dipendenti*.
Includere le operazioni in una policy per concedere le autorizzazioni per eseguire l'operazione associata.
Le operazioni delle policy in Amazon EKS utilizzano il seguente prefisso prima dell'operazione: `eks:`. Ad esempio, per concedere a qualcuno l'autorizzazione per ottenere le informazioni descrittive su un cluster Amazon EKS, includere l'operazione `DescribeCluster` nella policy. Le istruzioni della policy devono includere un elemento `Action` o `NotAction`.
Per specificare più operazioni in una sola istruzione, separa ciascuna di esse con una virgola come mostrato di seguito:
```
"Action": ["eks:action1", "eks:action2"]
```
È possibile specificare più azioni tramite caratteri jolly (\$1). Ad esempio, per specificare tutte le azioni che iniziano con la parola `Describe`, includi la seguente azione:
```
"Action": "eks:Describe*"
```
Per visualizzare un elenco di operazioni di Amazon EKS, consulta [Operazioni definite da Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) in *Service Authorization Reference*.
### Resources
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento JSON `Resource` della policy specifica l’oggetto o gli oggetti ai quali si applica l’operazione. Le istruzioni devono includere un elemento `Resource` o un elemento `NotResource`. Come best practice, specifica una risorsa utilizzando il suo [nome della risorsa Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). È possibile eseguire questa operazione per operazioni che supportano un tipo di risorsa specifico, note come *autorizzazioni a livello di risorsa*.
Per le azioni che non supportano le autorizzazioni a livello di risorsa, ad esempio le operazioni di elenco, utilizza un carattere jolly (\$1) per indicare che l’istruzione si applica a tutte le risorse.
```
"Resource": "*"
```
La risorsa del cluster Amazon EKS dispone del seguente ARN.
```
arn:aws: eks:region-code:account-id:cluster/cluster-name
```
Per ulteriori informazioni sul formato di ARNs, consulta [Amazon resource names (ARNs) e AWS service namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Ad esempio, per specificare il cluster con il nome *my-cluster* nell'istruzione, utilizzare il seguente ARN:
```
"Resource": "arn:aws: eks:region-code:111122223333:cluster/my-cluster"
```
Per specificare tutti i cluster che appartengono a un account e a una AWS regione specifici, usa il carattere jolly (\$1):
```
"Resource": "arn:aws: eks:region-code:111122223333:cluster/*"
```
Alcune operazioni Amazon EKS, ad esempio quelle utili per la creazione di risorse, non possono essere eseguite su una risorsa specifica. In questi casi, è necessario utilizzare il carattere jolly (\$1).
```
"Resource": "*"
```
*Per visualizzare un elenco dei tipi di risorse Amazon EKS e relativi ARNs, consulta [Resources defined by Amazon Elastic Kubernetes](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-resources-for-iam-policies) Service nel Service Authorization Reference.* Per informazioni sulle operazioni con cui è possibile specificare l'ARN di ogni risorsa, consultare [Operazioni definite da Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
### Chiavi di condizione
Amazon EKS definisce il proprio set di chiavi di condizione e supporta anche l'uso di alcune chiavi di condizione globali. Per visualizzare tutte le chiavi di condizione AWS globali, consulta [AWS Global Condition Context Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) nella *IAM* User Guide.
È possibile impostare le chiavi di condizione quando si associa un provider OpenID Connect al cluster. Per ulteriori informazioni, consulta [Policy IAM di esempio](authenticate-oidc-identity-provider.md#oidc-identity-provider-iam-policy).
Tutte le operazioni Amazon EC2 supportano le chiavi di condizione `aws:RequestedRegion` e `ec2:Region`. Per ulteriori informazioni, consulta [Esempio: limitazione dell'accesso a una AWS regione specifica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region).
Per un elenco di chiavi di condizione di Amazon EKS, consultare [Condizioni per Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) in *Service Authorization Reference*. Per informazioni su operazioni e risorse con cui è possibile utilizzare una chiave di condizione, consultare [Operazioni definite da Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
### Esempi
Per visualizzare esempi di policy basate su identità Amazon EKS, consultare [Esempi di policy basate su identità Amazon EKS](security-iam-id-based-policy-examples.md).
Quando si crea un cluster Amazon EKS, il [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) che crea il cluster riceve automaticamente le autorizzazioni `system:masters` nella configurazione del controllo degli accessi basato sul ruolo (RBAC) nel piano di controllo di Amazon EKS. Questo principale non è visualizzato in una configurazione visibile qualsiasi, quindi assicurati di tenere traccia di quale principale ha originariamente creato il cluster. Per concedere a ulteriori principali IAM la capacità di interagire con il cluster, modifica `aws-auth ConfigMap` all’interno di Kubernetes e crea `rolebinding` o `clusterrolebinding` Kubernetes con il nome di `group` specificato in `aws-auth ConfigMap`.
Per ulteriori informazioni sull'utilizzo di ConfigMap, vedere[Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs](grant-k8s-access.md).
## Policy basate sulle risorse Amazon EKS
Amazon EKS non supporta policy basate su risorse.
## Autorizzazione basata su tag Amazon EKS
È possibile allegare i tag alle risorse Amazon EKS o inoltrarli in una richiesta ad Amazon EKS. Per controllare l’accesso basato su tag, fornire informazioni sui tag nell’[elemento condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) di una policy utilizzando le chiavi di condizione `aws:ResourceTag/key-name `, `aws:RequestTag/key-name ` o `aws:TagKeys`. Per ulteriori informazioni sull'assegnazione di tag delle risorse di Amazon EKS, consultare [Organizzazione delle risorse Amazon EKS con tag](eks-using-tags.md). Per ulteriori informazioni sulle operazioni in cui è possibile utilizzare i tag nelle chiavi di condizione, consulta [Operazioni definite da Amazon EKS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)nel manuale [Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html).
## Ruoli IAM di Amazon EKS
Un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) è un'entità all'interno del tuo AWS account che dispone di autorizzazioni specifiche.
### Utilizzo di credenziali temporanee con Amazon EKS
È possibile utilizzare credenziali temporanee per effettuare l'accesso con la federazione, assumere un ruolo IAM o un ruolo multi-account. È possibile ottenere credenziali di sicurezza temporanee chiamando operazioni API AWS STS come [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)o. [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)
Amazon EKS supporta l'uso di credenziali temporanee.
### Ruoli collegati ai servizi
[I ruoli collegati ai](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) AWS servizi consentono ai servizi di accedere alle risorse di altri servizi per completare un'azione per conto dell'utente. I ruoli collegati ai servizi sono visualizzati nell'account IAM e sono di proprietà del servizio. Un amministratore può visualizzare, ma non può modificare le autorizzazioni dei ruoli collegati ai servizi.
Amazon EKS supporta i ruoli collegati ai servizi. Per maggiori dettagli su come creare e gestire i ruoli collegati ai servizi Amazon EKS, consultare [Utilizzo di ruoli collegati ai servizi per Amazon EKS](using-service-linked-roles.md).
### Ruoli dei servizi
Questa funzionalità consente a un servizio di assumere un [ruolo di servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-role) per conto dell'utente. Questo ruolo consente al servizio di accedere alle risorse in altri servizi per completare un'azione per conto dell'utente. I ruoli dei servizi sono visualizzati nell'account IAM e sono di proprietà dell'account. Ciò significa che un amministratore IAM può modificare le autorizzazioni per questo ruolo. Tuttavia, questo potrebbe pregiudicare la funzionalità del servizio.
Amazon EKS supporta i ruoli del servizio. Per ulteriori informazioni, consultare [Ruolo IAM del cluster Amazon EKS](cluster-iam-role.md) e [Ruolo IAM del nodo Amazon EKS](create-node-role.md).
### Scelta di un ruolo IAM in Amazon EKS
Quando crei una risorsa cluster in Amazon EKS, devi scegliere un ruolo per consentire ad Amazon EKS di accedere a diverse altre AWS risorse per tuo conto. Se hai già creato un ruolo di servizio in precedenza, Amazon EKS ti fornisce un elenco di ruoli da scegliere. È importante scegliere un ruolo con policy gestite da Amazon EKS allegate ad esso. Per ulteriori informazioni, consultare [Verifica della presenza di un ruolo del cluster esistente](cluster-iam-role.md#check-service-role) e [Verifica della presenza di un ruolo di nodo esistente](create-node-role.md#check-worker-node-role).
# Esempi di policy basate su identità Amazon EKS
Per impostazione predefinita, gli utenti e i ruoli IAM non dispongono dell’autorizzazione per creare o modificare risorse Amazon EKS. Inoltre, non possono eseguire attività utilizzando Console di gestione AWS la AWS CLI o AWS l'API. Un amministratore IAM deve creare policy IAM che concedono a utenti e ruoli l'autorizzazione per eseguire operazioni API specifiche sulle risorse specificate di cui hanno bisogno. L'amministratore deve quindi allegare queste policy a utenti o IAM che richiedono tali autorizzazioni.
Per informazioni su come creare una policy basata su identità IAM utilizzando questi documenti di policy JSON di esempio, consultare [Creazione di policy nella scheda JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) nella *Guida per l'utente di IAM*.
Quando si crea un cluster Amazon EKS, il [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) che crea il cluster riceve automaticamente le autorizzazioni `system:masters` nella configurazione del controllo degli accessi basato sul ruolo (RBAC) nel piano di controllo di Amazon EKS. Questo principale non è visualizzato in una configurazione visibile qualsiasi, quindi assicurati di tenere traccia di quale principale ha originariamente creato il cluster. Per concedere a ulteriori principali IAM la capacità di interagire con il cluster, modifica `aws-auth ConfigMap` all’interno di Kubernetes e crea `rolebinding` o `clusterrolebinding` Kubernetes con il nome di `group` specificato in `aws-auth ConfigMap`.
Per ulteriori informazioni sull'utilizzo di ConfigMap, vedere[Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs](grant-k8s-access.md).
**Topics**
+ [Best practice per le policy](#security-iam-service-with-iam-policy-best-practices)
+ [Utilizzo della console Amazon EKS](#security-iam-id-based-policy-examples-console)
+ [Consentire agli utenti IAM di visualizzare le loro autorizzazioni](#security-iam-id-based-policy-examples-view-own-permissions)
+ [Crea un cluster Kubernetes sul cloud AWS](#policy-create-cluster)
+ [Creazione di un cluster Kubernetes locale su un Outpost](#policy-create-local-cluster)
+ [Aggiornare un cluster Kubernetes](#policy-example1)
+ [Elencare o descrivere tutti i cluster](#policy-example2)
## Best practice per le policy
Le policy basate su identità determinano se qualcuno può creare, accedere o eliminare risorse Amazon EKS nell'account. Queste azioni possono comportare costi per il tuo AWS account. Quando si creano o modificano policy basate sull’identità, seguire queste linee guida e raccomandazioni:
+ **Inizia con le policy AWS gestite e passa alle autorizzazioni con privilegi minimi: per iniziare a concedere autorizzazioni** a utenti e carichi di lavoro, utilizza le politiche * AWS gestite* che concedono le autorizzazioni per molti casi d'uso comuni. Sono disponibili nel tuo account. AWS Ti consigliamo di ridurre ulteriormente le autorizzazioni definendo politiche gestite dai AWS clienti specifiche per i tuoi casi d'uso. Per maggiori informazioni, consulta [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o [Policy gestite da AWS per le funzioni dei processi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) nella *Guida per l’utente di IAM*.
+ **Applicazione delle autorizzazioni con privilegio minimo** - Quando si impostano le autorizzazioni con le policy IAM, concedere solo le autorizzazioni richieste per eseguire un’attività. È possibile farlo definendo le azioni che possono essere intraprese su risorse specifiche in condizioni specifiche, note anche come *autorizzazioni con privilegio minimo*. Per maggiori informazioni sull’utilizzo di IAM per applicare le autorizzazioni, consulta [Policy e autorizzazioni in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) nella *Guida per l’utente di IAM*.
+ **Condizioni d’uso nelle policy IAM per limitare ulteriormente l’accesso** - Per limitare l’accesso ad azioni e risorse è possibile aggiungere una condizione alle policy. Ad esempio, è possibile scrivere una condizione di policy per specificare che tutte le richieste devono essere inviate utilizzando SSL. Puoi anche utilizzare le condizioni per concedere l'accesso alle azioni del servizio se vengono utilizzate tramite un AWS servizio specifico, ad esempio AWS CloudFormation. Per maggiori informazioni, consultare la sezione [Elementi delle policy JSON di IAM: condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) nella *Guida per l’utente di IAM*.
+ **Utilizzo dello strumento di analisi degli accessi IAM per convalidare le policy IAM e garantire autorizzazioni sicure e funzionali** - Lo strumento di analisi degli accessi IAM convalida le policy nuove ed esistenti in modo che aderiscano al linguaggio (JSON) della policy IAM e alle best practice di IAM. IAM Access Analyzer offre oltre 100 controlli delle policy e consigli utili per creare policy sicure e funzionali. Per ulteriori informazioni, consulta [Convalida delle policy per IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) nella *Guida per l'utente IAM*.
+ **Richiedi l'autenticazione a più fattori (MFA**): se hai uno scenario che richiede utenti IAM o un utente root nel AWS tuo account, attiva l'MFA per una maggiore sicurezza. Per richiedere la MFA quando vengono chiamate le operazioni API, aggiungi le condizioni MFA alle policy. Per ulteriori informazioni, consulta [Configurazione dell'accesso alle API protetto con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) nella *Guida per l'utente IAM*.
Per maggiori informazioni sulle best practice in IAM, consulta [Best practice di sicurezza in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) nella *Guida per l'utente di IAM*.
## Utilizzo della console Amazon EKS
Per accedere alla console Amazon EKS, un [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) deve disporre di un set di autorizzazioni minimo. Queste autorizzazioni consentono al responsabile di elencare e visualizzare i dettagli sulle risorse Amazon EKS nel tuo AWS account. Se crei una policy di basata su identità più restrittiva delle autorizzazioni minime richieste, la console non funzionerà nel modo previsto per i principali associati a tale policy.
Per garantire che i principali IAM possano comunque utilizzare la console Amazon EKS, crea una policy con un nome univoco, ad esempio `AmazonEKSAdminPolicy`. Allega la politica ai principali. Per ulteriori informazioni, consulta [Aggiunta e rimozione di autorizzazioni per identità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) nella *Guida per l'utente di IAM*.
**Importante**
La policy di esempio riportata di seguito consente a un principale di visualizzare le informazioni sulla scheda **Configurazione** della console. Per visualizzare le informazioni nelle schede **Panoramica** e **Risorse** di Console di gestione AWS, il principale necessita anche delle autorizzazioni Kubernetes. Per ulteriori informazioni, consulta [Autorizzazioni richieste](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "eks.amazonaws.com"
}
}
}
]
}
```
Non è necessario consentire le autorizzazioni minime della console per i principali che effettuano chiamate solo alla AWS CLI o all'API. AWS Al contrario, è possibile accedere solo alle operazioni che soddisfano l’operazione API che stai cercando di eseguire.
## Consentire agli utenti IAM di visualizzare le loro autorizzazioni
Questo esempio mostra in che modo è possibile creare una policy che consente agli utenti IAM di visualizzare le policy inline e gestite che sono collegate alla relativa identità utente. Questa politica include le autorizzazioni per completare questa azione sulla console o a livello di codice utilizzando la CLI o l'API AWS . AWS
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Crea un cluster Kubernetes sul cloud AWS
Questa policy di esempio include le autorizzazioni minime richieste per creare un cluster Amazon EKS denominato *my-cluster* nella *us-west-2* AWS regione. Puoi sostituire la AWS regione con la AWS regione in cui desideri creare un cluster. Se viene visualizzato un avviso che indica che **le azioni contenute nella politica non supportano le autorizzazioni a livello di risorsa e richiedono la scelta `All resources` Console di gestione AWS, è possibile** ignorarlo senza problemi. Se il tuo account dispone già del ruolo *AWSServiceRoleForAmazonEKS*, puoi rimuovere l'azione `iam:CreateServiceLinkedRole` dalla policy. Se hai mai creato un cluster Amazon EKS nel tuo account, questo ruolo è già esistente, a meno che sia stato eliminato.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
"Condition": {
"ForAnyValue:StringEquals": {
"iam:AWSServiceName": "eks"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
}
]
}
```
## Creazione di un cluster Kubernetes locale su un Outpost
Questa policy di esempio include le autorizzazioni minime richieste per creare un cluster locale Amazon EKS denominato *my-cluster* su un Outpost nella *us-west-2* AWS regione. Puoi sostituire la AWS regione con la AWS regione in cui desideri creare un cluster. Se viene visualizzato un avviso che indica che **le azioni contenute nella politica non supportano le autorizzazioni a livello di risorsa e richiedono la scelta `All resources` Console di gestione AWS, è possibile** ignorarlo senza problemi. Se il tuo account dispone già del ruolo `AWSServiceRoleForAmazonEKSLocalOutpost`, puoi rimuovere l'azione `iam:CreateServiceLinkedRole` dalla policy. Se hai già creato un cluster locale Amazon EKS su Outpost nel tuo account, questo ruolo esiste già a meno che tu non l’abbia eliminato.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Action": [
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"iam:GetRole"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/outposts.eks-local.amazonaws.com/AWSServiceRoleForAmazonEKSLocalOutpost"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:ListAttachedRolePolicies"
],
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
},
{
"Action": [
"iam:CreateInstanceProfile",
"iam:TagInstanceProfile",
"iam:AddRoleToInstanceProfile",
"iam:GetInstanceProfile",
"iam:DeleteInstanceProfile",
"iam:RemoveRoleFromInstanceProfile"
],
"Resource": "arn:aws:iam::*:instance-profile/eks-local-*",
"Effect": "Allow"
}
]
}
```
## Aggiornare un cluster Kubernetes
Questa politica di esempio include l'autorizzazione minima richiesta per aggiornare un cluster denominato *my-cluster* nella regione us-west-2 AWS .
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:UpdateClusterVersion",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
}
]
}
```
## Elencare o descrivere tutti i cluster
Questa policy di esempio include le autorizzazioni minime richieste per elencare e descrivere tutti i cluster dell'account. Un [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) deve essere in grado di elencare e descrivere i cluster per utilizzare il comando `update-kubeconfig` AWS CLI.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
```
# Utilizzo di ruoli collegati ai servizi per Amazon EKS
Amazon Elastic Kubernetes Service utilizza [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) di AWS Identity and Access Management (IAM). Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EKS. I ruoli collegati ai servizi sono definiti automaticamente da Amazon EKS e includono tutte le autorizzazioni richieste dal servizio per eseguire chiamate agli altri servizi AWS per conto dell’utente.
**Topics**
+ [Utilizzo dei ruoli per i cluster Amazon EKS](using-service-linked-roles-eks.md)
+ [Utilizzo dei ruoli per i gruppi di nodi Amazon EKS](using-service-linked-roles-eks-nodegroups.md)
+ [Utilizzo dei ruoli per i profili Fargate in Amazon EKS](using-service-linked-roles-eks-fargate.md)
+ [Utilizzo di ruoli per connettere un cluster Kubernetes ad Amazon EKS](using-service-linked-roles-eks-connector.md)
+ [Utilizzo dei ruoli per i cluster locali Amazon EKS su Outpost](using-service-linked-roles-eks-outpost.md)
+ [Utilizzo dei ruoli per la dashboard Amazon EKS](using-service-linked-roles-eks-dashboard.md)
# Utilizzo dei ruoli per i cluster Amazon EKS
Amazon Elastic Kubernetes Service utilizza [ruoli collegati a servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) AWS Identity and Access Management (IAM) Ruoli collegati ai servizi. Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EKS. I ruoli collegati ai servizi sono definiti automaticamente da Amazon EKS e includono tutte le autorizzazioni richieste dal servizio per eseguire chiamate agli altri servizi AWS per conto dell'utente.
Un ruolo collegato ai servizi semplifica la configurazione di Amazon EKS perché consente di evitare l’aggiunta manuale delle autorizzazioni necessarie. Amazon EKS definisce le autorizzazioni del ruolo associato ai servizi e, salvo diversamente definito, solo Amazon EKS può assumerne il ruolo. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni che non può essere allegata a nessun'altra entità IAM.
È possibile eliminare un ruolo collegato ai servizi solo dopo aver eliminato le risorse correlate. Questa procedura protegge le risorse di Amazon EKS perché impedisce la rimozione involontaria delle autorizzazioni di accesso alle risorse.
Per informazioni sugli altri servizi che supportano i ruoli collegati ai servizi, consultare [Servizi AWS che funzionano con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cercare i servizi che riportano **Yes (Sì)** nella colonna **Service-linked roles (Ruoli collegati ai servizi)**. Scegli **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio.
## Autorizzazioni del ruolo collegato ai servizi per Amazon EKS
Amazon EKS usa il ruolo collegato ai servizi denominato `AWSServiceRoleForAmazonEKS`. Il ruolo consente ad Amazon EKS di gestire i cluster nell’account. Le policy allegate consentono al ruolo di gestire le seguenti risorse: interfacce di rete, gruppi di sicurezza, registri e VPC.
**Nota**
Il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKS` è distinto dal ruolo richiesto per la creazione del cluster. Per ulteriori informazioni, consulta [Ruolo IAM del cluster Amazon EKS](cluster-iam-role.md).
Ai fini dell'assunzione del ruolo, il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKS` considera attendibili i seguenti servizi:
+ `eks.amazonaws.com`
La policy delle autorizzazioni del ruolo consente ad Amazon EKS di eseguire le seguenti operazioni sulle risorse specificate:
+ [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
Per consentire a un'entità IAM (come un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato ai servizi devi configurare le relative autorizzazioni. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente di IAM*.
## Creazione di un ruolo collegato ai servizi per Amazon EKS
Non hai bisogno di creare manualmente un ruolo collegato ai servizi. Quando si crea un cluster in Console di gestione AWS, AWS CLI, o AWS API, Amazon EKS crea automaticamente il ruolo collegato al servizio.
Se elimini questo ruolo collegato ai servizi, è possibile ricrearlo seguendo lo stesso processo utilizzato per ricreare il ruolo nell'account. Quando viene creato un cluster, Amazon EKS crea di nuovo il ruolo collegato ai servizi automaticamente.
## Modifica di un ruolo collegato ai servizi per Amazon EKS
Amazon EKS non consente di modificare il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKS`. Dopo aver creato un ruolo collegato al servizio, non potrai modificarne il nome perché varie entità potrebbero farvi riferimento. È possibile tuttavia modificarne la descrizione utilizzando IAM. Per ulteriori informazioni, consulta [Modifica di un ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) nella *Guida per l'utente di IAM*.
## Eliminazione di un ruolo collegato ai servizi per Amazon EKS
Se non è più necessario utilizzare una funzionalità o un servizio che richiede un ruolo collegato al servizio, ti consigliamo di eliminare il ruolo. In questo modo non sarà più presente un'entità non utilizzata che non viene monitorata e gestita attivamente. Tuttavia, è necessario effettuare la pulizia delle risorse associate al ruolo collegato ai servizi prima di poterlo eliminare manualmente.
### Pulizia di un ruolo collegato ai servizi
Prima di utilizzare IAM; per eliminare un ruolo collegato al servizio, è necessario prima rimuovere qualsiasi risorsa utilizzata dal ruolo.
**Nota**
Se il servizio Amazon EKS utilizza tale ruolo quando tenti di eliminare le risorse, è possibile che l'eliminazione non riesca. In questo caso, attendi alcuni minuti e quindi ripeti l'operazione.
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra selezionare **Clusters** (Cluster).
1. Se il cluster dispone di gruppi di nodi o profili Fargate, è necessario eliminarli prima di eliminare il cluster. Per ulteriori informazioni, consultare [Eliminare un gruppo di nodi gestito dal cluster](delete-managed-node-group.md) e [Eliminare un profilo Fargate](delete-fargate-profile.md).
1. Sulla pagina **Cluster**, scegliere il cluster da eliminare e scegliere **Elimina**.
1. Digitare il nome del cluster nella finestra di conferma eliminazione, quindi scegliere **Elimina**.
1. Ripetere questa procedura per tutti gli altri cluster nell'account. Attendere che tutte le operazioni di eliminazione siano completate.
### Eliminazione manuale del ruolo collegato ai servizi
Utilizza la console IAM, la CLI di AWS o l'API AWS per eliminare il ruolo orientato ai servizi `AWSServiceRoleForAmazonEKS`. Per ulteriori informazioni, consulta [Eliminazione del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) nella *Guida per l'utente di IAM*.
## Regioni supportate per i ruoli collegati ai servizi di Amazon EKS
Amazon EKS supporta l'utilizzo di ruoli collegati ai servizi in tutte le Regioni in cui il servizio è disponibile. Per ulteriori informazioni, consulta la sezione [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html) (Endpoint e quote di servizio di Amazon EKS).
# Utilizzo dei ruoli per i gruppi di nodi Amazon EKS
Amazon EKS utilizza i [ruoli collegati ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) di AWS Identity and Access Management (IAM). Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EKS. I ruoli collegati ai servizi sono definiti automaticamente da Amazon EKS e includono tutte le autorizzazioni richieste dal servizio per eseguire chiamate agli altri servizi AWS per conto dell'utente.
Un ruolo collegato ai servizi semplifica la configurazione di Amazon EKS perché consente di evitare l’aggiunta manuale delle autorizzazioni necessarie. Amazon EKS definisce le autorizzazioni del ruolo associato ai servizi e, salvo diversamente definito, solo Amazon EKS può assumerne il ruolo. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni che non può essere allegata a nessun'altra entità IAM.
È possibile eliminare un ruolo collegato ai servizi solo dopo aver eliminato le risorse correlate. Questa procedura protegge le risorse di Amazon EKS perché impedisce la rimozione involontaria delle autorizzazioni di accesso alle risorse.
Per informazioni sugli altri servizi che supportano i ruoli collegati ai servizi, consultare [Servizi AWS che funzionano con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cercare i servizi che riportano **Yes (Sì)** nella colonna **Service-linked roles (Ruoli collegati ai servizi)**. Scegli **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio.
## Autorizzazioni del ruolo collegato ai servizi per Amazon EKS
Amazon EKS usa il ruolo collegato ai servizi denominato `AWSServiceRoleForAmazonEKSNodegroup`. Il ruolo consente ad Amazon EKS di gestire i gruppi di nodi nell’account. La policy `AWSServiceRoleForAmazonEKSNodegroup` allegata consente al ruolo di gestire le seguenti risorse: gruppi Auto Scaling, gruppi di sicurezza, modelli di avvio e profili dell’istanza IAM. Per ulteriori informazioni, consulta [AWS politica gestita: AWSService RoleForAmazon EKSNodegroup](security-iam-awsmanpol.md#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup).
Ai fini dell'assunzione del ruolo, il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKSNodegroup` considera attendibili i seguenti servizi:
+ `eks-nodegroup.amazonaws.com`
La policy delle autorizzazioni del ruolo consente ad Amazon EKS di eseguire le seguenti operazioni sulle risorse specificate:
+ [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html)
Per consentire a un'entità IAM (come un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato ai servizi devi configurare le relative autorizzazioni. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente di IAM*.
## Creazione di un ruolo collegato ai servizi per Amazon EKS
Non hai bisogno di creare manualmente un ruolo collegato ai servizi. Quando si crea un gruppo di nodi gestiti in Console di gestione AWS, AWS CLI o nell’API AWS, Amazon EKS crea automaticamente il ruolo collegato al servizio.
**Importante**
Questo ruolo collegato al servizio può apparire nell'account, se è stata completata un'operazione in un altro servizio che utilizza le caratteristiche supportate da questo ruolo. Se si utilizzava il servizio Amazon EKS prima dell'1 Gennaio 2017, data da cui è disponibile il supporto dei ruoli collegati ai servizi, Amazon EKS ha creato il ruolo AWSServiceRoleForAmazonEKSNodegroup nell'account. Per ulteriori informazioni, consultare [Un nuovo ruolo è apparso nel mio account IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
### Creazione di un ruolo collegato ai servizi in Amazon EKS (AWS API)
Non hai bisogno di creare manualmente un ruolo collegato ai servizi. Quando si crea un gruppo di nodi gestiti in Console di gestione AWS, AWS CLI o nell’API AWS, Amazon EKS crea automaticamente il ruolo collegato al servizio.
Se elimini questo ruolo collegato ai servizi, è possibile ricrearlo seguendo lo stesso processo utilizzato per ricreare il ruolo nell'account. Quando si crea un altro gruppo di nodi gestiti, Amazon EKS crea nuovamente il ruolo collegato al servizio.
## Modifica di un ruolo collegato ai servizi per Amazon EKS
Amazon EKS non consente di modificare il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKSNodegroup`. Dopo aver creato un ruolo collegato al servizio, non potrai modificarne il nome perché varie entità potrebbero farvi riferimento. È possibile tuttavia modificarne la descrizione utilizzando IAM. Per ulteriori informazioni, consulta [Modifica di un ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) nella *Guida per l'utente di IAM*.
## Eliminazione di un ruolo collegato ai servizi per Amazon EKS
Se non è più necessario utilizzare una funzionalità o un servizio che richiede un ruolo collegato al servizio, ti consigliamo di eliminare il ruolo. In questo modo non sarà più presente un'entità non utilizzata che non viene monitorata e gestita attivamente. Tuttavia, è necessario effettuare la pulizia delle risorse associate al ruolo collegato ai servizi prima di poterlo eliminare manualmente.
### Pulizia di un ruolo collegato ai servizi
Prima di utilizzare IAM; per eliminare un ruolo collegato al servizio, è necessario prima rimuovere qualsiasi risorsa utilizzata dal ruolo.
**Nota**
Se il servizio Amazon EKS utilizza tale ruolo quando tenti di eliminare le risorse, è possibile che l'eliminazione non riesca. In questo caso, attendi alcuni minuti e quindi ripeti l'operazione.
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra, seleziona **Cluster**.
1. Seleziona la scheda **Compute** (Calcolo).
1. Nella sezione **Gruppi di nodi**, scegliere il gruppo di nodi da eliminare.
1. Digitare il nome del gruppo di nodi nella finestra di conferma eliminazione e quindi scegliere **Elimina**.
1. Ripetere questa procedura per tutti gli altri gruppi di nodi nel cluster. Attendere che tutte le operazioni di eliminazione siano completate.
### Eliminazione manuale del ruolo collegato ai servizi
Utilizza la console IAM, la CLI di AWS o l'API AWS per eliminare il ruolo orientato ai servizi `AWSServiceRoleForAmazonEKSNodegroup`. Per ulteriori informazioni, consulta [Eliminazione del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) nella *Guida per l'utente di IAM*.
## Regioni supportate per i ruoli collegati ai servizi di Amazon EKS
Amazon EKS supporta l'utilizzo di ruoli collegati ai servizi in tutte le Regioni in cui il servizio è disponibile. Per ulteriori informazioni, consulta la sezione [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html) (Endpoint e quote di servizio di Amazon EKS).
# Utilizzo dei ruoli per i profili Fargate in Amazon EKS
Amazon EKS utilizza i [ruoli collegati ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) di AWS Identity and Access Management (IAM). Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EKS. I ruoli collegati ai servizi sono definiti automaticamente da Amazon EKS e includono tutte le autorizzazioni richieste dal servizio per eseguire chiamate agli altri servizi AWS per conto dell'utente.
Un ruolo collegato ai servizi semplifica la configurazione di Amazon EKS perché consente di evitare l’aggiunta manuale delle autorizzazioni necessarie. Amazon EKS definisce le autorizzazioni del ruolo associato ai servizi e, salvo diversamente definito, solo Amazon EKS può assumerne il ruolo. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni che non può essere allegata a nessun'altra entità IAM.
È possibile eliminare un ruolo collegato ai servizi solo dopo aver eliminato le risorse correlate. Questa procedura protegge le risorse di Amazon EKS perché impedisce la rimozione involontaria delle autorizzazioni di accesso alle risorse.
Per informazioni sugli altri servizi che supportano i ruoli collegati ai servizi, consultare [Servizi AWS che funzionano con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cercare i servizi che riportano **Yes (Sì)** nella colonna **Service-linked roles (Ruoli collegati ai servizi)**. Scegli **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio.
## Autorizzazioni del ruolo collegato ai servizi per Amazon EKS
Amazon EKS usa il ruolo collegato ai servizi denominato `AWSServiceRoleForAmazonEKSForFargate`. Il ruolo consente ad Amazon EKS Fargate di configurare la rete VPC necessaria per i pod Fargate. Le policy collegate consentono al ruolo di creare ed eliminare le interfacce di rete elastiche e di descrivere le risorse e le interfacce di rete elastiche.
Ai fini dell'assunzione del ruolo, il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKSForFargate` considera attendibili i seguenti servizi:
+ `eks-fargate.amazonaws.com`
La policy delle autorizzazioni del ruolo consente ad Amazon EKS di eseguire le seguenti operazioni sulle risorse specificate:
+ [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html)
Per consentire a un'entità IAM (come un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato ai servizi devi configurare le relative autorizzazioni. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente di IAM*.
## Creazione di un ruolo collegato ai servizi per Amazon EKS
Non hai bisogno di creare manualmente un ruolo collegato ai servizi. Quando crei un profilo Fargate in Console di gestione AWS, AWS CLI o nell’API AWS, Amazon EKS crea il ruolo collegato al servizio per l’utente.
**Importante**
Questo ruolo collegato al servizio può apparire nell'account, se è stata completata un'operazione in un altro servizio che utilizza le caratteristiche supportate da questo ruolo. Se si utilizzava il servizio Amazon EKS prima del 13 dicembre 2019, data da cui è disponibile il supporto dei ruoli collegati ai servizi, allora Amazon EKS ha creato il ruolo AWSServiceRoleForAmazonEKSForFargate nell'account. Per ulteriori informazioni, consulta la sezione [A New role appeared in my IAM account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared) (Nel mio account IAM è apparso un nuovo ruolo).
### Creazione di un ruolo collegato ai servizi in Amazon EKS (AWS API)
Non hai bisogno di creare manualmente un ruolo collegato ai servizi. Quando crei un profilo Fargate in Console di gestione AWS, AWS CLI o nell’API AWS, Amazon EKS crea il ruolo collegato al servizio per l’utente.
Se elimini questo ruolo collegato ai servizi, è possibile ricrearlo seguendo lo stesso processo utilizzato per ricreare il ruolo nell'account. Quando si crea un altro gruppo di nodi gestiti, Amazon EKS crea nuovamente il ruolo collegato al servizio.
## Modifica di un ruolo collegato ai servizi per Amazon EKS
Amazon EKS non consente di modificare il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKSForFargate`. Dopo aver creato un ruolo collegato al servizio, non potrai modificarne il nome perché varie entità potrebbero farvi riferimento. È possibile tuttavia modificarne la descrizione utilizzando IAM. Per ulteriori informazioni, consulta [Modifica di un ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) nella *Guida per l'utente di IAM*.
## Eliminazione di un ruolo collegato ai servizi per Amazon EKS
Se non è più necessario utilizzare una funzionalità o un servizio che richiede un ruolo collegato al servizio, ti consigliamo di eliminare il ruolo. In questo modo non sarà più presente un'entità non utilizzata che non viene monitorata e gestita attivamente. Tuttavia, è necessario effettuare la pulizia delle risorse associate al ruolo collegato ai servizi prima di poterlo eliminare manualmente.
### Pulizia di un ruolo collegato ai servizi
Prima di utilizzare IAM; per eliminare un ruolo collegato al servizio, è necessario prima rimuovere qualsiasi risorsa utilizzata dal ruolo.
**Nota**
Se il servizio Amazon EKS utilizza tale ruolo quando tenti di eliminare le risorse, è possibile che l'eliminazione non riesca. In questo caso, attendi alcuni minuti e quindi ripeti l'operazione.
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra, seleziona **Cluster**.
1. Nella pagina **Cluster** selezionare il cluster.
1. Seleziona la scheda **Compute** (Calcolo).
1. Se sono presenti profili Fargate nella sezione **Fargate profiles** (Profili Fargate), selezionare ciascun profilo singolarmente, quindi scegliere **Delete** (Elimina).
1. Digitare il nome del cluster nella finestra di conferma eliminazione e quindi scegliere **Elimina**.
1. Ripetere questa procedura per tutti gli altri profili Fargate nel cluster e per ciascun cluster nell'account.
### Eliminazione manuale del ruolo collegato ai servizi
Utilizza la console IAM, la AWS CLI o l’API AWS per eliminare il ruolo collegato al servizio AWSServiceRoleForAmazonEKSForFargate. Per ulteriori informazioni, consulta [Eliminazione del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) nella *Guida per l'utente di IAM*.
## Regioni supportate per i ruoli collegati ai servizi di Amazon EKS
Amazon EKS supporta l'utilizzo di ruoli collegati ai servizi in tutte le Regioni in cui il servizio è disponibile. Per ulteriori informazioni, consulta la sezione [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html) (Endpoint e quote di servizio di Amazon EKS).
# Utilizzo di ruoli per connettere un cluster Kubernetes ad Amazon EKS
Amazon EKS utilizza ruoli AWS collegati al [servizio Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role). Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EKS. I ruoli collegati ai servizi sono predefiniti da Amazon EKS e includono tutte le autorizzazioni richieste dal servizio per chiamare altri AWS servizi per tuo conto.
Un ruolo collegato ai servizi semplifica la configurazione di Amazon EKS perché consente di evitare l’aggiunta manuale delle autorizzazioni necessarie. Amazon EKS definisce le autorizzazioni del ruolo associato ai servizi e, salvo diversamente definito, solo Amazon EKS può assumerne il ruolo. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni che non può essere allegata a nessun'altra entità IAM.
È possibile eliminare un ruolo collegato al servizio solo dopo avere eliminato le risorse correlate. Questa procedura protegge le risorse di Amazon EKS perché impedisce la rimozione involontaria delle autorizzazioni di accesso alle risorse.
Per informazioni sugli altri servizi che supportano i ruoli collegati ai servizi, consulta [Servizi AWS che funzionano con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cerca i servizi che riportano **Yes** (Sì) nella colonna **Service-linked roles** (Ruoli collegati ai servizi). Scegli **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio.
## Autorizzazioni del ruolo collegato ai servizi per Amazon EKS
Amazon EKS usa il ruolo collegato ai servizi denominato `AWSServiceRoleForAmazonEKSConnector`. Il ruolo consente ad Amazon EKS di collegarsi ai cluster Kubernetes. Le policy allegate consentono al ruolo di gestire le risorse necessarie per connettersi al cluster Kubernetes registrato.
Ai fini dell’assunzione del ruolo, il ruolo collegato al servizio `AWSServiceRoleForAmazonEKSConnector` considera attendibili i seguenti servizi:
+ `eks-connector.amazonaws.com`
La policy delle autorizzazioni del ruolo consente ad Amazon EKS di eseguire le seguenti operazioni sulle risorse specificate:
+ [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)
Per consentire a un’entità IAM (come un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato al servizio è necessario configurare le relative autorizzazioni. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente IAM*.
Questo ruolo utilizza le autorizzazioni SSM (Systems Manager) per stabilire connessioni sicure e gestire i cluster Kubernetes connessi.
## Creazione di un ruolo collegato ai servizi per Amazon EKS
Non devi creare manualmente un ruolo collegato ai servizi per collegare un cluster. Quando connetti un cluster nella AWS CLI o nell' AWS API`eksctl`, Amazon EKS crea il ruolo collegato al servizio per te. Console di gestione AWS
Se elimini questo ruolo collegato al servizio, è possibile ricrearlo seguendo lo stesso processo utilizzato per ricreare il ruolo nell’account. Quando viene collegato un cluster, Amazon EKS crea di nuovo il ruolo collegato ai servizi automaticamente.
## Modifica di un ruolo collegato ai servizi per Amazon EKS
Amazon EKS non consente di modificare il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKSConnector`. Dopo avere creato un ruolo collegato al servizio, non sarà possibile modificarne il nome perché varie entità potrebbero farvi riferimento. È possibile tuttavia modificarne la descrizione utilizzando IAM. Per ulteriori informazioni, consulta [Modifica di un ruolo collegato al servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) nella *Guida per l’utente di IAM*.
## Eliminazione di un ruolo collegato ai servizi per Amazon EKS
Se non è più necessario utilizzare una funzionalità o un servizio che richiede un ruolo collegato al servizio, ti consigliamo di eliminare il ruolo. In questo modo non sarà più presente un’entità non utilizzata che non viene monitorata e gestita attivamente. Tuttavia, è necessario effettuare la pulizia delle risorse associate al ruolo collegato ai servizi prima di poterlo eliminare manualmente.
### Pulizia di un ruolo collegato ai servizi
Prima di utilizzare IAM; per eliminare un ruolo collegato al servizio, è necessario prima rimuovere qualsiasi risorsa utilizzata dal ruolo.
**Nota**
Se il servizio Amazon EKS utilizza tale ruolo quando tenti di eliminare le risorse, è possibile che l'eliminazione non riesca. In questo caso, attendi alcuni minuti e quindi ripeti l’operazione.
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra, seleziona **Cluster**.
1. Nella pagina **Cluster** selezionare il cluster.
1. Selezionare la scheda **Annulla registrazione** e quindi selezionare la scheda **Ok**.
### Eliminazione manuale del ruolo collegato ai servizi
Utilizza la console IAM, la AWS CLI o l' AWS API per eliminare il ruolo collegato al AWSService RoleForAmazon EKSConnector servizio. Per ulteriori informazioni, consultare [Eliminazione del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) nella *Guida per l'utente di IAM*.
# Utilizzo dei ruoli per i cluster locali Amazon EKS su Outpost
Amazon Elastic Kubernetes Service utilizza [ruoli collegati a servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) AWS Identity and Access Management (IAM) Ruoli collegati ai servizi. Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EKS. I ruoli collegati ai servizi sono definiti automaticamente da Amazon EKS e includono tutte le autorizzazioni richieste dal servizio per eseguire chiamate agli altri servizi AWS per conto dell'utente.
Un ruolo collegato ai servizi semplifica la configurazione di Amazon EKS perché consente di evitare l’aggiunta manuale delle autorizzazioni necessarie. Amazon EKS definisce le autorizzazioni del ruolo associato ai servizi e, salvo diversamente definito, solo Amazon EKS può assumerne il ruolo. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni che non può essere allegata a nessun'altra entità IAM.
È possibile eliminare un ruolo collegato ai servizi solo dopo aver eliminato le risorse correlate. Questa procedura protegge le risorse di Amazon EKS perché impedisce la rimozione involontaria delle autorizzazioni di accesso alle risorse.
Per informazioni sugli altri servizi che supportano i ruoli collegati ai servizi, consultare [Servizi AWS che funzionano con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cercare i servizi che riportano **Yes (Sì)** nella colonna **Service-linked roles (Ruoli collegati ai servizi)**. Scegli **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio.
## Autorizzazioni del ruolo collegato ai servizi per Amazon EKS
Amazon EKS usa il ruolo collegato ai servizi denominato `AWSServiceRoleForAmazonEKSLocalOutpost`. Il ruolo consente ad Amazon EKS di gestire i cluster locali nell’account. Le policy collegate consentono al ruolo di gestire le seguenti risorse: interfacce di rete, gruppi di sicurezza, registri e istanze Amazon EC2.
**Nota**
Il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKSLocalOutpost` è distinto dal ruolo richiesto per la creazione del cluster. Per ulteriori informazioni, consulta [Ruolo IAM del cluster Amazon EKS](cluster-iam-role.md).
Ai fini dell'assunzione del ruolo, il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKSLocalOutpost` considera attendibili i seguenti servizi:
+ `outposts.eks-local.amazonaws.com`
La policy delle autorizzazioni del ruolo consente ad Amazon EKS di eseguire le seguenti operazioni sulle risorse specificate:
+ [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
Per consentire a un'entità IAM (come un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato ai servizi devi configurare le relative autorizzazioni. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente di IAM*.
## Creazione di un ruolo collegato ai servizi per Amazon EKS
Non hai bisogno di creare manualmente un ruolo collegato ai servizi. Quando si crea un cluster in Console di gestione AWS, AWS CLI, o AWS API, Amazon EKS crea automaticamente il ruolo collegato al servizio.
Se elimini questo ruolo collegato ai servizi, è possibile ricrearlo seguendo lo stesso processo utilizzato per ricreare il ruolo nell'account. Quando viene creato un cluster, Amazon EKS crea di nuovo il ruolo collegato ai servizi automaticamente.
## Modifica di un ruolo collegato ai servizi per Amazon EKS
Amazon EKS non consente di modificare il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKSLocalOutpost`. Dopo aver creato un ruolo collegato al servizio, non è possibile modificarne il nome, perché potrebbero farvi riferimento diverse entità. È possibile tuttavia modificarne la descrizione utilizzando IAM. Per ulteriori informazioni, consulta [Modifica di un ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) nella *Guida per l'utente di IAM*.
## Eliminazione di un ruolo collegato ai servizi per Amazon EKS
Se non è più necessario utilizzare una funzionalità o un servizio che richiede un ruolo collegato al servizio, ti consigliamo di eliminare il ruolo. In questo modo non sarà più presente un'entità non utilizzata che non viene monitorata e gestita attivamente. Tuttavia, è necessario effettuare la pulizia delle risorse associate al ruolo collegato ai servizi prima di poterlo eliminare manualmente.
### Pulizia di un ruolo collegato ai servizi
Prima di utilizzare IAM; per eliminare un ruolo collegato al servizio, è necessario prima rimuovere qualsiasi risorsa utilizzata dal ruolo.
**Nota**
Se il servizio Amazon EKS utilizza tale ruolo quando tenti di eliminare le risorse, è possibile che l'eliminazione non riesca. In questo caso, attendi alcuni minuti e quindi ripeti l'operazione.
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra, scegli **Clusters** (Cluster) Amazon EKS.
1. Se il cluster dispone di gruppi di nodi o profili Fargate, è necessario eliminarli prima di eliminare il cluster. Per ulteriori informazioni, consultare [Eliminare un gruppo di nodi gestito dal cluster](delete-managed-node-group.md) e [Eliminare un profilo Fargate](delete-fargate-profile.md).
1. Sulla pagina **Cluster**, scegliere il cluster da eliminare e scegliere **Elimina**.
1. Digitare il nome del cluster nella finestra di conferma eliminazione, quindi scegliere **Elimina**.
1. Ripetere questa procedura per tutti gli altri cluster nell'account. Attendere che tutte le operazioni di eliminazione siano completate.
### Eliminazione manuale del ruolo collegato ai servizi
Utilizza la console IAM, la CLI di AWS o l'API AWS per eliminare il ruolo orientato ai servizi `AWSServiceRoleForAmazonEKSLocalOutpost`. Per ulteriori informazioni, consulta [Eliminazione del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) nella *Guida per l'utente di IAM*.
## Regioni supportate per i ruoli collegati ai servizi di Amazon EKS
Amazon EKS supporta l'utilizzo di ruoli collegati ai servizi in tutte le Regioni in cui il servizio è disponibile. Per ulteriori informazioni, consulta la sezione [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html) (Endpoint e quote di servizio di Amazon EKS).
# Utilizzo dei ruoli per la dashboard Amazon EKS
La dashboard Amazon EKS utilizza questo ruolo collegato ai servizi per aggregare informazioni sulle risorse del cluster da più regioni e account. La dashboard si integra con AWS Organizations per leggere in modo sicuro le informazioni su più account dell’organizzazione.
Per ulteriori informazioni sulle dashboard Amazon EKS, consulta [Visualizza i dati aggregati sulle risorse del cluster con il pannello di controllo EKS](cluster-dashboard.md).
## Contesto
Amazon EKS utilizza i [ruoli collegati ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) di AWS Identity and Access Management (IAM). Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EKS. I ruoli collegati ai servizi sono definiti automaticamente da Amazon EKS e includono tutte le autorizzazioni richieste dal servizio per eseguire chiamate agli altri servizi AWS per conto dell'utente.
Un ruolo collegato ai servizi semplifica la configurazione di Amazon EKS perché consente di evitare l’aggiunta manuale delle autorizzazioni necessarie. Amazon EKS definisce le autorizzazioni del ruolo associato ai servizi e, salvo diversamente definito, solo Amazon EKS può assumerne il ruolo. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni che non può essere allegata a nessun'altra entità IAM.
È possibile eliminare un ruolo collegato ai servizi solo dopo aver eliminato le risorse correlate. Questa procedura protegge le risorse di Amazon EKS perché impedisce la rimozione involontaria delle autorizzazioni di accesso alle risorse.
Per informazioni sugli altri servizi che supportano i ruoli collegati ai servizi, consultare [Servizi AWS che funzionano con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cercare i servizi che riportano **Yes (Sì)** nella colonna **Service-linked roles (Ruoli collegati ai servizi)**. Scegli **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio.
## Autorizzazioni del ruolo collegato ai servizi per Amazon EKS
Amazon EKS usa il ruolo collegato ai servizi denominato `AWSServiceRoleForAmazonEKSDashboard`. Il ruolo consente ad Amazon EKS di generare e visualizzare la dashboard EKS, incluse informazioni aggregate sulle risorse del cluster. La policy `AmazonEKSDashboardServiceRolePolicy` allegata consente al ruolo di gestire le seguenti risorse: gruppi Auto Scaling, gruppi di sicurezza, modelli di avvio e profili dell’istanza IAM. Per ulteriori informazioni, consulta [AWS politica gestita: Amazon EKSDashboard ServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy).
Ai fini dell'assunzione del ruolo, il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKSDashboard` considera attendibili i seguenti servizi:
+ `dashboard.eks.amazonaws.com`
Per visualizzare la versione più recente del documento di policy JSON, consulta [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) nella Guida di riferimento sulle policy gestite da AWS.
Per consentire a un'entità IAM (come un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato ai servizi devi configurare le relative autorizzazioni. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente di IAM*.
## Creazione di un ruolo collegato ai servizi per Amazon EKS
Non hai bisogno di creare manualmente un ruolo collegato ai servizi. Quando è abilitata la dashboard o nella console AWS, Amazon EKS crea il ruolo collegato ai servizi.
Per ulteriori informazioni sull’abilitazione della dashboard EKS, consulta [Configurare l'integrazione di EKS Dashboard con AWS Organizations](cluster-dashboard-orgs.md).
**Importante**
Questo ruolo collegato al servizio può apparire nell'account, se è stata completata un'operazione in un altro servizio che utilizza le caratteristiche supportate da questo ruolo.
## Modifica di un ruolo collegato ai servizi per Amazon EKS
Amazon EKS non consente di modificare il ruolo collegato ai servizi `AWSServiceRoleForAmazonEKSDashboard`. Dopo aver creato un ruolo collegato al servizio, non potrai modificarne il nome perché varie entità potrebbero farvi riferimento. È possibile tuttavia modificarne la descrizione utilizzando IAM. Per ulteriori informazioni, consulta [Modifica di un ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) nella *Guida per l'utente di IAM*.
## Eliminazione di un ruolo collegato ai servizi per Amazon EKS
Se non è più necessario utilizzare una funzionalità o un servizio che richiede un ruolo collegato al servizio, ti consigliamo di eliminare il ruolo. In questo modo non sarà più presente un'entità non utilizzata che non viene monitorata e gestita attivamente. Tuttavia, è necessario effettuare la pulizia delle risorse associate al ruolo collegato ai servizi prima di poterlo eliminare manualmente.
### Pulizia di un ruolo collegato ai servizi
Prima di utilizzare IAM; per eliminare un ruolo collegato al servizio, è necessario prima rimuovere qualsiasi risorsa utilizzata dal ruolo.
**Nota**
Se il servizio Amazon EKS utilizza tale ruolo quando tenti di eliminare le risorse, è possibile che l'eliminazione non riesca. In questo caso, attendi alcuni minuti e quindi ripeti l'operazione.
Per ulteriori informazioni sulla disabilitazione della dashboard EKS, consulta [Configurare l'integrazione di EKS Dashboard con AWS Organizations](cluster-dashboard-orgs.md).
### Eliminazione manuale del ruolo collegato ai servizi
Utilizza la console IAM, la CLI di AWS o l'API AWS per eliminare il ruolo orientato ai servizi `AWSServiceRoleForAmazonEKSDashboard`. Per ulteriori informazioni, consulta [Eliminazione del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) nella *Guida per l'utente di IAM*.
## Regioni supportate per i ruoli collegati ai servizi di Amazon EKS
Amazon EKS supporta l'utilizzo di ruoli collegati ai servizi in tutte le Regioni in cui il servizio è disponibile. Per ulteriori informazioni, consulta la sezione [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html) (Endpoint e quote di servizio di Amazon EKS).
# Ruolo IAM di esecuzione del pod di Amazon EKS
Il ruolo di esecuzione di Amazon EKS Pod è necessario per eseguire Pods sull'infrastruttura AWS Fargate.
Quando il cluster crea Pods sull'infrastruttura AWS Fargate, i componenti in esecuzione sull'infrastruttura Fargate devono effettuare chiamate AWS APIs per conto dell'utente. In questo modo possono eseguire azioni come estrarre le immagini dei container da Amazon ECR o indirizzare i log ad altri AWS servizi. Il ruolo di esecuzione del pod Amazon EKS fornisce le autorizzazioni IAM per eseguire questa operazione.
Quando si crea un profilo Fargate, è necessario specificare un ruolo di esecuzione del pod per i componenti Amazon EKS che vengono eseguiti su infrastruttura Fargate utilizzando il profilo. Questo ruolo è aggiunto al [controllo di accesso basato sul ruolo](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) di Kubernetes del cluster per l’autorizzazione. Ciò consente al `kubelet` in esecuzione sull’infrastruttura Fargate di registrarsi con il cluster Amazon EKS in modo che possa essere visualizzato nel cluster come nodo.
**Nota**
Il profilo Fargate deve avere un ruolo IAM diverso rispetto ai gruppi di EC2 nodi Amazon.
**Importante**
I container in esecuzione nel pod Fargate non possono assumere le autorizzazioni IAM associate a un ruolo di esecuzione del pod. Per concedere ai contenitori del tuo Fargate Pod le autorizzazioni per accedere ad altri AWS servizi, devi utilizzare i [ruoli IAM per](iam-roles-for-service-accounts.md) gli account di servizio.
[Prima di creare un profilo Fargate, devi creare un ruolo IAM con Amazon. EKSFargate PodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html)
## Verificare la presenza di un ruolo di esecuzione del pod esistente configurato correttamente
Per verificare se l’account dispone già di un ruolo di esecuzione del pod Amazon EKS configurato correttamente, utilizzare la procedura indicata di seguito. Per prevenire il problema di sicurezza di un delegato confuso, è importante che il ruolo limiti l’accesso in base a `SourceArn`. È possibile modificare il ruolo di esecuzione secondo necessità per includere il supporto per i profili Fargate su altri cluster.
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Nella pagina **Ruoli**, cerca l'elenco dei ruoli per **Amazon EKSFargate PodExecutionRole**. Se il ruolo non esiste, consulta [Creazione del ruolo di esecuzione del pod Amazon EKS](#create-pod-execution-role) per crearlo. Se il ruolo è presente, selezionalo.
1. Nella EKSFargate PodExecutionRole pagina **Amazon**, procedi come segue:
1. Seleziona **Autorizzazioni**.
1. Assicurati che la policy gestita da **EKSFargatePodExecutionRolePolicyAmazon** Amazon sia associata al ruolo.
1. Scegli **Trust relationships (Relazioni di trust)**.
1. Seleziona **Edit trust policy** (Modifica policy di attendibilità).
1. Nella pagina **Edit trust policy** (Modifica policy di attendibilità), verifica che la relazione di attendibilità contenga la policy seguente e una riga per i profili Fargate nel cluster. In tal caso, scegli **Cancel** (Annulla).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
Se la policy corrisponde ma non contiene una riga che specifica i profili Fargate sul cluster, aggiungi la riga riportata di seguito nella parte superiore dell’oggetto `ArnLike`. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster, *111122223333* con l'ID dell'account e *my-cluster* con il nome del cluster.
```
"aws:SourceArn": "arn:aws: eks:region-code:111122223333:fargateprofile/my-cluster/*",
```
Se la policy non corrisponde, copia la policy precedente nel modulo e scegli **Update policy** (Aggiorna policy). Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster. Se desideri utilizzare lo stesso ruolo in tutte le AWS regioni del tuo account, sostituiscilo *region-code* con`*`. Sostituisci *111122223333* con il tuo ID account e *my-cluster* con il nome del cluster. Se vuoi usare lo stesso ruolo per tutti i cluster dell'account, sostituisci *my-cluster* con `*`.
## Creazione del ruolo di esecuzione del pod Amazon EKS
Se non disponi già del ruolo di esecuzione di Amazon EKS Pod per il tuo cluster, puoi utilizzare Console di gestione AWS o la AWS CLI per crearlo.
Console di gestione AWS
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Nella pagina **Ruoli**, seleziona **Crea ruolo**.
1. Nella pagina **Seleziona un’entità attendibile**, esegui le operazioni seguenti:
1. Nella sezione **Tipo di entità affidabile**, scegli ** AWS servizio**.
1. Dall'elenco a discesa **Casi d'uso per altri AWS servizi**, scegli **EKS**.
1. Scegli **EKS - Pod Fargate**.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Add permissions** (Aggiungi autorizzazioni), scegli **Next** (Successivo).
1. Nella pagina **Name, review, and create** (Assegna un nome, rivedi e crea), esegui le operazioni seguenti:
1. Per **Nome ruolo**, inserisci un nome univoco per il ruolo, ad esempio `AmazonEKSFargatePodExecutionRole`.
1. In **Aggiungi tag (facoltativo)**, aggiungi metadati al ruolo collegando i tag come coppie chiave-valore. Per ulteriori informazioni sull’utilizzo di tag in IAM, consulta la sezione [Tagging IAM resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) nella *Guida per l’utente di IAM*.
1. Scegli **Crea ruolo**.
1. Nella pagina **Ruoli**, cerca l'elenco dei ruoli per **Amazon EKSFargate PodExecutionRole**. Seleziona il ruolo.
1. Nella EKSFargate PodExecutionRole pagina **Amazon**, procedi come segue:
1. Scegli **Trust relationships (Relazioni di trust)**.
1. Seleziona **Edit trust policy** (Modifica policy di attendibilità).
1. Nella pagina **Modifica policy di attendibilità**, effettua le operazioni seguenti:
1. Copia e incolla il contenuto seguente nel modello **Modifica policy di attendibilità**. Sostituisci *region-code* con la AWS regione in cui si trova il cluster. Se desideri utilizzare lo stesso ruolo in tutte le AWS regioni del tuo account, sostituiscilo *region-code* con`*`. Sostituisci *111122223333* con il tuo ID account e *my-cluster* con il nome del cluster. Se vuoi usare lo stesso ruolo per tutti i cluster dell'account, sostituisci *my-cluster* con `*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Scegli **Aggiorna policy**.
AWS CLI
1. Copia e incolla il contenuto seguente in un file denominato `pod-execution-role-trust-policy.json`. Sostituisci *region-code* con la AWS regione in cui si trova il cluster. Se desideri utilizzare lo stesso ruolo in tutte le AWS regioni del tuo account, sostituiscilo *region-code* con`*`. Sostituisci *111122223333* con il tuo ID account e *my-cluster* con il nome del cluster. Se vuoi usare lo stesso ruolo per tutti i cluster dell'account, sostituisci *my-cluster* con `*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Creare un ruolo IAM di esecuzione del pod.
```
aws iam create-role \
--role-name AmazonEKSFargatePodExecutionRole \
--assume-role-policy-document file://"pod-execution-role-trust-policy.json"
```
1. Allega la policy IAM gestita da Amazon EKS richiesta al ruolo.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy \
--role-name AmazonEKSFargatePodExecutionRole
```
# Ruolo IAM di Amazon EKS Connector
Puoi connettere i cluster Kubernetes per visualizzarli nel tuo. Console di gestione AWS Per collegarsi a un cluster Kubernetes, creare un ruolo IAM.
## Verificare la presenza di un ruolo del connettore EKS esistente
Per controllare se l'account dispone già di un ruolo di Amazon EKS Connector, utilizzare la procedura indicata di seguito.
1. Apri la console IAM all'indirizzo. https://console.aws.amazon.com/iam/
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Cerca l’elenco dei ruoli per `AmazonEKSConnectorAgentRole`. Se un ruolo che include `AmazonEKSConnectorAgentRole` non esiste, consultare [Creazione del ruolo agente di Amazon EKS Connector](#create-connector-role) per crearlo. Se un ruolo che include `AmazonEKSConnectorAgentRole` esiste, seleziona il ruolo per visualizzare le policy allegate.
1. Selezionare **Autorizzazioni**.
1. Assicurati che la policy EKSConnector AgentPolicy gestita da **Amazon** sia associata al ruolo. Se la policy è collegata, il ruolo del connettore Amazon EKS è configurato correttamente.
1. Scegliere **Relazioni di attendibilità**, quindi scegliere **Modifica policy di attendibilità**.
1. Verifica che la relazione di trust includa la policy seguente. Se la relazione di attendibilità corrisponde alla policy seguente, scegli **Annulla**. Se la relazione di attendibilità non corrisponde, copia la policy nella finestra **Modifica policy di attendibilità** e scegli **Aggiorna policy**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Creazione del ruolo agente di Amazon EKS Connector
Puoi usare Console di gestione AWS o AWS CloudFormation per creare il ruolo di agente del connettore.
AWS CLI
1. Creare un file denominato `eks-connector-agent-trust-policy.json` contenente il seguente JSON da utilizzare per il ruolo IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Creare un file denominato `eks-connector-agent-policy.json` contenente il seguente JSON da utilizzare per il ruolo IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SsmControlChannel",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel"
],
"Resource": "arn:aws:eks:*:*:cluster/*"
},
{
"Sid": "ssmDataplaneOperations",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenDataChannel",
"ssmmessages:OpenControlChannel"
],
"Resource": "*"
}
]
}
```
1. Crea il ruolo agente di Amazon EKS Connector utilizzando la policy di attendibilità e la policy creata negli elementi precedenti dell'elenco.
```
aws iam create-role \
--role-name AmazonEKSConnectorAgentRole \
--assume-role-policy-document file://eks-connector-agent-trust-policy.json
```
1. Allegare la policy al ruolo agente di Amazon EKS Connector.
```
aws iam put-role-policy \
--role-name AmazonEKSConnectorAgentRole \
--policy-name AmazonEKSConnectorAgentPolicy \
--policy-document file://eks-connector-agent-policy.json
```
AWS CloudFormation
1. Salvate il seguente AWS CloudFormation modello in un file di testo sul vostro sistema locale.
**Nota**
Questo modello crea anche il ruolo collegato al servizio che altrimenti verrebbe stato creato al momento della chiamata API `registerCluster`. Per informazioni dettagliate, vedi [Utilizzo di ruoli per connettere un cluster Kubernetes ad Amazon EKS](using-service-linked-roles-eks-connector.md).
```
---
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Provisions necessary resources needed to register clusters in EKS'
Parameters: {}
Resources:
EKSConnectorSLR:
Type: AWS::IAM::ServiceLinkedRole
Properties:
AWSServiceName: eks-connector.amazonaws.com
EKSConnectorAgentRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: [ 'sts:AssumeRole' ]
Principal:
Service: 'ssm.amazonaws.com'
EKSConnectorAgentPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: EKSConnectorAgentPolicy
Roles:
- {Ref: 'EKSConnectorAgentRole'}
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateControlChannel' ]
Resource:
- Fn::Sub: 'arn:${AWS::Partition}:eks:*:*:cluster/*'
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateDataChannel', 'ssmmessages:OpenDataChannel', 'ssmmessages:OpenControlChannel' ]
Resource: "*"
Outputs:
EKSConnectorAgentRoleArn:
Description: The agent role that EKS connector uses to communicate with AWS services.
Value: !GetAtt EKSConnectorAgentRole.Arn
```
1. Apri la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).
1. Scegliere **Crea stack** Con nuove risorse (standard).
1. In **Specify template (Specifica modello)**, selezionare **Upload a template file (Carica un file di modello)** e **Choose file (Scegli file)**.
1. Scegliere il file creato in precedenza, quindi selezionare **Next (Successivo)**.
1. Per **Stack name (Nome pila)**, immettere un nome per il ruolo, ad esempio `eksConnectorAgentRole`, quindi scegliere **Next (Successivo)**.
1. Nella pagina **Configure stack options (Configura opzioni pila)**, scegliere **Next (Successivo)**.
1. Nella pagina **Revisione**, esaminare le informazioni, accettare che la pila può creare risorse IAM, quindi scegliere **Crea pila**.
# AWS politiche gestite per Amazon Elastic Kubernetes Service
Una politica AWS gestita è una politica autonoma creata e amministrata da AWS. AWS le politiche gestite sono progettate per fornire autorizzazioni per molti casi d'uso comuni, in modo da poter iniziare ad assegnare autorizzazioni a utenti, gruppi e ruoli.
Tieni presente che le policy AWS gestite potrebbero non concedere le autorizzazioni con il privilegio minimo per i tuoi casi d'uso specifici, poiché sono disponibili per tutti i clienti. AWS Si consiglia pertanto di ridurre ulteriormente le autorizzazioni definendo [policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) specifiche per i propri casi d'uso.
Non è possibile modificare le autorizzazioni definite nelle politiche gestite. AWS Se AWS aggiorna le autorizzazioni definite in una politica AWS gestita, l'aggiornamento ha effetto su tutte le identità principali (utenti, gruppi e ruoli) a cui è associata la politica. AWS è più probabile che aggiorni una policy AWS gestita quando viene lanciato un nuovo AWS servizio o quando nuove operazioni API diventano disponibili per i servizi esistenti.
Per ulteriori informazioni, consultare [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) nella *Guida per l'utente di IAM*.
## AWS politica gestita: Amazoneks\$1CNI\$1Policy
É possibile allegare la `AmazonEKS_CNI_Policy` alle entità IAM. Prima di creare un gruppo di nodi Amazon EC2, questa policy deve essere allegata al[ ruolo IAM del nodo](create-node-role.md), o a un ruolo IAM che è utilizzato in modo specifico dal plugin CNI di Amazon VPC per Kubernetes. In questo modo può eseguire operazioni per conto dell'utente. Si consiglia di allegare le policy a un ruolo utilizzato solo dal plugin. Per ulteriori informazioni, consultare [Assegna IPs ai pod con Amazon VPC CNI](managing-vpc-cni.md) e [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md).
**Dettagli dell'autorizzazione**
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le attività seguenti:
+ ** `ec2:*NetworkInterface` e `ec2:*PrivateIpAddresses` **: consente al plugin CNI di Amazon VPC di eseguire azioni come il provisioning di interfacce di rete elastiche e indirizzi IP per i pod, così da fornire una rete per le applicazioni eseguite in Amazon EKS.
+ **Azioni di lettura `ec2`**: consente al plugin CNI di Amazon VPC di eseguire azioni come descrivere istanze e sottoreti, così da visualizzare la quantità di indirizzi IP gratuiti nelle sottoreti Amazon VPC. Il CNI di VPC può utilizzare gli indirizzi IP gratuiti in ciascuna sottorete per scegliere le sottoreti con gli indirizzi IP più liberi da utilizzare durante la creazione di un’interfaccia di rete elastica.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazoneks\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html#AmazonEKS_CNI_Policy-json) nella Managed Policy Reference Guide. AWS
## AWS politica gestita: Amazon EKSCluster Policy
È possibile allegare `AmazonEKSClusterPolicy` alle entità IAM. Prima di creare un cluster, è necessario disporre di un [ruolo IAM del cluster](cluster-iam-role.md) con questa policy allegata. I cluster Kubernetes gestiti da Amazon EKS effettuano chiamate verso altri AWS servizi per tuo conto. Ciò serve a gestire le risorse utilizzate con il servizio.
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le attività seguenti:
+ ** `autoscaling` **: leggi e aggiorna la configurazione di un gruppo Auto Scaling. Queste autorizzazioni non sono utilizzate da Amazon EKS, ma rimangono nella policy per la compatibilità con le versioni precedenti.
+ ** `ec2` **: lavora con volumi e risorse di rete associati ai nodi Amazon EC2. Ciò è necessario affinché il piano di controllo (control-plane) Kubernetes possa unire le istanze a un cluster ed eseguire dinamicamente il provisioning e la gestione dei volumi Amazon EBS richiesti dai volumi persistenti di Kubernetes.
+ ** `ec2` **: elimina le interfacce di rete elastiche create da CNI di VPC. Ciò è necessario affinché EKS possa ripulire le interfacce di rete elastiche che rimangono se CNI di VPC si chiude inaspettatamente.
+ ** `elasticloadbalancing` **: lavora con Elastic Load Balancers e aggiunge nodi come destinazioni. Ciò è necessario affinché il piano di controllo Kubernetes possa eseguire dinamicamente il provisioning degli Elastic Load Balancers (load balancer Elastico) richiesti dai servizi Kubernetes.
+ ** `iam` **: crea un ruolo collegato ai servizi. Ciò è necessario affinché il piano di controllo (control-plane) Kubernetes possa eseguire dinamicamente il provisioning degli Elastic Load Balancer richiesti dai servizi Kubernetes.
+ **`kms`**— Leggi una chiave da KMS. AWS Questa attività è necessaria affinché il piano di controllo (control-plane) Kubernetes supporti la [crittografia dei segreti](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) di Kubernetes archiviati in `etcd`.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSCluster Policy nella AWS Managed Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) Reference Guide.
## AWS politica gestita: Amazon EKSDashboard ConsoleReadOnly
È possibile collegare `AmazonEKSDashboardConsoleReadOnly` alle entità IAM.
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le attività seguenti:
+ ** `eks` **: accesso in sola lettura ai dati, alle risorse e alle informazioni sulle versioni del cluster della dashboard EKS. Ciò consente di visualizzare le metriche relative a EKS e i dettagli di configurazione del cluster.
+ **`organizations`**- Accesso in sola lettura alle informazioni di AWS Organizations, tra cui:
+ visualizzazione dei dettagli dell’organizzazione e dell’accesso al servizio
+ elenco delle root organizzative, degli account e delle unità organizzative
+ Visualizzazione della struttura dell’organizzazione
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSDashboard ConsoleReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardConsoleReadOnly.html#AmazonEKSDashboardConsoleReadOnly-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSFargate PodExecutionRolePolicy
È possibile allegare `AmazonEKSFargatePodExecutionRolePolicy` alle entità IAM. Prima di poter creare un profilo Fargate, è necessario creare un ruolo di esecuzione del pod Fargate e allegare questa policy ad esso. Per ulteriori informazioni, consultare [Fase 2: creare un ruolo di esecuzione del pod Fargate](fargate-getting-started.md#fargate-sg-pod-execution-role) e [Definisci quali pod utilizzano AWS Fargate durante l’avvio](fargate-profile.md).
Questa politica concede al ruolo le autorizzazioni che forniscono l'accesso ad altre risorse di AWS servizio necessarie per eseguire Amazon EKS Pods su Fargate.
**Dettagli dell'autorizzazione**
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le attività seguenti:
+ ** `ecr` **: consente ai pod in esecuzione su Fargate di estrarre le immagini del container memorizzate in Amazon ECR.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSFargate PodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html#AmazonEKSFargatePodExecutionRolePolicy-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSConnector ServiceRolePolicy
Non è possibile allegare `AmazonEKSConnectorServiceRolePolicy` alle entità IAM. Questa policy è allegata a un ruolo collegato ai servizi che consente ad Amazon EKS di eseguire operazioni per conto dell'utente. Per ulteriori informazioni, consulta [Utilizzo di ruoli per connettere un cluster Kubernetes ad Amazon EKS](using-service-linked-roles-eks-connector.md).
Il ruolo consente ad Amazon EKS di collegarsi ai cluster Kubernetes. Le policy allegate consentono al ruolo di gestire le risorse necessarie per connettersi al cluster Kubernetes registrato.
**Dettagli dell'autorizzazione**
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le seguenti attività.
+ **`SSM Management`**— Crea, descrivi ed elimina le attivazioni SSM e annulla la registrazione delle istanze gestite. Ciò consente le operazioni di base di Systems Manager.
+ **`Session Management`**— Avvia sessioni SSM specifiche per i cluster EKS ed esegui comandi non interattivi utilizzando il documento AmazonEks.
+ **`IAM Role Passing`**— Passa i ruoli IAM specificamente al servizio SSM, controllato da una condizione che limita i ruoli passati a. `ssm.amazonaws.com`
+ **`EventBridge Rules`**— Crea EventBridge regole e obiettivi, ma solo se gestiti da. `eks-connector.amazonaws.com` Le regole sono specificamente limitate a AWS SSM come fonte dell'evento.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSConnector ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSFor FargateServiceRolePolicy
Non è possibile allegare `AmazonEKSForFargateServiceRolePolicy` alle entità IAM. Questa policy è allegata a un ruolo collegato ai servizi che consente ad Amazon EKS di eseguire operazioni per conto dell'utente. Per ulteriori informazioni, consulta `AWSServiceRoleforAmazonEKSForFargate`.
Questa policy concede ad Amazon EKS le autorizzazioni necessarie per eseguire le attività di Fargate. La policy viene utilizzato solo se si dispone di nodi Fargate.
**Dettagli dell'autorizzazione**
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le seguenti attività.
+ ** `ec2` **: crea ed elimina interfacce di rete elastiche e descrive le interfacce di rete elastiche e le risorse. Questa operazione è necessaria affinché il servizio Fargate di Amazon EKS possa configurare la rete VPC necessaria per i pod Fargate.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSFor FargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html#AmazonEKSForFargateServiceRolePolicy-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSCompute Policy
È possibile collegare `AmazonEKSComputePolicy` alle entità IAM. È possibile allegare questa policy al [ruolo IAM del cluster](cluster-iam-role.md) per espandere le risorse che EKS può gestire nel tuo account.
Questa policy concede le autorizzazioni necessarie ad Amazon EKS per creare e gestire istanze EC2 per il cluster EKS e le autorizzazioni IAM necessarie per configurare EC2. Inoltre, questa policy concede ad Amazon EKS le autorizzazioni per creare il ruolo collegato al servizio Spot EC2 per conto dell’utente.
### Dettagli dell'autorizzazione
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le attività seguenti:
+ **Autorizzazioni`ec2` **:
+ `ec2:CreateFleet` e `ec2:RunInstances`: consente la creazione di istanze EC2 e l’utilizzo di risorse EC2 specifiche (immagini, gruppi di sicurezza, sottoreti) per i nodi del cluster EKS.
+ `ec2:CreateLaunchTemplate`: consente di creare modelli di lancio EC2 per i nodi del cluster EKS.
+ La policy include anche condizioni per limitare l’utilizzo di queste autorizzazioni EC2 alle risorse contrassegnate con il nome del cluster EKS e altri tag pertinenti.
+ `ec2:CreateTags`: consente di aggiungere tag alle risorse EC2 create dalle azioni `CreateFleet`, `RunInstances` e `CreateLaunchTemplate`.
+ **Autorizzazioni `iam`**:
+ `iam:AddRoleToInstanceProfile`: consente di aggiungere un ruolo IAM al profilo dell’istanza di calcolo EKS.
+ `iam:PassRole`: consente di passare i ruoli IAM necessari al servizio EC2.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSCompute Policy nella AWS Managed Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSComputePolicy.html#AmazonEKSComputePolicy-json) Reference Guide.
## AWS politica gestita: Amazon EKSNetworking Policy
È possibile collegare `AmazonEKSNetworkingPolicy` alle entità IAM. È possibile allegare questa policy al [ruolo IAM del cluster](cluster-iam-role.md) per espandere le risorse che EKS può gestire nel tuo account.
Questa policy è progettata per concedere le autorizzazioni necessarie ad Amazon EKS per creare e gestire interfacce di rete per il cluster EKS, consentendo al piano di controllo e ai nodi worker di comunicare e funzionare correttamente.
### Dettagli delle autorizzazioni
Questa policy concede le seguenti autorizzazioni per consentire ad Amazon EKS di gestire le interfacce di rete per il cluster:
+ ** Autorizzazioni dell’interfaccia di rete `ec2`**
+ `ec2:CreateNetworkInterface`: consente la creazione di interfacce di rete EC2.
+ La policy include condizioni per limitare l’utilizzo di questa autorizzazione alle interfacce di rete contrassegnate con il nome del cluster EKS e il nome del nodo CNI di Kubernetes.
+ `ec2:CreateTags`: consente di aggiungere tag alle interfacce di rete create dall’azione `CreateNetworkInterface`.
+ **Autorizzazioni di gestione delle interfacce di rete `ec2`**:
+ `ec2:AttachNetworkInterface`,`ec2:ModifyNetworkInterfaceAttribute`, `ec2:DetachNetworkInterface` - Consente di collegare e modificare gli attributi dell'interfaccia di rete e di scollegare le interfacce di rete alle istanze EC2.
+ `ec2:UnassignPrivateIpAddresses`, `ec2:UnassignIpv6Addresses`, `ec2:AssignPrivateIpAddresses`, `ec2:AssignIpv6Addresses`: consente di gestire le assegnazioni degli indirizzi IP delle interfacce di rete.
+ Tali autorizzazioni sono limitate alle interfacce di rete contrassegnate con il nome del cluster EKS.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSNetworking Policy nella AWS Managed Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSNetworkingPolicy.html#AmazonEKSNetworkingPolicy-json) Reference Guide.
## AWS politica gestita: Amazon EKSBlock StoragePolicy
È possibile collegare `AmazonEKSBlockStoragePolicy` alle entità IAM. È possibile allegare questa policy al [ruolo IAM del cluster](cluster-iam-role.md) per espandere le risorse che EKS può gestire nel tuo account.
Questa policy concede le autorizzazioni necessarie ad Amazon EKS per creare, gestire e mantenere volumi e snapshot EC2 per il cluster EKS, consentendo al piano di controllo e ai nodi worker di fornire e utilizzare l’archiviazione persistente come richiesto dai carichi di lavoro Kubernetes.
### Dettagli delle autorizzazioni
Questa policy IAM concede le seguenti autorizzazioni per consentire ad Amazon EKS di gestire volumi e snapshot EC2:
+ **Autorizzazioni per la gestione dei volumi `ec2`**:
+ `ec2:AttachVolume`, `ec2:DetachVolume`, `ec2:ModifyVolume`, `ec2:EnableFastSnapshotRestores`: consente di allegare, scollegare, modificare e abilitare ripristini rapidi di snapshot per i volumi EC2.
+ Queste autorizzazioni sono limitate ai volumi contrassegnati con il nome del cluster EKS.
+ `ec2:CreateTags`: consente di aggiungere tag ai volumi e agli snapshot di EC2 creati dalle azioni `CreateVolume` e `CreateSnapshot`.
+ **Autorizzazioni per la creazione di volumi `ec2`**:
+ `ec2:CreateVolume`: consente la creazione di nuovi volumi EC2.
+ La policy include condizioni per limitare l’utilizzo di questa autorizzazione a volumi contrassegnati con il nome del cluster EKS e altri tag pertinenti.
+ `ec2:CreateSnapshot`: consente la creazione di nuovi snapshot di volumi EC2.
+ La policy include condizioni per limitare l’utilizzo di questa autorizzazione agli snapshot contrassegnati con il nome del cluster EKS e altri tag pertinenti.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSBlock StoragePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSBlockStoragePolicy.html#AmazonEKSBlockStoragePolicy-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSLoad BalancingPolicy
È possibile collegare `AmazonEKSLoadBalancingPolicy` alle entità IAM. È possibile allegare questa policy al [ruolo IAM del cluster](cluster-iam-role.md) per espandere le risorse che EKS può gestire nel tuo account.
Questa policy IAM concede le autorizzazioni necessarie ad Amazon EKS per lavorare con vari AWS servizi per gestire Elastic Load Balancers (ELBs) e risorse correlate.
### Dettagli delle autorizzazioni
Le autorizzazioni principali concesse da questa policy sono:
+ ** `elasticloadbalancing` **: consente di creare, modificare e gestire Elastic Load Balancer e gruppi di destinazione. Ciò include le autorizzazioni per creare, aggiornare ed eliminare bilanciatori del carico, gruppi di destinazione, listener e regole.
+ ** `ec2` **: consente di creare e gestire gruppi di sicurezza, necessari al piano di controllo Kubernetes per unire le istanze a un cluster e gestire i volumi Amazon EBS. Consente inoltre di descrivere ed elencare risorse EC2 come istanze, sottoreti VPCs, gruppi di sicurezza e altre risorse di rete.
+ **`iam`**: consente di creare un ruolo collegato al servizio per Elastic Load Balancing, necessario per il provisioning dinamico del piano di controllo di Kubernetes. ELBs
+ **`kms`**: Consente la lettura di una chiave da AWS KMS, necessaria affinché il piano di controllo di Kubernetes supporti la crittografia dei segreti Kubernetes archiviati in etcd.
+ **`wafv2`**e **`shield`**: Consente di associare e dissociare Web e di ACLs creare/eliminare le protezioni AWS Shield per Elastic Load Balancers.
+ ** `cognito-idp` **, ** `acm` ** e ** `elasticloadbalancing` **: concede le autorizzazioni per descrivere i client del pool di utenti, elencare e descrivere i certificati, e descrivere i gruppi di destinazione, necessari al piano di controllo di Kubernetes per gestire gli Elastic Load Balancer.
La policy include anche diversi controlli delle condizioni per garantire che le autorizzazioni rientrino nell’ambito dello specifico cluster EKS gestito, utilizzando il tag `eks:eks-cluster-name`.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSLoad BalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html#AmazonEKSLoadBalancingPolicy-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSMCPRead OnlyAccess
È possibile collegare `AmazonEKSMCPReadOnlyAccess` alle entità IAM. Questa policy fornisce l'accesso in sola lettura alle risorse di Amazon EKS e ai AWS servizi correlati, consentendo al server Amazon EKS Model Context Protocol (MCP) di eseguire operazioni di osservabilità e risoluzione dei problemi senza apportare modifiche all'infrastruttura.
**Dettagli delle autorizzazioni**
Questa politica include le seguenti autorizzazioni che consentono ai responsabili di completare le seguenti attività:
+ **`eks`**Consente ai responsabili di descrivere ed elencare cluster EKS, gruppi di nodi, componenti aggiuntivi, voci di accesso, approfondimenti e accedere all'API Kubernetes per operazioni di sola lettura.
+ **`iam`**Consente ai responsabili di recuperare informazioni sui ruoli, le policy e i relativi allegati IAM per comprendere le autorizzazioni associate alle risorse EKS.
+ **`ec2`**Consente ai principali di descrivere VPCs, alle sottoreti e alle tabelle di routing per comprendere la configurazione di rete dei cluster EKS.
+ **`sts`**Consente ai responsabili di recuperare le informazioni sull'identità del chiamante per scopi di autenticazione e autorizzazione.
+ **`logs`**Consente ai responsabili di avviare query e recuperare i risultati delle query dai CloudWatch registri per la risoluzione dei problemi e il monitoraggio.
+ **`cloudwatch`**Consente ai responsabili di recuperare i dati metrici per il monitoraggio delle prestazioni del cluster e del carico di lavoro.
+ **`eks-mcp`**Consente ai responsabili di richiamare operazioni MCP e richiamare strumenti di sola lettura all'interno del server MCP Amazon EKS.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSMCPRead OnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSService Policy
È possibile collegare `AmazonEKSServicePolicy` alle entità IAM. I cluster creati prima del 16 aprile 2020 richiedono all'utente di creare un ruolo IAM e allegarvi questa policy. I cluster creati a partire dal 16 aprile 2020 non richiedono la creazione di un ruolo e non richiedono l’assegnazione di questa policy. Quando crei un cluster utilizzando un principale IAM che dispone dell'`iam:CreateServiceLinkedRole`autorizzazione, il ruolo [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) collegato ai servizi viene creato automaticamente per te. Al ruolo collegato ai servizi è EKSService RolePolicy associata la [policy gestita: Amazon](#security-iam-awsmanpol-amazoneksservicerolepolicy).
Questa policy consente ad Amazon EKS di creare e gestire le risorse necessarie per gestire i cluster Amazon EKS.
**Dettagli dell'autorizzazione**
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le seguenti attività.
+ ** `eks` **: aggiorna la versione Kubernetes del cluster dopo aver avviato un aggiornamento. Questa autorizzazione non è utilizzata da Amazon EKS, ma rimane nella policy per la compatibilità con le versioni precedenti.
+ ** `ec2` **: lavora con le interfacce di rete elastiche e altre risorse e tag di rete. Ciò è richiesto da Amazon EKS per configurare la rete che facilita la comunicazione tra i nodi e il piano di controllo Kubernetes. Leggi le informazioni sui gruppi di sicurezza. Aggiorna i tag sui gruppi di sicurezza.
+ ** `route53` **: associa un VPC a una zona ospitata. Ciò è richiesto da Amazon EKS per abilitare la rete di endpoint privati per il server API del cluster Kubernetes.
+ ** `logs` **: registra eventi. Ciò è necessario per consentire ad Amazon EKS di spedire i log del piano di controllo Kubernetes a. CloudWatch
+ ** `iam` **: crea un ruolo collegato ai servizi. Questa operazione è necessaria affinché Amazon EKS possa creare il ruolo collegato al servizio [Autorizzazioni del ruolo collegato ai servizi per Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) per conto dell'utente.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSService Policy nella AWS Managed Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html#AmazonEKSServicePolicy-json) Reference Guide.
## AWS politica gestita: Amazon EKSService RolePolicy
Non è possibile allegare `AmazonEKSServiceRolePolicy` alle entità IAM. Questa policy è allegata a un ruolo collegato ai servizi che consente ad Amazon EKS di eseguire operazioni per conto dell'utente. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi per Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks). Quando crei un cluster utilizzando un principale IAM che dispone dell'`iam:CreateServiceLinkedRole`autorizzazione, il ruolo [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) collegato ai servizi viene creato automaticamente per te e questa policy gli viene allegata.
Questa policy consente al ruolo collegato al servizio di chiamare i AWS servizi per tuo conto.
**Dettagli dell'autorizzazione**
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le seguenti attività.
+ ** `ec2` **: crea e descrive le interfacce di rete elastiche e le istanze di Amazon EC2, il gruppo di sicurezza del cluster e i VPC necessari per la creazione del cluster. Per ulteriori informazioni, consulta [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md). Leggi le informazioni sui gruppi di sicurezza. Aggiorna i tag sui gruppi di sicurezza. Leggi informazioni sulle prenotazioni della capacità on demand. Leggi la configurazione del VPC, comprese le tabelle di routing e la rete, ACLs per rilevare i problemi di configurazione nell'ambito di Cluster Insights.
+ **Modalità automatica `ec2`**: termina le istanze EC2 create dalla modalità automatica EKS. Per ulteriori informazioni, consulta [Automate cluster infrastructure with EKS Auto Mode](automode.md).
+ ** `iam` **: elenca tutti i criteri gestiti allegati a un ruolo IAM. Ciò è necessario affinché Amazon EKS possa pubblicare e convalidare tutte le politiche gestite e le autorizzazioni necessarie per la creazione di un cluster.
+ **Associa un VPC a una zona ospitata**. Ciò è richiesto da Amazon EKS per abilitare la rete di endpoint privati per il server API del cluster Kubernetes.
+ **Evento di registro**: è necessario per consentire ad Amazon EKS di inviare i log del piano di controllo Kubernetes a. CloudWatch
+ **Metrica metrica**: è necessaria per consentire ad Amazon EKS di inviare i log del piano di controllo Kubernetes a. CloudWatch
+ ** `eks` **: gestisci le voci e le politiche di accesso ai cluster, permettendo un controllo granulare su chi può accedere alle risorse EKS e quali azioni può eseguire. Ciò include l’associazione di policy di accesso standard per operazioni di elaborazione, rete, bilanciamento del carico e archiviazione.
+ ** `elasticloadbalancing` **: crea, gestisci ed elimina i bilanciatori del carico e i relativi componenti (listener, gruppi di destinazione, certificati) associati ai cluster EKS. Visualizza gli attributi e lo stato di integrità del bilanciatore del carico.
+ **`events`**- Crea e gestisci EventBridge regole per il monitoraggio degli eventi EC2 e AWS Health relativi ai cluster EKS, abilitando risposte automatiche ai cambiamenti dell'infrastruttura e agli avvisi sullo stato.
+ ** `iam` **: gestisci i profili delle istanze EC2 con il prefisso “eks”, inclusa la creazione, l’eliminazione e l’associazione dei ruoli, necessarie per la gestione dei nodi EKS. Consente di descrivere qualsiasi profilo di istanza per consentire agli utenti di definire profili di istanza personalizzati da utilizzare per i nodi di lavoro.
+ **`pricing`**`shield`****- Accedi alle informazioni AWS sui prezzi e allo stato di protezione Shield, abilitando la gestione dei costi e funzionalità di sicurezza avanzate per le risorse EKS.
+ **Pulizia delle risorse**: elimina in modo sicuro le risorse con tag EKS, inclusi volumi, snapshot, modelli di avvio e interfacce di rete durante le operazioni di pulizia dei cluster.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSService RolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html#AmazonEKSServiceRolePolicy-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSVPCResource Controller
È possibile allegare la policy `AmazonEKSVPCResourceController` alle identità IAM. Se utilizzi [gruppi di sicurezza per pod](security-groups-for-pods.md), dovrai allegare questa policy al [ruolo IAM del cluster Amazon EKS](cluster-iam-role.md) perché possa eseguire operazioni per tuo conto.
Questa policy concede le autorizzazioni del ruolo cluster per gestire le interfacce di rete elastiche e gli indirizzi IP per i nodi.
**Dettagli dell'autorizzazione**
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le attività seguenti:
+ ** `ec2` **: gestisci le interfacce di rete elastiche e gli indirizzi IP per supportare i gruppi di sicurezza dei pod e i nodi Windows.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSVPCResource Controller](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html#AmazonEKSVPCResourceController-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSWorker NodePolicy
É possibile allegare la `AmazonEKSWorkerNodePolicy` alle entità IAM. È necessario allegare questa policy a un [Ruolo IAM del nodo](create-node-role.md) che va specificato quando si creano nodi Amazon EC2 che consentono ad Amazon EKS di eseguire operazioni per conto dell'utente. Se si crea un gruppo di nodi utilizzando `eksctl`, si crea il ruolo IAM del nodo e si allega automaticamente questa policy al ruolo.
Questa policy concede ai nodi Amazon EKS Amazon EC2 le autorizzazioni per connettersi ai cluster Amazon EKS.
**Dettagli dell'autorizzazione**
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le attività seguenti:
+ ** `ec2` **: leggi le informazioni sul volume dell’istanza e sulla rete. Ciò è necessario affinché i nodi Kubernetes possano descrivere le informazioni sulle risorse Amazon EC2 necessarie per l'unione del nodo al cluster Amazon EKS.
+ ** `eks` **: descrivi in modo facoltativo il cluster come parte del bootstrap del nodo.
+ ** `eks-auth:AssumeRoleForPodIdentity` **: consenti il recupero delle credenziali per i carichi di lavoro EKS sul nodo. Ciò è necessario per il funzionamento di EKS Pod Identity.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html#AmazonEKSWorkerNodePolicy-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSWorker NodeMinimalPolicy
Puoi collegare WorkerNodeMinimalPolicy AmazonEks alle tue entità IAM. È necessario allegare questa policy a un ruolo IAM del nodo che deve essere specificato quando si creano nodi Amazon EC2 che consentono ad Amazon EKS di eseguire operazioni per conto dell’utente.
Questa policy concede ai nodi Amazon EKS Amazon EC2 le autorizzazioni per connettersi ai cluster Amazon EKS. Questa politica ha meno autorizzazioni rispetto ad Amazon EKSWorkerNodePolicy.
**Dettagli dell'autorizzazione**
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le attività seguenti:
+ `eks-auth:AssumeRoleForPodIdentity`: consenti il recupero delle credenziali per i carichi di lavoro EKS sul nodo. Ciò è necessario per il funzionamento di EKS Pod Identity.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodeMinimalPolicy.html#AmazonEKSWorkerNodeMinimalPolicy-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: AWSService RoleForAmazon EKSNodegroup
Non è possibile allegare `AWSServiceRoleForAmazonEKSNodegroup` alle entità IAM. Questa policy è allegata a un ruolo collegato ai servizi che consente ad Amazon EKS di eseguire operazioni per conto dell'utente. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi per Amazon EKS](using-service-linked-roles-eks-nodegroups.md#service-linked-role-permissions-eks-nodegroups).
Questa policy concede l'autorizzazione ai ruoli `AWSServiceRoleForAmazonEKSNodegroup` che consentono di creare e gestire gruppi di nodi Amazon EC2 nell'account.
**Dettagli dell'autorizzazione**
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le attività seguenti:
+ ** `ec2` **: lavora con gruppi di sicurezza, tag, prenotazioni della capacità e modelli di avvio. Ciò è necessario per i gruppi di nodi gestiti da Amazon EKS per abilitare la configurazione dell’accesso remoto e descrivere le prenotazioni della capacità che possono essere utilizzate nei gruppi di nodi gestiti. Inoltre, i gruppi di nodi gestiti da Amazon EKS creano un modello di avvio per conto dell'utente. Questo consente di configurare il gruppo Amazon EC2 Auto Scaling che supporta ogni gruppo di nodi gestito.
+ ** `iam` **: crea un ruolo collegato ai servizi e passa un ruolo. Ciò è richiesto dai gruppi di nodi gestiti da Amazon EKS per gestire i profili di istanza per il ruolo passato durante la creazione di un gruppo di nodi gestito. Questo profilo dell'istanza viene utilizzato dalle istanze Amazon EC2 avviate come parte di un gruppo di nodi gestito. Amazon EKS deve creare ruoli collegati al servizio per altri servizi come, ad esempio i gruppi di Amazon EC2 Auto Scaling. Queste autorizzazioni vengono utilizzate nella creazione di un gruppo di nodi gestito.
+ ** `autoscaling` **: lavora con gruppi Auto Scaling di sicurezza. Questo è richiesto dai gruppi di nodi gestiti da Amazon EKS per gestire il gruppo di Amazon EC2 Auto Scaling che supporta ciascun gruppo di nodi gestito. Viene anche utilizzato per supportare funzionalità come l'eliminazione dei Pod quando i nodi vengono terminati o il riciclo durante gli aggiornamenti dei gruppi di nodi e la gestione dei pool caldi configurati su gruppi di nodi gestiti.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta la Managed Policy Reference Guide [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html#AWSServiceRoleForAmazonEKSNodegroup-json). AWS
## AWS politica gestita: Amazon EKSDashboard ServiceRolePolicy
Non è possibile allegare `AmazonEKSDashboardServiceRolePolicy` alle entità IAM. Questa policy è allegata a un ruolo collegato ai servizi che consente ad Amazon EKS di eseguire operazioni per conto dell'utente. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi per Amazon EKS](using-service-linked-roles-eks-dashboard.md#service-linked-role-permissions-eks-dashboard).
Questa policy concede l'autorizzazione ai ruoli `AWSServiceRoleForAmazonEKSDashboard` che consentono di creare e gestire gruppi di nodi Amazon EC2 nell'account.
**Dettagli dell'autorizzazione**
Questa policy include le seguenti autorizzazioni che consentono ad Amazon EKS di completare le attività seguenti:
+ **`organizations`**— Visualizza le informazioni sulla struttura e gli account della tua AWS Organizations. Ciò include le autorizzazioni per elencare gli account dell’organizzazione, visualizzare le unità organizzative e le root, elencare gli amministratori delegati, visualizzare i servizi che hanno accesso all’organizzazione e recuperare informazioni dettagliate sull’organizzazione e sugli account.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSDashboard ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EBSCSIDriver Policy
La `AmazonEBSCSIDriverPolicy` policy consente al driver Amazon EBS Container Storage Interface (CSI) di creare, modificare, copiare, allegare, scollegare ed eliminare volumi per tuo conto. Ciò include la modifica dei tag sui volumi esistenti e l’abilitazione del ripristino rapido degli snapshot (FSR) sui volumi EBS. Inoltre, concede al driver CSI EBS le autorizzazioni per creare, bloccare, ripristinare ed eliminare istantanee e per elencare istanze, volumi e istantanee.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EBSCSIDriver ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html#AmazonEBSCSIDriverPolicy-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EFSCSIDriver Policy
La`AmazonEFSCSIDriverPolicy`la policy consente all'Amazon EFS Container Storage Interface (CSI) di creare ed eliminare punti di accesso per tuo conto. Concede inoltre al driver CSI di Amazon EFS le autorizzazioni per elencare i punti di accesso, i file system, gli obiettivi di montaggio e le zone di disponibilità di Amazon EC2.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EFSCSIDriver ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEFSCSIDriverPolicy.html#AmazonEFSCSIDriverPolicy-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSLocal OutpostClusterPolicy
È possibile collegare questa policy alle entità IAM. Prima di creare un cluster, è necessario allegare questa policy a un [ruolo cluster](cluster-iam-role.md). I cluster Kubernetes gestiti da Amazon EKS effettuano chiamate verso altri AWS servizi per tuo conto. Ciò serve a gestire le risorse utilizzate con il servizio.
La `AmazonEKSLocalOutpostClusterPolicy` include le autorizzazioni seguenti:
+ **Azioni di lettura `ec2`**: consente alle istanze del piano di controllo di descrivere le proprietà della zona di disponibilità, della tabella di routing, dell’istanza e dell’interfaccia di rete. Autorizzazioni necessarie affinché le istanze Amazon EC2 si uniscano correttamente al cluster come istanze del piano di controllo.
+ ** `ssm` **: consente la connessione di Systems Manager di Amazon EC2 all’istanza del piano di controllo, utilizzata da Amazon EKS per comunicare e gestire il cluster locale nel tuo account.
+ **`logs`**— Consente alle istanze di inviare i log ad Amazon. CloudWatch
+ **`secretsmanager`**— Consente alle istanze di ottenere ed eliminare i dati di bootstrap per le istanze del piano di controllo in modo sicuro da Secrets Manager. AWS
+ ** `ecr` **: consente a pod e container in esecuzione sulle istanze del piano di controllo di estrarre le immagini di container memorizzate in Amazon Elastic Container Registry.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSLocal OutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html#AmazonEKSLocalOutpostClusterPolicy-json) nella AWS Managed Policy Reference Guide.
## AWS politica gestita: Amazon EKSLocal OutpostServiceRolePolicy
Non è possibile allegare questa policy alle entità IAM. Quando crei un cluster utilizzando un principale IAM che dispone dell'`iam:CreateServiceLinkedRole`autorizzazione, Amazon EKS crea automaticamente il ruolo collegato al servizio [AWSServiceRoleforAmazonEKSLocalOutpost](using-service-linked-roles-eks-outpost.md) per te e gli allega questa policy. Questa policy consente al ruolo collegato al servizio di chiamare i AWS servizi per tuo conto per i cluster locali.
La `AmazonEKSLocalOutpostServiceRolePolicy` include le autorizzazioni seguenti:
+ ** `ec2` **: consente ad Amazon EKS di utilizzare le risorse di sicurezza, rete e altro tipo per avviare e gestire correttamente le istanze del piano di controllo nel tuo account.
+ ** `ssm`, `ssmmessages` **: consente la connessione di Amazon EC2 Systems Manager alle istanze del piano di controllo, utilizzata da Amazon EKS per comunicare e gestire il cluster locale nel tuo account.
+ ** `iam` **: consente ad Amazon EKS di gestire il profilo dell’istanza associato alle istanze del piano di controllo.
+ **`secretsmanager`**- Consente ad Amazon EKS di inserire i dati di bootstrap per le istanze del piano di controllo in AWS Secrets Manager in modo che possano essere referenziati in modo sicuro durante il bootstrap dell'istanza.
+ ** `outposts` **: consente ad Amazon EKS di ottenere le informazioni sull’Outpost dal tuo account per avviare correttamente un cluster locale in un Outpost.
Per visualizzare la versione più recente del documento sulla policy JSON, consulta [Amazon EKSLocal OutpostServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostServiceRolePolicy.html#AmazonEKSLocalOutpostServiceRolePolicy-json) nella AWS Managed Policy Reference Guide.
## Amazon EKS si aggiorna alle politiche AWS gestite
Visualizza i dettagli sugli aggiornamenti delle politiche AWS gestite per Amazon EKS da quando questo servizio ha iniziato a tracciare queste modifiche.
Per ricevere notifiche di tutte le modifiche al file di origine di questa pagina di documentazione specifica, puoi iscriverti al seguente URL con un lettore RSS:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/security/iam-reference/security-iam-awsmanpol.adoc.atom
```
| Modifica | Descrizione | Data |
| --- | --- | --- |
| Autorizzazione aggiunta a [AWS politica gestita: Amazon EKSNetworking Policy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | È stata aggiunta `ec2:ModifyNetworkInterfaceAttribute` l'autorizzazione in`AmazonEKSNetworkingPolicy`. Ciò consente ad Amazon EKS Auto Mode Controller di modificare gli attributi dell'interfaccia di rete relativi alle istanze EC2. | 3 febbraio 2026 |
| Aggiunte autorizzazioni a [AWS politica gestita: AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Aggiunto `autoscaling:PutWarmPool` e `autoscaling:DeleteWarmPool` `autoscaling:DescribeWarmPool` autorizzazioni a. `AWSServiceRoleForAmazonEKSNodegroup` Ciò consente ai gruppi di nodi gestiti di Amazon EKS di gestire le risorse del pool caldo ASG sottostante per tutto il ciclo di vita del gruppo di nodi. | 17 febbraio 2026 |
| Autorizzazione aggiunta a [AWS politica gestita: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | È stato rimosso il requisito del prefisso «eks» nel nome del profilo dell'istanza di destinazione per l'autorizzazione in. `iam:GetInstanceProfile` `AmazonEKSServiceRolePolicy` Ciò consente ad Amazon EKS Auto Mode di convalidare e utilizzare profili di istanza personalizzati NodeClasses senza richiedere il prefisso di denominazione «eks». | 2 febbraio 2026 |
| Autorizzazioni aggiunte ad [Amazon EBSCSIDriver Policy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | È stata aggiunta `ec2:LockSnapshot` l'autorizzazione per consentire al driver CSI EBS di bloccare direttamente le istantanee EBS. | 15 gennaio 2026 |
| Introdotto [AWS politica gestita: Amazon EKSMCPRead OnlyAccess](#security-iam-awsmanpol-amazoneksmcpreadonlyaccess). | Amazon EKS ha introdotto una nuova policy gestita `AmazonEKSMCPReadOnlyAccess` per abilitare strumenti di sola lettura nel server MCP Amazon EKS per l'osservabilità e la risoluzione dei problemi. | 21 novembre 2025 |
| Autorizzazioni aggiunte ad [Amazon EBSCSIDriver Policy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | È stata aggiunta `ec2:CopyVolumes` l'autorizzazione per consentire al driver CSI EBS di copiare direttamente i volumi EBS. | 17 novembre 2025 |
| Autorizzazione aggiunta a [AWS politica gestita: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Aggiunte `ec2:DescribeRouteTables` e `ec2:DescribeNetworkAcls` autorizzazioni a. `AmazonEKSServiceRolePolicy` Ciò consente ad Amazon EKS di rilevare problemi di configurazione con le tabelle di routing VPC e la rete ACLs per nodi ibridi come parte delle informazioni sui cluster. | 22 ottobre 2025 |
| Aggiunta l’autorizzazione a [AWSServiceRoleForAmazonEKSConnector](using-service-linked-roles-eks-connector.md) | È stata aggiunta `ssmmessages:OpenDataChannel` l'autorizzazione a `AmazonEKSConnectorServiceRolePolicy` | 15 ottobre 2025 |
| Aggiunta l’autorizzazione a [AWS politica gestita: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) | Questo ruolo può allegare una nuova policy di accesso `AmazonEKSEventPolicy`. Autorizzazioni limitate per `ec2:DeleteLaunchTemplate` e `ec2:TerminateInstances`. | 26 agosto 2025 |
| Aggiunta l’autorizzazione a [AWS politica gestita: Amazon EKSLocal OutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) | Aggiunta l’autorizzazione `ssmmessages:OpenDataChannel` a `AmazonEKSLocalOutpostServiceRolePolicy`. | 26 giugno 2025 |
| Aggiunta l’autorizzazione a [AWS politica gestita: Amazon EKSCompute Policy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | Autorizzazioni aggiornate per le risorse `ec2:RunInstances` e `ec2:CreateFleet` azioni che includono le prenotazioni della capacità ` arn:aws: ec2:*:*:capacity-reservation/*`. Ciò consente alla modalità automatica di Amazon EKS di avviare istanze utilizzando le prenotazioni della capacità on-demand di EC2 nel tuo account. `iam:CreateServiceLinkedRole` aggiunto per consentire alla modalità automatica di Amazon EKS di creare il ruolo `AWSServiceRoleForEC2Spot` collegato al servizio Spot EC2 per tuo conto. | 20 giugno 2025 |
| È stata aggiunta l'autorizzazione ad [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | È stata aggiunta l’autorizzazione `ec2:DescribeCapacityReservations` per consentire alla modalità automatica di Amazon EKS di avviare istanze utilizzando le prenotazioni della capacità on-demand EC2 nell’account. | 20 giugno 2025 |
| Introdotto [AWS politica gestita: Amazon EKSDashboard ConsoleReadOnly](#security-iam-awsmanpol-amazoneksdashboardconsolereadonly). | È stata introdotta una nuova policy `AmazonEKSDashboardConsoleReadOnly`. | 19 giugno 2025 |
| Introdotto [AWS politica gestita: Amazon EKSDashboard ServiceRolePolicy](#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy). | È stata introdotta una nuova policy `AmazonEKSDashboardServiceRolePolicy`. | 21 maggio 2025 |
| Autorizzazioni aggiunte ad [Amazon EKSCluster Policy](#security-iam-awsmanpol-amazoneksclusterpolicy). | È stata aggiunta l’autorizzazione `ec2:DeleteNetworkInterfaces` per consentire ad Amazon EKS di eliminare le interfacce di rete elastiche che sono lasciate indietro se il CNI di VPC si chiude inaspettatamente. | 16 aprile 2025 |
| È stata aggiunta l'autorizzazione ad [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Sono state aggiunte `ec2:RevokeSecurityGroupEgress` e `ec2:AuthorizeSecurityGroupEgress` autorizzazioni per consentire ai AI/ML clienti EKS di aggiungere regole Security Group Egress all'EKS Cluster SG predefinito compatibili con EFA, come parte della versione EKS 1.33. | 14 aprile 2025 |
| Autorizzazioni aggiunte ad [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Aggiunta l’autorizzazione per terminare le istanze EC2 create dalla modalità automatica di EKS. | 28 febbraio 2025 |
| Autorizzazioni aggiunte ad [Amazon EBSCSIDriver Policy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | È stata aggiunta una nuova dichiarazione che autorizza il driver CSI EBS a ripristinare tutti gli snapshot. Ciò era precedentemente consentito dalla policy esistente, ma è necessaria una nuova dichiarazione esplicita per via di una modifica nella gestione di IAM per `CreateVolume`. È stata aggiunta la possibilità per il driver CSI EBS di modificare i tag sui volumi esistenti. Il driver CSI EBS può modificare i tag dei volumi esistenti tramite un parametro in Kubernetes. VolumeAttributesClasses È stata aggiunta la possibilità per il driver CSI EBS di abilitare il ripristino rapido degli snapshot (FSR) sui volumi EBS. Il driver CSI EBS può abilitare FSR su nuovi volumi tramite parametri nelle classi di archiviazione Kubernetes. | 13 gennaio 2025 |
| Aggiunte autorizzazioni a [AWS politica gestita: Amazon EKSLoad BalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | Aggiornato `AmazonEKSLoadBalancingPolicy` per consentire l’elenco e la descrizione delle risorse di rete e degli indirizzi IP. | 26 dicembre 2024 |
| Aggiunte autorizzazioni a [AWS politica gestita: AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Aggiornato `AWSServiceRoleForAmazonEKSNodegroup` per compatibilità con le regioni della Cina. | 22 novembre 2024 |
| Aggiunte autorizzazioni a [AWS politica gestita: Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) | È stata aggiunta l'`ec2:DescribeAvailabilityZones`autorizzazione per `AmazonEKSLocalOutpostClusterPolicy` consentire al AWS Cloud Controller Manager sul piano di controllo del cluster di identificare la zona di disponibilità in cui si trova ogni nodo. | 21 novembre 2024 |
| Aggiunte autorizzazioni a [AWS politica gestita: AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Policy `AWSServiceRoleForAmazonEKSNodegroup` aggiornata per consentire a `ec2:RebootInstances` le istanze create da gruppi di nodi gestiti di Amazon EKS. Limitazione delle autorizzazioni `ec2:CreateTags` per le risorse Amazon EC2. | 20 novembre 2024 |
| Aggiunte autorizzazioni a [AWS politica gestita: Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Politica AWS gestita aggiornata da EKS`AmazonEKSServiceRolePolicy`. Aggiunte le autorizzazioni per le politiche di accesso EKS, la gestione del bilanciatore del carico e la pulizia automatica delle risorse del cluster. | 16 novembre 2024 |
| Introdotto [AWS politica gestita: Amazon EKSCompute Policy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | Politica AWS gestita aggiornata da EKS`AmazonEKSComputePolicy`. Autorizzazioni delle risorse aggiornate per l’azione `iam:AddRoleToInstanceProfile`. | 7 novembre 2024 |
| Introdotto [AWS politica gestita: Amazon EKSCompute Policy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | AWS ha introdotto il`AmazonEKSComputePolicy`. | 1 novembre 2024 |
| Aggiunte autorizzazioni a `AmazonEKSClusterPolicy` | Aggiunta l’autorizzazione `ec2:DescribeInstanceTopology` per consentire ad Amazon EKS di allegare informazioni di topologia al nodo come etichette. | 1 novembre 2024 |
| Introdotto [AWS politica gestita: Amazon EKSBlock StoragePolicy](#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy). | AWS ha introdotto il`AmazonEKSBlockStoragePolicy`. | 30 ottobre 2024 |
| Introdotto [AWS politica gestita: Amazon EKSLoad BalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | AWS ha introdotto il`AmazonEKSLoadBalancingPolicy`. | 30 ottobre 2024 |
| Autorizzazioni aggiunte ad [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Sono state aggiunte `cloudwatch:PutMetricData` autorizzazioni per consentire ad Amazon EKS di pubblicare metriche su Amazon. CloudWatch | 29 ottobre 2024 |
| Introdotto [AWS politica gestita: Amazon EKSNetworking Policy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | AWS ha introdotto il. `AmazonEKSNetworkingPolicy` | 28 ottobre 2024 |
| Aggiunte autorizzazioni a `AmazonEKSServicePolicy` e `AmazonEKSServiceRolePolicy` | Aggiunte autorizzazione `ec2:GetSecurityGroupsForVpc` e ai tag associati per consentire a EKS di leggere le informazioni sui gruppi di sicurezza e aggiornare i tag correlati. | 10 ottobre 2024 |
| Presentato [Amazon EKSWorker NodeMinimalPolicy](#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy). | AWS ha introdotto il`AmazonEKSWorkerNodeMinimalPolicy`. | 3 ottobre 2024 |
| Aggiunte autorizzazioni a [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Aggiunte le autorizzazioni `autoscaling:ResumeProcesses` e `autoscaling:SuspendProcesses` per consentire ad Amazon EKS di sospendere e riprendere `AZRebalance` nei gruppi Auto Scaling gestiti da Amazon EKS. | 21 agosto 2024 |
| Aggiunte autorizzazioni a [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Aggiunta l’autorizzazione `ec2:DescribeCapacityReservations` per consentire ad Amazon EKS di descrivere la prenotazione della capacità nell’account dell’utente. È stata aggiunta l’autorizzazione `autoscaling:PutScheduledUpdateGroupAction` per abilitare l’impostazione del ridimensionamento pianificato sui gruppi di nodi `CAPACITY_BLOCK`. | 27 giugno 2024 |
| [AmazonEKS\$1CNI\$1Policy](#security-iam-awsmanpol-amazoneks-cni-policy): aggiornamento a una policy esistente | Amazon EKS ha aggiunto nuove autorizzazioni `ec2:DescribeSubnets` per consentire al plugin CNI di Amazon VPC per Kubernetes di visualizzare la quantità di indirizzi IP gratuiti nelle sottoreti Amazon VPC. Il CNI di VPC può utilizzare gli indirizzi IP gratuiti in ciascuna sottorete per scegliere le sottoreti con gli indirizzi IP più liberi da utilizzare durante la creazione di un’interfaccia di rete elastica. | 4 marzo 2024 |
| [Amazon EKSWorker NodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy): aggiornamento a una politica esistente | Amazon EKS ha aggiunto nuove autorizzazioni per consentire le associazioni EKS Pod Identity. Amazon EKS Pod Identity Agent utilizza il ruolo del nodo. | 26 novembre 2023 |
| Introduzione [EFSCSIDriverdella politica Amazon](#security-iam-awsmanpol-amazonefscsidriverservicerolepolicy). | AWS ha introdotto il`AmazonEFSCSIDriverPolicy`. | 26 luglio 2023 |
| Autorizzazioni aggiunte ad [Amazon EKSCluster Policy](#security-iam-awsmanpol-amazoneksclusterpolicy). | È stata aggiunta l'autorizzazione `ec2:DescribeAvailabilityZones` per consentire ad Amazon EKS di ottenere i dettagli AZ durante l'individuazione automatica delle sottoreti nella creazione di sistemi di bilanciamento del carico. | 7 febbraio 2023 |
| Condizioni politiche aggiornate in [Amazon EBSCSIDriver Policy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Sono state rimosse condizioni della policy non valide con caratteri jolly nel campo chiave `StringLike`. È stata aggiunta, inoltre, una nuova condizione `ec2:ResourceTag/kubernetes.io/created-for/pvc/name: "*"` a `ec2:DeleteVolume` che consente al driver CSI EBS di eliminare volumi creati dal plugin nella struttura. | 17 novembre 2022 |
| Autorizzazioni aggiunte ad [Amazon EKSLocal OutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | Aggiunti `ec2:DescribeVPCAttribute`, `ec2:GetConsoleOutput` e `ec2:DescribeSecret` per consentire una migliore convalida dei prerequisiti e il controllo gestito del ciclo di vita. Sono stati inoltre aggiunti `ec2:DescribePlacementGroups`, `"arn:aws: ec2:*:*:placement-group/*"` e `ec2:RunInstances` per supportare il controllo del posizionamento delle istanze Amazon EC2 del piano di controllo su Outposts. | 24 ottobre 2022 |
| Aggiorna le autorizzazioni di Amazon Elastic Container Registry in [Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | L'azione `ecr:GetDownloadUrlForLayer` è stata spostata da tutte le sezioni delle risorse a una sezione con ambito. Aggiunta la risorsa ` arn:aws: ecr:*:*:repository/eks/ `. Risorsa ` arn:aws: ecr:` rimossa. Questa risorsa è coperta dalla risorsa ` arn:aws: ecr:*:*:repository/eks/*` aggiunta. | 20 ottobre 2022 |
| Autorizzazioni aggiunte ad [Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | È stato aggiunto il repository ` arn:aws: ecr:*:*:repository/kubelet-config-updater` Amazon Elastic Container Registry in modo che le istanze del piano di controllo del cluster possano aggiornare alcuni argomenti `kubelet`. | 31 agosto 2022 |
| Presentato [Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | AWS ha introdotto il`AmazonEKSLocalOutpostClusterPolicy`. | 24 agosto 2022 |
| Presentato [Amazon EKSLocal OutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | AWS ha introdotto il`AmazonEKSLocalOutpostServiceRolePolicy`. | 23 agosto 2022 |
| Introduzione [EBSCSIDriverdella politica Amazon](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | AWS ha introdotto il`AmazonEBSCSIDriverPolicy`. | 4 aprile 2022 |
| Autorizzazioni aggiunte ad [Amazon EKSWorker NodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy). | `ec2:DescribeInstanceTypes`Aggiunto per abilitare Amazon EKS ottimizzato in grado di AMIs rilevare automaticamente le proprietà a livello di istanza. | 21 marzo 2022 |
| Aggiunte autorizzazioni a [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Aggiunta l'autorizzazione `autoscaling:EnableMetricsCollection` per consentire ad Amazon EKS l'abilitazione della raccolta di parametri. | 13 dicembre 2021 |
| Autorizzazioni aggiunte ad [Amazon EKSCluster Policy](#security-iam-awsmanpol-amazoneksclusterpolicy). | Aggiunta delle autorizzazioni `ec2:DescribeAccountAttributes`, `ec2:DescribeAddresses`, e `ec2:DescribeInternetGateways` per consentire ad Amazon EKS di creare un ruolo collegato al servizio per un Network Load Balancer (load balancer di Rete). | 17 giugno 2021 |
| Amazon EKS ha iniziato a monitorare le modifiche | Amazon EKS ha iniziato a tracciare le modifiche per le sue politiche AWS gestite. | 17 giugno 2021 |
# Risoluzione dei problemi di IAM
Questo argomento illustra alcuni errori comuni che si potrebbero verificare durante l'utilizzo di Amazon EKS con IAM, e il modo in cui gestirli.
## AccessDeniedException
Se ricevi un messaggio `AccessDeniedException` quando chiami un'operazione AWS API, le credenziali [principali IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) che stai utilizzando non dispongono delle autorizzazioni necessarie per effettuare quella chiamata.
```
An error occurred (AccessDeniedException) when calling the DescribeCluster operation:
User: arn:aws: iam::111122223333:user/user_name is not authorized to perform:
eks:DescribeCluster on resource: arn:aws: eks:region:111122223333:cluster/my-cluster
```
Nel messaggio di esempio precedente, l'utente non dispone delle autorizzazioni per chiamare l'operazione API `DescribeCluster` di Amazon EKS. Per fornire le autorizzazioni da amministratore Amazon EKS a un principale IAM, consultare [Esempi di policy basate su identità Amazon EKS](security-iam-id-based-policy-examples.md).
Per informazioni generali su IAM, consultare [Controllo dell'accesso tramite policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) nella *Guida per l'utente di IMA*.
## Non riesci a vedere **i nodi** nella scheda **Elaborazione** o altro nella scheda **Risorse** e ricevi un errore nella Console di gestione AWS
È possibile che venga visualizzato un messaggio di errore della console che recita `Your current user or role does not have access to Kubernetes objects on this EKS cluster`. Assicurati che l'utente [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) Console di gestione AWS con cui stai utilizzando disponga delle autorizzazioni necessarie. Per ulteriori informazioni, consulta [Autorizzazioni richieste](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
## La `ConfigMap` per aws-auth non concede l'accesso al cluster
L’[Autenticatore AWS IAM](https://github.com/kubernetes-sigs/aws-iam-authenticator) non consente un percorso nell’ARN del ruolo utilizzato in `ConfigMap`. Pertanto, rimuovi il percorso prima di specificare `rolearn`. Ad esempio, modifica ` arn:aws: iam::111122223333:role/team/developers/eks-admin ` in ` arn:aws: iam::111122223333:role/eks-admin `.
## Non sono autorizzato a eseguire iam: PassRole
Se ricevi un errore che indica che non disponi delle autorizzazioni a eseguire l’operazione `iam:PassRole`, è necessario aggiornare le policy per poter passare un ruolo ad Amazon EKS.
Alcuni AWS servizi consentono di trasferire un ruolo esistente a quel servizio anziché creare un nuovo ruolo di servizio o un ruolo collegato al servizio. Per eseguire questa operazione, è necessario disporre delle autorizzazioni per trasmettere il ruolo al servizio.
L'errore di esempio seguente si verifica quando un utente IAM denominato `marymajor` cerca di utilizzare la console per eseguire un'operazione in Amazon EKS. Tuttavia, l’azione richiede che il servizio disponga delle autorizzazioni concesse da un ruolo di servizio. Mary non dispone delle autorizzazioni per trasmettere il ruolo al servizio.
```
User: {arn-aws}iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In questo caso, le policy di Mary devono essere aggiornate per poter eseguire l’operazione `iam:PassRole`.
Se hai bisogno di aiuto, contatta il tuo AWS amministratore. L’amministratore è la persona che ti ha fornito le credenziali di accesso.
## Voglio consentire a persone esterne al mio AWS account di accedere alle mie risorse Amazon EKS
È possibile creare un ruolo con il quale utenti in altri account o persone esterne all’organizzazione possono accedere alle tue risorse. È possibile specificare chi è attendibile per l’assunzione del ruolo. Per i servizi che supportano politiche basate sulle risorse o liste di controllo degli accessi (ACLs), puoi utilizzare tali politiche per consentire alle persone di accedere alle tue risorse.
Per maggiori informazioni, consulta gli argomenti seguenti:
+ Per sapere se Amazon EKS supporta queste caratteristiche, consultare [Funzionamento di Amazon EKS con IAM](security-iam-service-with-iam.md).
+ Per scoprire come fornire l'accesso alle tue risorse su più AWS account di tua proprietà, consulta [Fornire l'accesso a un utente IAM in un altro AWS account di tua proprietà](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) nella *IAM* User Guide.
+ Per scoprire come fornire l'accesso alle tue risorse ad AWS account di terze parti, consulta [Fornire l'accesso agli AWS account di proprietà di terze parti](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) nella *Guida per l'utente IAM*.
+ Per informazioni su come fornire l'accesso tramite la federazione delle identità, consulta [Fornire l'accesso a utenti autenticati esternamente (federazione delle identità)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) nella *Guida per l'utente IAM*.
+ Per informazioni sulle differenze di utilizzo tra ruoli e policy basate su risorse per l’accesso multi-account, consulta [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente di IAM*.
## I container dei pod riceveranno il seguente errore: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`
I tuoi contenitori ricevono questo errore se l'applicazione effettua esplicitamente richieste all'endpoint globale AWS STS (`https://sts.amazonaws`) e il tuo account di servizio Kubernetes è configurato per utilizzare un endpoint regionale. Puoi risolvere il problema con una delle opzioni seguenti:
+ Aggiorna il codice dell'applicazione per rimuovere le chiamate esplicite all'endpoint globale STS. AWS
+ Aggiorna il codice dell'applicazione per effettuare chiamate esplicite agli endpoint regionali, ad esempio `https://sts.us-west-2.amazonaws.com`. L'applicazione dovrebbe avere la ridondanza integrata per scegliere una AWS regione diversa in caso di guasto del servizio nella regione. AWS Per ulteriori informazioni, consulta [Managing AWS STS in an AWS Region nella](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) IAM User Guide.
+ Configura gli account del servizio per l'utilizzo dell'endpoint globale. I cluster utilizzano l’endpoint regionale per impostazione predefinita. Per ulteriori informazioni, consulta [Configurare l’endpoint del Servizio di token di sicurezza AWS per un account di servizio](configure-sts-endpoint.md).
# Ruolo IAM del cluster Amazon EKS
Ѐ richiesto un ruolo IAM del cluster Amazon EKS per ogni cluster. I cluster Kubernetes gestiti da Amazon EKS utilizzano questo ruolo per gestire i nodi e il [provider di servizi cloud](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) utilizza questo ruolo per creare bilanciatori del carico con Elastic Load Balancing per i servizi.
Prima di poter creare cluster Amazon EKS, devi creare un ruolo IAM con una delle seguenti policy IAM:
+ [EKSClusterPolitica di Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html)
+ Una policy IAM personalizzata. Le autorizzazioni minime che seguono consentono al cluster di Kubernetes di gestire i nodi, ma non consentono al [provider di servizi cloud](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) di creare bilanciatori del carico con bilanciamento del carico elastico. La policy IAM personalizzata deve disporre almeno delle seguenti autorizzazioni:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "kubernetes.io/cluster/*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeInstanceTopology",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
**Nota**
Prima del 3 ottobre 2023, era richiesta la [EKSClusterpolitica di Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) sul ruolo IAM per ogni cluster.
Prima del 16 aprile 2020, erano obbligatorie [Amazon EKSService EKSCluster Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) [e Amazon Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) e il nome suggerito per il ruolo era`eksServiceRole`. Con il ruolo `AWSServiceRoleForAmazonEKS` collegato ai servizi, la politica di [Amazon EKSService Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) non è più richiesta per i cluster creati a partire dal 16 aprile 2020.
## Verifica della presenza di un ruolo del cluster esistente
Per verificare se l’account dispone già di un ruolo del cluster Amazon EKS, puoi utilizzare la procedura indicata di seguito.
1. Apri la console IAM all'indirizzo. https://console.aws.amazon.com/iam/
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Cerca l’elenco dei ruoli per `eksClusterRole`. Se un ruolo che include `eksClusterRole` non esiste, consultare [Creazione del ruolo del cluster Amazon EKS](#create-service-role) per crearlo. Se un ruolo che include `eksClusterRole` esiste, seleziona il ruolo per visualizzare le policy allegate.
1. Selezionare **Autorizzazioni**.
1. Assicurati che la **EKSClusterpolitica gestita da Amazon** Policy sia associata al ruolo. Se la policy è allegata, il ruolo del cluster Amazon EKS è configurato correttamente.
1. Scegliere **Relazioni di attendibilità**, quindi scegliere **Modifica policy di attendibilità**.
1. Verifica che la relazione di trust includa la policy seguente. Se la relazione di attendibilità corrisponde alla policy seguente, scegli **Annulla**. Se la relazione di attendibilità non corrisponde, copia la policy nella finestra **Modifica policy di attendibilità** e scegli **Aggiorna policy**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Creazione del ruolo del cluster Amazon EKS
È possibile utilizzare Console di gestione AWS o la AWS CLI per creare il ruolo del cluster.
Console di gestione AWS
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Scegli **Ruoli**, quindi **Crea ruolo**.
1. In **Tipo di entità affidabile**, seleziona ** AWS servizio**.
1. Dall'elenco a discesa **Casi d'uso per altri AWS servizi**, scegli **EKS**.
1. Scegli **EKS - Cluster** per il caso d’uso, quindi scegli **Successivo**.
1. Nella scheda **Aggiungi autorizzazioni**, scegli **Successivo**.
1. Per **Nome ruolo**, inserisci un nome univoco per il ruolo, ad esempio `eksClusterRole`.
1. Per **Descrizione**, inserisci un testo descrittivo come `Amazon EKS - Cluster role`.
1. Scegli **Crea ruolo**.
AWS CLI
1. Copiare i seguenti contenuti in un file denominato *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Crea il ruolo. Puoi sostituire *eksClusterRole* con un nome a tua scelta.
```
aws iam create-role \
--role-name eksClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Allega la policy IAM richiesta al ruolo.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy \
--role-name eksClusterRole
```
# Ruolo IAM del nodo Amazon EKS
Il `kubelet` daemon del nodo Amazon EKS effettua chiamate per tuo AWS APIs conto. I nodi ricevono le autorizzazioni per queste chiamate API attraverso un profilo dell'istanza IAM e le policy associate. Prima di avviare i nodi e registrarli in un cluster, devi creare un ruolo IAM che i nodi possano utilizzare all'avvio. Questo requisito si applica ai nodi lanciati con l'AMI ottimizzata Amazon EKS fornita da Amazon o con qualsiasi altro nodo AMIs che intendi utilizzare. Inoltre, questo requisito si applica sia ai gruppi di nodi gestiti sia ai nodi autogestiti.
**Nota**
Non è possibile utilizzare lo stesso ruolo utilizzato per creare i cluster.
Prima di creare i nodi, è necessario creare un ruolo IAM con le seguenti autorizzazioni:
+ Autorizzazioni per `kubelet` descrivere EC2 le risorse Amazon nel VPC, come quelle fornite dalla policy di [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html). Questa policy fornisce anche le autorizzazioni per il Pod Identity Agent di Amazon EKS.
+ [Autorizzazioni `kubelet` per l'utilizzo di immagini di container da Amazon Elastic Container Registry (Amazon ECR), come previsto dalla politica di Amazon. EC2 ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html) Le autorizzazioni per utilizzare le immagini dei container da Amazon Elastic Container Registry (Amazon ECR) sono necessarie perché i componenti aggiuntivi integrati per le reti eseguono pod che utilizzano immagini di container provenienti da Amazon ECR.
+ (Facoltativo) Autorizzazioni per consentire al Pod Identity Agent di Amazon EKS di utilizzare l'azione `eks-auth:AssumeRoleForPodIdentity` per recuperare le credenziali per i pod. Se non utilizzi [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html), devi fornire questa autorizzazione oltre alle EC2 autorizzazioni per utilizzare EKS Pod Identity.
+ (Facoltativo) Se non si usa Pod Identity di EKS o IRSA per fornire le autorizzazioni ai pod VPC CNI, è necessario fornire le autorizzazioni per il VPC CNI sul ruolo dell’istanza. Puoi utilizzare la politica [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html)gestita (se hai creato il cluster con la `IPv4` famiglia) o una [IPv6 politica creata da te](cni-iam-role.md#cni-iam-role-create-ipv6-policy) (se hai creato il cluster con la `IPv6` famiglia). Invece di allegare la policy a questo ruolo, tuttavia, consigliamo di allegarla a un ruolo separato utilizzato specificamente per il componente aggiuntivo CNI di Amazon VPC. Per ulteriori informazioni sulla creazione di un ruolo separato per il componente aggiuntivo CNI di Amazon VPC, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md).
**Nota**
I gruppi di EC2 nodi Amazon devono avere un ruolo IAM diverso rispetto al profilo Fargate. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md).
## Verifica della presenza di un ruolo di nodo esistente
Per controllare se l’account dispone già di un ruolo di nodo Amazon EKS, utilizza la procedura indicata di seguito.
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Ricerca `eksNodeRole`, `AmazonEKSNodeRole` o `NodeInstanceRole` nell'elenco di ruoli. Se un ruolo con uno di questi nomi non esiste, consulta [Creazione del ruolo IAM del nodo Amazon EKS](#create-worker-node-role) per creare il ruolo. Se esiste un ruolo che contiene `eksNodeRole`, `AmazonEKSNodeRole` o `NodeInstanceRole`, seleziona il ruolo per visualizzare le policy allegate.
1. Seleziona **Autorizzazioni**.
1. Assicurati che le policy EC2 ContainerRegistryPullOnly gestite da **Amazon EKSWorker NodePolicy** **e Amazon** siano associate al ruolo o che sia allegata una policy personalizzata con le autorizzazioni minime.
**Nota**
Se la policy **AmazonEKS\$1CNI\$1Policy** è allegata al ruolo, è consigliabile invece rimuoverla e allegarla a un ruolo IAM mappato all'account di servizio `aws-node` Kubernetes. Per ulteriori informazioni, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md).
1. Scegli **Trust relationships** (Relazioni di attendibilità), quindi scegli **Edit trust policy** (Modifica policy di attendibilità).
1. Verifica che la relazione di trust includa la policy seguente. Se la relazione di attendibilità corrisponde alla policy seguente, scegli **Annulla**. Se la relazione di attendibilità non corrisponde, copia la policy nella finestra **Modifica policy di attendibilità** e scegli **Aggiorna policy**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
## Creazione del ruolo IAM del nodo Amazon EKS
Puoi creare il ruolo IAM del nodo con Console di gestione AWS o la AWS CLI.
Console di gestione AWS
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Nella pagina **Ruoli**, seleziona **Crea ruolo**.
1. Nella pagina **Seleziona un’entità attendibile**, esegui le operazioni seguenti:
1. Nella sezione **Tipo di entità affidabile**, scegli ** AWS servizio**.
1. In **Use case** (Caso d'uso), scegli **EC2**.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Aggiungi autorizzazioni**, collega una policy personalizzata o esegui le operazioni seguenti:
1. Nella casella **Filtra policy**, inserisci `AmazonEKSWorkerNodePolicy`.
1. Seleziona la casella di controllo a sinistra di **Amazon EKSWorker NodePolicy** nei risultati della ricerca.
1. Scegli **Cancella filtri**.
1. Nella casella **Filtra policy**, inserisci `AmazonEC2ContainerRegistryPullOnly`.
1. Seleziona la casella di controllo a sinistra di **Amazon EC2 ContainerRegistryPullOnly** nei risultati della ricerca.
La policy **gestita Amazoneks\$1CNI\$1Policy** o una policy creata da te devono essere collegate anche a questo ruolo o a [IPv6 un ruolo](cni-iam-role.md#cni-iam-role-create-ipv6-policy) diverso mappato all'account del servizio Kubernetes. `aws-node` Si consiglia di assegnare la policy al ruolo associato all'account del servizio Kubernetes anziché assegnarlo a questo ruolo. Per ulteriori informazioni, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md).
1. Scegli **Next (Successivo)**.
1. Nella pagina **Name, review, and create** (Assegna un nome, rivedi e crea), esegui le operazioni seguenti:
1. Per **Nome ruolo**, inserisci un nome univoco per il ruolo, ad esempio `AmazonEKSNodeRole`.
1. In **Descrizione**, sostituisci il testo attuale con un testo descrittivo come `Amazon EKS - Node role`.
1. In **Aggiungi tag (facoltativo)**, aggiungi metadati al ruolo collegando i tag come coppie chiave-valore. Per ulteriori informazioni sull’utilizzo di tag in IAM, consulta la sezione [Tagging IAM resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) nella *Guida per l’utente di IAM*.
1. Scegli **Crea ruolo**.
AWS CLI
1. Per creare il file `node-role-trust-relationship.json`, emetti il seguente comando:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
1. Crea il ruolo IAM.
```
aws iam create-role \
--role-name AmazonEKSNodeRole \
--assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Allegare al ruolo IAM le due policy gestite IAM richieste.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name AmazonEKSNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly \
--role-name AmazonEKSNodeRole
```
1. Allega una delle seguenti policy IAM al ruolo IAM a seconda della famiglia di IP con cui hai creato il cluster. La policy deve essere allegata a questo ruolo o a un ruolo associato all’account di servizio Kubernetes `aws-node` che viene utilizzato per il componente aggiuntivo Amazon VPC CNI per Kubernetes. Si consiglia di assegnare la policy al ruolo associato all'account del servizio Kubernetes. Per assegnare la policy al ruolo associato all'account del servizio Kubernetes, consultare [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md).
+ IPv4
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name AmazonEKSNodeRole
```
+ IPv6
1. Copia il testo seguente e salvalo in un file denominato `vpc-cni-ipv6-policy.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Creare la policy IAM.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Allega la policy IAM al ruolo IAM. Sostituisci *111122223333* con l'ID del tuo account.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name AmazonEKSNodeRole
```
# Ruolo IAM del cluster della modalità automatica di Amazon EKS
Ѐ richiesto un ruolo IAM del cluster di Amazon EKS per ogni cluster. I cluster di Kubernetes gestiti da Amazon EKS utilizzano questo ruolo per automatizzare le attività di routine per lo storage, il networking e il dimensionamento automatico di elaborazione.
Prima di poter creare cluster Amazon EKS, devi creare un ruolo IAM con le policy richieste per la modalità automatica di EKS. Puoi allegare le politiche gestite AWS IAM suggerite o creare policy personalizzate con autorizzazioni equivalenti.
+ [EKSComputePolitica di Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingPolitica di Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterPolitica di Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
## Verifica della presenza di un ruolo del cluster esistente
Per verificare se l’account dispone già di un ruolo del cluster Amazon EKS, puoi utilizzare la procedura indicata di seguito.
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Cerca l’elenco dei ruoli per `AmazonEKSAutoClusterRole`. Se un ruolo che include `AmazonEKSAutoClusterRole` non esiste, consultare le istruzioni nella sezione successiva per crearlo. Se un ruolo che include `AmazonEKSAutoClusterRole` esiste, seleziona il ruolo per visualizzare le policy allegate.
1. Selezionare **Autorizzazioni**.
1. Assicurati che la **EKSClusterpolitica gestita da Amazon** Policy sia associata al ruolo. Se la policy è allegata, il ruolo del cluster Amazon EKS è configurato correttamente.
1. Scegliere **Relazioni di attendibilità**, quindi scegliere **Modifica policy di attendibilità**.
1. Verifica che la relazione di trust includa la policy seguente. Se la relazione di attendibilità corrisponde alla policy seguente, scegli **Annulla**. Se la relazione di attendibilità non corrisponde, copia la policy nella finestra **Modifica policy di attendibilità** e scegli **Aggiorna policy**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
**Nota**
AWS non richiede il nome `AmazonEKSAutoClusterRole` per questo ruolo.
## Creazione del ruolo del cluster Amazon EKS
È possibile utilizzare Console di gestione AWS o la AWS CLI per creare il ruolo del cluster.
### Console di gestione AWS
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Scegli **Ruoli**, quindi **Crea ruolo**.
1. In **Tipo di entità affidabile**, seleziona ** AWS servizio**.
1. Dall'elenco a discesa **Casi d'uso per altri AWS servizi**, scegli **EKS**.
1. Scegli **EKS - Cluster** per il caso d’uso, quindi scegli **Successivo**.
1. Nella scheda **Aggiungi autorizzazioni**, selezionare le policy e quindi scegliere **Avanti**.
+ [EKSComputePolitica di Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingPolitica di Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterPolitica di Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
1. Per **Nome ruolo**, inserisci un nome univoco per il ruolo, ad esempio `AmazonEKSAutoClusterRole`.
1. Per **Descrizione**, inserisci un testo descrittivo come `Amazon EKS - Cluster role`.
1. Scegli **Crea ruolo**.
### AWS CLI
1. Copiare i seguenti contenuti in un file denominato *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Crea il ruolo. Puoi sostituire *AmazonEKSAutoClusterRole* con un nome a tua scelta.
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Allegare le policy IAM richieste al ruolo:
**EKSClusterPolitica di Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
**EKSComputePolitica di Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSComputePolicy
```
**Amazon EKSBlock StoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**Amazon EKSLoad BalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**EKSNetworkingPolitica di Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSNetworkingPolicy
```
# Ruolo IAM del nodo della modalità automatica di Amazon EKS
**Nota**
Non puoi utilizzare lo stesso ruolo usato per creare i cluster.
Prima di creare i nodi, devi creare un ruolo IAM con le seguenti policy, o autorizzazioni equivalenti:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
## Verifica della presenza di un ruolo di nodo esistente
Per controllare se l’account dispone già di un ruolo di nodo Amazon EKS, utilizza la procedura indicata di seguito.
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Cerca l’elenco dei ruoli per `AmazonEKSAutoNodeRole`. Se un ruolo con uno di questi nomi non esiste, consulta le istruzioni nella sezione successiva per creare il ruolo. Se esiste un ruolo che contiene `AmazonEKSAutoNodeRole`, selezionare il ruolo per visualizzare i criteri allegati.
1. Seleziona **Autorizzazioni**.
1. Assicurati che siano allegate le policy richieste sopra riportate o le policy personalizzate equivalenti.
1. Scegli **Relazioni di attendibilità**, quindi scegli **Modifica policy di attendibilità**.
1. Verifica che la relazione di trust includa la policy seguente. Se la relazione di attendibilità corrisponde alla policy seguente, scegli **Annulla**. Se la relazione di attendibilità non corrisponde, copia la policy nella finestra **Modifica policy di attendibilità** e scegli **Aggiorna policy**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Creazione del ruolo IAM del nodo Amazon EKS
Puoi creare il ruolo IAM del nodo con Console di gestione AWS o la AWS CLI.
### Console di gestione AWS
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Nella pagina **Ruoli**, seleziona **Crea ruolo**.
1. Nella pagina **Seleziona un’entità attendibile**, esegui le operazioni seguenti:
1. Nella sezione **Tipo di entità affidabile**, scegli ** AWS servizio**.
1. In **Use case** (Caso d'uso), scegli **EC2**.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Aggiungi autorizzazioni**, allega le policy seguenti:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
1. Nella pagina **Assegna un nome, rivedi e crea**, esegui le operazioni seguenti:
1. Per **Nome ruolo**, inserisci un nome univoco per il ruolo, ad esempio `AmazonEKSAutoNodeRole`.
1. In **Descrizione**, sostituisci il testo attuale con un testo descrittivo come `Amazon EKS - Node role`.
1. In **Aggiungi tag (facoltativo)**, aggiungi metadati al ruolo collegando i tag come coppie chiave-valore. Per ulteriori informazioni sull’utilizzo di tag in IAM, consulta la sezione [Tagging IAM resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) nella *Guida per l’utente di IAM*.
1. Scegli **Crea ruolo**.
### AWS CLI
**Crea il ruolo IAM del nodo**
Utilizza il **node-trust-policyfile.json** del passaggio precedente per definire quali entità possono assumere il ruolo. Per creare il ruolo IAM del nodo, esegui il seguente comando:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
**Annota l’ARN del ruolo**
Una volta creato il ruolo, recupera e salva l’ARN del ruolo IAM del nodo. Sarà necessario usare questo ARN nei passaggi successivi. Usa il seguente comando per ottenere l’ARN:
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
**Allega le policy richieste**
Allega le seguenti policy AWS gestite al ruolo Node IAM per fornire le autorizzazioni necessarie:
Per collegare Amazon EKSWorkerNodeMinimalPolicy:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
Per collegare Amazon EC2ContainerRegistryPullOnly:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
# Funzionalità Amazon EKS, ruolo IAM
Le funzionalità EKS richiedono la configurazione di un ruolo IAM di capacità (o ruolo di capacità). Le funzionalità utilizzano questo ruolo per eseguire azioni sui AWS servizi e accedere alle risorse Kubernetes nel cluster tramite voci di accesso create automaticamente.
Prima di poter specificare un ruolo di capacità durante la creazione della capacità, è necessario creare il ruolo IAM con la policy di fiducia e le autorizzazioni appropriate per il tipo di funzionalità. Una volta creato, questo ruolo IAM può essere riutilizzato per un numero qualsiasi di risorse funzionali.
## Requisiti del ruolo di capacità
Il ruolo di capacità deve soddisfare i seguenti requisiti:
+ Il ruolo deve appartenere allo stesso AWS account del cluster e della risorsa di capacità
+ Il ruolo deve avere una politica di fiducia che consenta al servizio EKS Capabilities di assumerlo
+ Il ruolo deve disporre delle autorizzazioni appropriate per il tipo di capacità e i requisiti del caso d'uso (vedi[Autorizzazioni per tipo di funzionalità](#capability-permissions))
## Politica di fiducia per i ruoli di capacità
Tutti i ruoli di capacità devono includere la seguente politica di fiducia:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
Questa politica di fiducia consente a EKS di:
+ Assumi il ruolo di eseguire operazioni AWS API
+ Tagga le sessioni per scopi di controllo e tracciamento
## Autorizzazioni per tipo di funzionalità
Le autorizzazioni IAM richieste dipendono dalla funzionalità utilizzata e dal modello di implementazione.
**Nota**
Per le implementazioni di produzione che utilizzano IAM Role Selectors con ACK o quando si utilizza kro o Argo CD senza integrazione di AWS servizi, Capability Role potrebbe non richiedere alcuna autorizzazione IAM oltre alla policy di fiducia.
**kro (Kube Resource Orchestrator)**
Non sono richieste autorizzazioni IAM. Puoi creare un ruolo di capacità senza policy allegate. kro richiede solo le autorizzazioni RBAC di Kubernetes per creare e gestire le risorse Kubernetes.
** AWS Controller per Kubernetes (ACK)**
ACK supporta due modelli di autorizzazione:
+ **Configurazione semplice (sviluppo/test)**: aggiungi le autorizzazioni di AWS servizio direttamente al Capability Role. È la soluzione ideale per iniziare, per le implementazioni con account singolo o quando tutti gli utenti necessitano delle stesse autorizzazioni.
+ **Best practice di produzione**: utilizza IAM Role Selectors per implementare l'accesso con privilegi minimi. Con questo approccio, il Capability Role necessita solo dell'`sts:AssumeRole`autorizzazione per assumere ruoli specifici del servizio. Non si aggiungono autorizzazioni di AWS servizio (come S3 o RDS) al ruolo di capacità stesso: tali autorizzazioni vengono concesse a singoli ruoli IAM mappati su namespace specifici.
I selettori di ruolo IAM consentono di:
+ Isolamento delle autorizzazioni a livello di namespace
+ Gestione delle risorse tra account
+ Ruoli IAM specifici del team
+ Modello di sicurezza con privilegi minimi
Esempio di policy Capability Role per l'approccio IAM Role Selector:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/ACK-S3-Role",
"arn:aws:iam::111122223333:role/ACK-RDS-Role",
"arn:aws:iam::444455556666:role/ACKCrossAccountRole"
]
}
]
}
```
Per una configurazione dettagliata delle autorizzazioni ACK, inclusi IAM Role Selectors, consulta. [Configurare le autorizzazioni ACK](ack-permissions.md)
**CD Argo**
Per impostazione predefinita, non sono richieste autorizzazioni IAM. Potrebbero essere necessarie autorizzazioni opzionali per:
+ ** AWS Secrets Manager**: se si utilizza Secrets Manager per archiviare le credenziali del repository Git
+ ** AWS CodeConnections**: Se si utilizza CodeConnections per l'autenticazione del repository Git
Politica di esempio per Secrets Manager e CodeConnections:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*"
},
{
"Effect": "Allow",
"Action": [
"codeconnections:UseConnection",
"codeconnections:GetConnection"
],
"Resource": "arn:aws:codeconnections:region:account-id:connection/*"
}
]
}
```
Per i requisiti di autorizzazione dettagliati di Argo CD, vedere[Considerazioni su Argo CD](argocd-considerations.md).
## Verificate la presenza di un ruolo di capacità esistente
Puoi utilizzare la seguente procedura per verificare se il tuo account dispone già di un ruolo IAM con funzionalità adatto al tuo caso d'uso.
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Cerca nell'elenco dei ruoli il nome del tuo ruolo di capacità (ad esempio, `ACKCapabilityRole` o`ArgoCDCapabilityRole`).
1. Se esiste un ruolo, selezionalo per visualizzare le politiche allegate e la relazione di fiducia.
1. Scegliere **Relazioni di attendibilità**, quindi scegliere **Modifica policy di attendibilità**.
1. Verifica che la relazione di fiducia corrisponda alla [politica di fiducia in materia di capacità](#capability-trust-policy). Se non corrisponde, aggiorna la politica di fiducia.
1. Scegli **Autorizzazioni** e verifica che il ruolo disponga delle autorizzazioni appropriate per il tipo di capacità e il caso d'uso.
## Creazione di una funzionalità (ruolo IAM)
È possibile utilizzare Console di gestione AWS o la AWS CLI per creare un ruolo di capacità.
** Console di gestione AWS **
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Scegli **Ruoli**, quindi **Crea ruolo**.
1. In **Tipo di entità affidabile**, seleziona **Politica di fiducia personalizzata**.
1. Copia e incolla la [politica di attendibilità delle capacità](#capability-trust-policy) nell'editor dei criteri di fiducia.
1. Scegli **Next (Successivo)**.
1. Nella scheda **Aggiungi autorizzazioni**, seleziona o crea politiche appropriate per il tuo tipo di capacità (vedi[Autorizzazioni per tipo di funzionalità](#capability-permissions)). Per kro, puoi saltare questo passaggio.
1. Scegli **Next (Successivo)**.
1. Per **Nome ruolo**, inserisci un nome univoco per il tuo ruolo, ad esempio `ACKCapabilityRole``ArgoCDCapabilityRole`, o. `kroCapabilityRole`
1. Per **Descrizione**, inserisci un testo descrittivo come `Amazon EKS - ACK capability role`.
1. Scegliere **Crea ruolo**.
** AWS CLI**
1. Copia la [policy di affidabilità delle capacità](#capability-trust-policy) in un file denominato`capability-trust-policy.json`.
1. Crea il ruolo. Sostituiscila `ACKCapabilityRole` con il nome del ruolo desiderato.
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://capability-trust-policy.json
```
1. Allega le politiche IAM richieste al ruolo. Per ACK, allega le policy per AWS i servizi che desideri gestire. Per Argo CD, allegate le politiche per Secrets Manager o CodeConnections se necessario. Per kro, puoi saltare questo passaggio.
Esempio per ACK con autorizzazioni S3:
```
aws iam put-role-policy \
--role-name ACKCapabilityRole \
--policy-name S3Management \
--policy-document file://s3-policy.json
```
## Risoluzione dei problemi relativi alle funzionalità e ai ruoli
**La creazione delle funzionalità fallisce con «Ruolo IAM non valido»**
Verificare che:
+ Il ruolo esiste nello stesso account del cluster
+ La politica di fiducia corrisponde alla [politica di affidabilità delle capacità](#capability-trust-policy)
+ Hai l'`iam:PassRole`autorizzazione per il ruolo
**La funzionalità mostra errori di autorizzazione**
Verificare che:
+ Il ruolo dispone delle autorizzazioni IAM necessarie per il tipo di funzionalità
+ La voce di accesso per il ruolo esiste nel cluster
+ Se necessario, vengono configurate autorizzazioni Kubernetes aggiuntive (vedi) [Autorizzazioni Kubernetes aggiuntive](capabilities-security.md#additional-kubernetes-permissions)
**Le risorse ACK falliscono con errori di «autorizzazione negata»**
Verificare che:
+ Il ruolo dispone delle autorizzazioni IAM necessarie per il tuo caso d'uso
+ Per i controller ACK che fanno riferimento a segreti, assicurati di aver associato la policy di `AmazonEKSSecretReaderPolicy` accesso prevista ai namespace appropriati.
Per ulteriori indicazioni sulla risoluzione dei problemi, consulta. [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)