Panoramica sulla sicurezza

Questa pagina descrive l'architettura di sicurezza di GKE su AWS, inclusa la crittografia e la configurazione dei nodi.

I cluster GKE offrono funzionalità che consentono di proteggere i workload, inclusi i contenuti dell'immagine container, il runtime dei container, la rete del cluster e l'accesso al server API del cluster.

Quando utilizzi i cluster GKE, accetti di assumerti determinate responsabilità per i tuoi cluster. Per saperne di più, consulta Responsabilità condivise dei cluster GKE.

Crittografia con AWS KMS

GKE su AWS utilizza chiavi simmetriche di AWS Key Management Service (KMS) gestite dal cliente per criptare:

  • Dati di stato di Kubernetes in etcd
  • Dati utente dell'istanza EC2
  • Volumi EBS per la crittografia at-rest dei dati del piano di controllo e del pool di nodi

Per gli ambienti di produzione, ti consigliamo di utilizzare chiavi diverse per la configurazione e la crittografia dei volumi. Per ridurre ulteriormente i rischi in caso di compromissione di una chiave, puoi anche creare chiavi diverse per ciascuno dei seguenti elementi:

  • Configurazione del piano di controllo del cluster configuration
  • Database del piano di controllo del cluster database
  • Volume principale del piano di controllo del cluster principale
  • Volume radice del piano di controllo del cluster
  • Configurazione del node pool
  • Volume radice del node pool

Per una maggiore sicurezza, puoi creare un criterio della chiave AWS KMS che assegni solo il set minimo di autorizzazioni richieste. Per saperne di più, consulta Creazione di chiavi KMS con autorizzazioni specifiche.

Crittografia dei dati at-rest

La crittografia dei dati at-rest è la crittografia dei dati archiviati, a differenza dei dati in transito. Per impostazione predefinita, GKE su AWS cripta i dati in etcd e nei volumi di archiviazione at-rest utilizzando le chiavi gestite dalla piattaforma AWS.

I cluster GKE su AWS archiviano i dati nei volumi AWS Elastic Block Storage (EBS). Questi volumi EBS sono sempre criptati at-rest con le chiavi AWS Key Management System (AWS KMS). Quando crei cluster e node pool, puoi fornire una chiave KMS gestita dal cliente (CMK) per criptare i volumi EBS sottostanti. Se non specifichi una chiave, AWS utilizza la chiave predefinita gestita da AWS nella regione AWS in cui è in esecuzione il cluster.

Inoltre, tutti i cluster GKE abilitano la crittografia dei secret a livello di applicazione per i dati sensibili, come gli oggetti Secret di Kubernetes, che vengono archiviati in etcd. Anche se gli autori degli attacchi ottengono l'accesso al volume sottostante in cui sono archiviati i dati etcd, questi dati sono criptati.

Quando crei un cluster, devi passare una chiave AWS KMS al --database-encryption-kms-key-arn campo. Questa chiave viene utilizzata per la crittografia envelope dei dati dell'applicazione. Poiché questo campo della risorsa è immutabile e non può essere modificato una volta creato il cluster, ti consigliamo di utilizzare un alias della chiave KMS. Puoi utilizzare gli alias delle chiavi per ruotare le chiavi utilizzate per la crittografia at-rest durante il ciclo di vita del cluster.

Come funziona la crittografia a livello di applicazione

Kubernetes offre la crittografia a livello di applicazione con una tecnica nota come crittografia envelope. Per criptare un secret viene utilizzata una chiave locale, comunemente chiamata chiave di crittografia dei dati (DEK), La DEK viene quindi criptata con una seconda chiave chiamata chiave di crittografia della chiave (KEK). La KEK non viene archiviata da Kubernetes. Quando crei un nuovo secret di Kubernetes, il cluster esegue le seguenti operazioni:

  1. Il server API Kubernetes genera una DEK univoca per il secret utilizzando un generatore di numeri casuali.

  2. Il server API Kubernetes cripta il secret localmente con la DEK.

  3. Il server API Kubernetes invia la DEK ad AWS KMS per la crittografia.

  4. AWS KMS utilizza una KEK pregenerata per criptare la DEK e restituisce la DEK criptata al plug-in AWS KMS del server API Kubernetes.

  5. Il server API Kubernetes salva il secret criptato e la DEK criptata in etcd. La DEK in testo non crittografato non viene salvata su disco.

  6. Il server API Kubernetes crea una voce della cache in memoria per mappare la DEK criptata alla DEK in testo non crittografato. In questo modo, il server API può decriptare i secret a cui è stato eseguito l'accesso di recente senza eseguire query su AWS KMS.

