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