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à.
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) con il provider Kubernetes KMS v2
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
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 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 EC2 istanze basate su Nitro per il piano di controllo 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 è la nostra 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 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-migratorRBAC 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 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 KMS, verranno applicati i AWS normali prezzi KMS.
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.
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 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.
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 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_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 Integrità del cluster e codici di errore con percorsi di risoluzione. 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
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+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
