Panoramica sulla sicurezza

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

I cluster GKE offrono funzionalità per proteggere i tuoi carichi di lavoro, inclusi i contenuti dell'immagine container, il runtime del 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 maggiori informazioni, consulta Responsabilità condivise dei cluster GKE.

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 Azure cripta i dati in etcd e nei volumi di archiviazione at-rest utilizzando chiavi gestite dalla piattaforma Azure.

I cluster GKE su Azure archiviano i dati nei volumi di dischi Azure. Questi volumi sono sempre criptati at-rest utilizzando le chiavi di Azure Key Vault. Quando crei cluster e pool di nodi, puoi fornire una chiave di Key Vault gestita dal cliente per criptare i volumi del disco sottostanti del cluster. Se non specifichi una chiave, Azure utilizza la chiave gestita da Azure predefinita all'interno della regione Azure in cui viene eseguito 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, puoi fornire una chiave Azure Key Vault nel parametro --database-encryption-kms-key-arn. Questa chiave viene utilizzata per criptare i dati della tua applicazione. Se non fornisci una chiave durante la creazione del cluster, GKE su Azure ne crea una automaticamente per il tuo cluster. Questo campo della risorsa è immutabile e non può essere modificato dopo la creazione del cluster.

Puoi anche creare manualmente una chiave Key Vault o portare la tua chiave (BYOK) con un modulo di sicurezza hardware (HSM). Per ulteriori informazioni, vedi Bring Your Own Key.

Come funziona la crittografia a livello di applicazione

Kubernetes offre la crittografia a livello di applicazione con una tecnica nota come crittografia envelope. Una chiave locale, comunemente chiamata chiave di crittografia dei dati (DEK), viene utilizzata per criptare un secret. La DEK viene poi criptata con una seconda chiave chiamata chiave di crittografia della chiave (KEK). La KEK non viene archiviata da Kubernetes. Quando crei un nuovo secret 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 Azure Key Vault per la crittografia.

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

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

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

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

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

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

  3. Se non esiste una voce della cache corrispondente, il server API invia la DEK ad Azure Key Vault 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.

Crittografia della configurazione con il firewall di Key Vault

Se trasmetti una chiave pubblica per la crittografia, l'entità di servizio non ha bisogno dell'autorizzazione per criptare, ma ha bisogno dell'autorizzazione per gestire le assegnazioni di ruolo. Il modo più semplice per farlo è assegnare il ruolo User Access Administrator integrato di Azure al service principal.

Per proteggere ulteriormente Azure Key Vault, puoi abilitare il firewall di Azure Key Vault. GKE su Azure può quindi utilizzare una chiave pubblica per la crittografia ed evitare l'accesso di rete al Key Vault.

Per configurare il firewall, devi scaricare la chiave Key Vault con l'interfaccia a riga di comando di Azure. Passa la chiave a --config-encryption-public-key quando crei un cluster con Google Cloud CLI.

Devi comunque abilitare gli endpoint di servizio per Key Vault in tutte le subnet utilizzate per il cluster. Per saperne di più, vedi Endpoint di servizio di rete virtuale per Azure Key Vault.

Rotazione chiavi

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

Per ulteriori informazioni, consulta la sezione 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 Azure esegue il deployment dei tuoi workload sui node pool delle istanze VM di Azure. La sezione seguente illustra le funzionalità di sicurezza dei nodi.

Ubuntu

I nodi eseguono una versione ottimizzata del sistema operativo 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 le seguenti:

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

Proteggere i carichi di lavoro

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

Limitare i privilegi di processo dei container di pod

Limitare i privilegi dei processi in container è importante per la sicurezza del tuo cluster. Puoi impostare 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 GKE su Azure predefinito, Ubuntu, utilizza i criteri di sicurezza Docker AppArmor predefiniti per tutti i container. Puoi visualizzare il modello del profilo su GitHub. Tra le altre cose, questo profilo nega ai container le seguenti capacità:

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

Limitare la capacità dei workload di automodificarsi

Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione per modificarsi autonomamente. Ad esempio, alcuni carichi di lavoro vengono scalati automaticamente in verticale. Sebbene comoda, questa operazione può consentire a un malintenzionato che ha già compromesso un nodo di ottenere privilegi più elevati nel cluster. Ad esempio, un malintenzionato potrebbe fare in modo che un workload sul nodo venga eseguito come un account di servizio con più privilegi che esiste nello stesso spazio dei nomi.

Idealmente, ai workload non dovrebbe essere concessa l'autorizzazione a modificarsi in primo luogo. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni installando Policy Controller o Gatekeeper nel tuo cluster e applicando vincoli, ad esempio NoUpdateServiceAccount dalla libreria open source Gatekeeper, che fornisce diverse norme di sicurezza utili.

Quando implementi i criteri, in genere è necessario consentire ai controller che gestiscono il ciclo di vita del cluster di ignorare i criteri. Questo è necessario 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 Azure, devi impostare i seguenti parametri in 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.

Isolare i carichi di lavoro su pool di nodi dedicati

Puoi utilizzare incompatibilità e tolleranze di Kubernetes per designare pool di nodi specifici per eseguire tipi specifici di carichi di lavoro. Ad esempio, puoi indicare a GKE su Azure di pianificare i carichi di lavoro degli utenti lontano dalla maggior parte dei carichi di lavoro gestiti dal sistema o di posizionare i carichi di lavoro con diversi livelli di attendibilità in pool di nodi diversi.

L'isolamento dei carichi di lavoro mediante incompatibilità e tolleranze non è una misura di sicurezza garantita. Utilizza questa opzione solo insieme alle altre misure di protezione offerte da GKE su Azure.

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

Passaggi successivi