Contribuisci a migliorare questa pagina
Per contribuire a questa guida per l’utente, seleziona il link Edit this page on GitHub che si trova nel riquadro destro di ogni pagina.
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 predefinita gestita che implementa una difesa approfondita per le applicazioni Kubernetes e non richiede alcuna azione lato utente.
Amazon EKS utilizza il Servizio AWS di gestione delle chiavi (KMS) con il provider Kubernetes KMS v2
Comprensione della crittografia a busta
La crittografia a busta è il processo di crittografia dei dati in testo semplice con una chiave di crittografia dei dati (DEK) prima di inviarli al datastore (etcd) e quindi di crittografia della DEK con una chiave KMS principale archiviata in un sistema KMS (AWS KMS) remoto e gestito centralmente. Si tratta di una strategia di difesa approfondita 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 della chiave (KEK).
In che modo Amazon EKS abilita la crittografia a busta predefinita con KMS v2 e AWS KMS
Amazon EKS utilizza KMS v2
Per impostazione predefinita, questa KEK è di proprietà di AWS, ma puoi facoltativamente importarne una da AWS KMS.
Il diagramma riportato di seguito mostra la generazione e la crittografia di una DEK all’avvio del server API.
Il diagramma di alto livello riportato di seguito mostra la crittografia di una risorsa Kubernetes prima che venga archiviata in etcd.
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 di kube-apiserver è protetta tramite il sistema Nitro. Amazon EKS utilizza solo istanze EC2 basate su Nitro 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 AWS la sicurezza ha la massima priorità
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à, 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 la DEK utilizzando una chiave di crittografia a chiave remota (KEK) di AWS KMS. 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 della DEK memorizzato nella cache per generare altre DEK monouso basate su una funzione di derivazione della chiave (KDF). Ciascuna di queste DEK generate viene quindi utilizzata solo una volta per crittografare una singola risorsa Kubernetes prima che venga archiviata in etcd.
Tieni presente che sono state effettuate chiamate aggiuntive dal server API per verificare lo stato e la normale funzionalità dell’integrazione AWS KMS. Tali controlli dell’integrità 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 log degli eventi AWS CloudTrail associati all’uso della CMK del tuo cluster.
Se il cluster utilizza una chiave di proprietà di AWS, questa verrà descritta in dettaglio nella console EKS (escluso l’ARN della chiave).
AWS può accedere alla chiave di proprietà di AWS utilizzata per la crittografia a busta predefinita 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 di proprietà di AWS.
La crittografia a busta predefinita è abilitata nel mio cluster EKS esistente?
Se esegui il cluster 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 il controllo degli accessi basato sul ruolo (RBAC) eks:kms-storage-migrator ClusterRole per migrare dati che in precedenza non erano crittografati a 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 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. Tuttavia, se utilizzi la tua chiave AWS KMS, verranno applicati i normali prezzi di KMS
Quanto costa utilizzare la mia chiave AWS KMS per crittografare i dati dell’API Kubernetes nel 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 di KMS per un account, quindi il costo dell’utilizzo della chiave AWS KMS personale sul cluster sarà influenzato dall’utilizzo di questa chiave su altri cluster o risorse all’interno dell’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 ad 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 della DEK crittografato non si trova nella cache del server API, quest’ultimo chiamerà AWS KMS per crittografare il seed della 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 seed della DEK decrittografato verrà memorizzato nella cache e utilizzato per future operazioni di decrittografia.
Per ulteriori informazioni, consulta KEP-3299: KMS v2 Improvements
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 crittografiariabiliti. 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 collocato in uno stato non integro/degradato, a quel punto non saremo in grado di adempiere al nostro impegno di servizio
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 disabilitata/eliminata?
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 allarme CloudWatch per ricevere notifiche 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 che interrompono l’API a causa di un aggiornamento automatico di Kubernetes che può avvenire mentre il cluster si trova in uno stato non integro/degradato.
Perché il mio cluster EKS si trova in uno stato non integro/degradato dopo aver disabilitato la CMK?
Il server API del piano di controllo (control-plane) EKS utilizza una chiave DEK crittografata e archiviata nella cache della memoria del server API per crittografare tutti gli oggetti durante le operazioni di creazione/aggiornamento 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à una DEK memorizzata nella cache e dovrà chiamare AWS KMS per le operazioni di crittografia e decrittografia. Senza una CMK, questo processo fallirà con un codice di errore KMS_KEY_DISABLED, 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_KEY_NOT_FOUND) o le concessioni per la CMK associata al cluster vengono revocate (KMS_GRANT_REVOKED), il cluster non sarà ripristinabile. Per ulteriori informazioni sullo stato del cluster e sui codici di errore, consulta Cluster health FAQs and error codes with resolution paths.
Mi verranno comunque addebitati costi per un cluster EKS degradato/non integro perché ho disabilitato o eliminato la mia CMK?
Sì. Sebbene il piano di controllo (control-plane) EKS non sia utilizzabile in caso di disattivazione di una CMK, 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
Il mio cluster EKS può essere aggiornato automaticamente quando si trova in uno stato non integro o degradato 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+1) 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. Un alias è un nome descrittivo per una chiave Amazon Web Service KMS. 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