Quando un client richiede un secret dal server API Kubernetes, ecco cosa succede:

  1. Il server API Kubernetes recupera il secret criptato e la DEK criptata da etcd.

  2. Il server API Kubernetes controlla la cache per una voce della mappa esistente e, se la trova, decripta il secret con essa.

  3. Se non esiste una voce della cache corrispondente, il server API invia la DEK a AWS KMS per la decrittografia utilizzando la KEK. La DEK decriptata viene quindi utilizzata per decriptare il secret.

  4. Infine, il server API Kubernetes restituisce il secret decriptato al client.

Rotazione chiavi

A differenza della rotazione dei certificati, rotazione della chiave è l'atto di modificare il materiale crittografico sottostante contenuto in una chiave di crittografia della chiave (KEK). Può essere attivata automaticamente nell'ambito di una rotazione pianificata o manualmente, in genere dopo un incidente di sicurezza in cui le chiavi potrebbero essere state compromesse. La rotazione delle chiavi sostituisce solo il singolo campo della chiave che contiene i dati della chiave di crittografia/decrittografia non elaborati.

Rotazione delle chiavi KMS

AWS KMS supporta la rotazione automatica delle chiavi KMS. Se abilitata, AWS genera automaticamente nuovo materiale della chiave di crittografia per la chiave una volta all'anno. Non sono richieste azioni manuali.

Per saperne di più, consulta Rotazione delle chiavi.

Attendibilità cluster

Tutte le comunicazioni del cluster utilizzano Transport Layer Security (TLS). Ogni cluster viene sottoposto a provisioning con le seguenti autorità di certificazione (CA) radice autofirmate principali:

  • La CA radice del cluster viene utilizzata per convalidare le richieste inviate al server API.
  • La CA radice etcd viene utilizzata per convalidare le richieste inviate alle repliche etcd.

Ogni cluster ha una CA radice univoca. Se la CA di un cluster viene compromessa, la CA di nessun altro cluster viene interessata. Tutte le CA radice hanno un periodo di validità di 30 anni.

Sicurezza dei nodi

GKE su AWS esegue il deployment dei workload nei node pool delle istanze AWS EC2. La sezione seguente illustra le funzionalità di sicurezza dei nodi.

Ubuntu

I nodi eseguono una versione ottimizzata del Ubuntu Ubuntu per eseguire il control plane e i nodi di Kubernetes. Per saperne di più, consulta le funzionalità di sicurezza nella documentazione di Ubuntu.

I cluster GKE implementano diverse funzionalità di sicurezza, tra cui:

  • Set di pacchetti ottimizzato

  • Kernel Linux personalizzatoGoogle Cloud

  • Account utente con limitazioni e accesso root disabilitato

Sono disponibili guide di sicurezza aggiuntive per Ubuntu, ad esempio:

Proteggi i tuoi workload

Kubernetes consente agli utenti di eseguire rapidamente il provisioning, la scalabilità e l'aggiornamento dei workload basati su container. Questa sezione descrive le tattiche che puoi utilizzare per limitare gli effetti collaterali dell'esecuzione di container su cluster e Google Cloud servizi.

Limita i privilegi dei processi dei container dei pod

Limitare i privilegi dei processi containerizzati è importante per la sicurezza del cluster. Puoi impostare le opzioni relative alla sicurezza con un contesto di sicurezza. Queste impostazioni ti consentono di modificare le impostazioni di sicurezza dei tuoi processi, ad esempio:

  • Utente e gruppo che eseguono il processo
  • Funzionalità Linux disponibili
  • Escalation dei privilegi

Il sistema operativo del nodo predefinito di GKE su AWS, Ubuntu, utilizza i criteri di sicurezza AppArmor di Docker predefiniti per tutti i container. Puoi visualizzare il modello del profilo su GitHub. Tra le altre cose, questo profilo nega ai container le seguenti funzionalità:

  • Scrittura di file direttamente in una directory ID processo (/proc/)
  • Scrittura di file non presenti in /proc/
  • Scrittura di file in /proc/sys diversi da /proc/sys/kernel/shm*
  • Montaggio di file system

Limita la capacità dei workload di modificarsi autonomamente

