**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à. # 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" } } } ] } ```