Alcuni workload Kubernetes, in particolare i workload di sistema, hanno l'autorizzazione a modificarsi autonomamente. Ad esempio, alcuni workload si scalano automaticamente in verticale. Sebbene sia conveniente, ciò può consentire a un autore di attacchi che ha già compromesso un nodo di eseguire un'escalation nel cluster. Ad esempio, un attaccante potrebbe fare in modo che un workload sul nodo si modifichi per essere eseguito come un account di servizio con maggiori privilegi esistente nello stesso spazio dei nomi.

Idealmente, ai workload non dovrebbe essere concessa l'autorizzazione a modificarsi autonomamente. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni installando Policy Controller o Gatekeeper nel cluster e applicando vincoli, come NoUpdateServiceAccount dalla libreria Gatekeeper open source, che fornisce diversi criteri di sicurezza utili.

Quando esegui il deployment dei criteri, in genere è necessario consentire ai controller che gestiscono il ciclo di vita del cluster di ignorare i criteri. Questa operazione è necessaria affinché i controller possano apportare modifiche al cluster, ad esempio applicare gli upgrade del cluster. Ad esempio, se esegui il deployment del criterio NoUpdateServiceAccount su GKE su AWS, devi impostare i seguenti parametri nel Constraint:

parameters:
  allowedGroups: []
  allowedUsers:
  - service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com

Sostituisci PROJECT_NUMBER con il numero (non l'ID) del progetto che ospita il cluster.

Utilizza Autorizzazione binaria

Un altro modo per proteggere i workload è abilitare Autorizzazione binaria. Autorizzazione binaria è una funzionalità di sicurezza che garantisce che sui cluster GKE venga eseguito il deployment solo delle immagini container attendibili.

Ecco come funziona il processo:

  1. Gli amministratori creano un criterio che definisce i requisiti per il deployment di un'immagine. Ciò include la specifica delle entità attendibili e autorizzate (attestatori) che possono firmare le immagini e potrebbe includere altri criteri che un'immagine deve soddisfare per essere considerata sicura per il deployment.

  2. Un attestatore (ad esempio, uno sviluppatore o un sistema automatizzato) utilizza un algoritmo crittografico per generare una coppia di chiavi (chiavi privata e pubblica).

  3. La chiave privata, che viene mantenuta segreta, viene utilizzata per generare una firma digitale (ovvero un insieme univoco di caratteri) per un'immagine. Questa firma funge da sigillo di approvazione: indica che l'immagine ha superato tutti i controlli e le convalide necessari.

  4. La firma digitale viene quindi "allegata" all'immagine. In altre parole, la firma viene archiviata nei metadati dell'immagine, in genere nel registro delle immagini.

  5. La chiave pubblica viene quindi registrata nel sistema di Autorizzazione binaria in modo che il sistema possa utilizzarla per la verifica della firma.

  6. Quando viene effettuata una richiesta di deployment di un container, il sistema di Autorizzazione binaria recupera la firma digitale allegata all'immagine nel registro.

  7. Il sistema di Autorizzazione binaria utilizza la chiave pubblica registrata per verificare la firma digitale allegata all'immagine. Verifica inoltre se l'immagine soddisfa tutti gli altri criteri definiti nel criterio. Se la firma digitale può essere verificata correttamente utilizzando la chiave pubblica e i dati dell'immagine e l'immagine soddisfa tutti gli altri criteri definiti nel criterio, il sistema di Autorizzazione binaria consente il deployment del container. Se la firma digitale non può essere verificata correttamente utilizzando la chiave pubblica e i dati dell'immagine o se l'immagine non soddisfa altri criteri definiti nel criterio, il sistema di Autorizzazione binaria nega il deployment del container.

Per saperne di più sul funzionamento di Autorizzazione binaria, consulta la panoramica di Autorizzazione binaria.

Per abilitare Autorizzazione binaria su un cluster esistente o durante la creazione di un cluster, consulta Come abilitare Autorizzazione binaria.

Isola i workload nei node pool dedicati

Puoi utilizzare le contaminazioni e le tolleranze di Kubernetes per designare node pool specifici per l'esecuzione di tipi specifici di workload. Ad esempio, puoi indicare a GKE su AWS di pianificare i workload utente lontano dalla maggior parte dei workload gestiti dal sistema o di inserire workload con livelli di attendibilità diversi in node pool diversi.

L'isolamento dei workload tramite contaminazioni e tolleranze non è una misura di sicurezza garantita. Utilizza questa funzionalità insieme alle altre misure di hardening offerte da GKE su AWS.

Per saperne di più, consulta Isolare i workload nei node pool dedicati.

Passaggi successivi