Panoramica sulla sicurezza

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

I cluster GKE offrono funzionalità per proteggere i tuoi workload, inclusi i contenuti dell'immagine del 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 saperne di più, 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 at-rest nei volumi etcd e di archiviazione utilizzando le 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 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 attivano 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 utenti malintenzionati ottengono l'accesso al volume sottostante in cui sono archiviati i dati etcd, questi dati sono criptati.

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

Come funziona la crittografia a livello di applicazione

Kubernetes offre la crittografia a livello di applicazione con una tecnica nota come crittografia dell'involucro. Per criptare un segreto viene utilizzata una chiave locale, comunemente chiamata chiave di crittografia dei dati (DEK). La DEK stessa 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 tuo cluster:

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

2. Il server dell'API Kubernetes cripta il segreto localmente con la chiave 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 segreto criptato e il DEK criptato in etcd. Il DEK in testo non viene salvato sul disco.

6. Il server API Kubernetes crea una voce della cache in memoria per mappare il DEK criptato al DEK in testo normale. In questo modo, il server API decripta i secret a cui è stato eseguito l'accesso di recente senza eseguire query su Azure Key Vault.

Quando un client richiede un segreto dal server dell'API Kubernetes, accade quanto segue:

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

2. Il server dell'API Kubernetes controlla se nella cache è presente una voce di 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 poi utilizzata per decriptare il secret.

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

Configura la crittografia con il firewall Key Vault

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

Per aumentare la sicurezza di Azure Key Vault, puoi attivare il firewall di Azure Key Vault. GKE on Azure può quindi utilizzare una chiave pubblica per la crittografia ed evitare l'accesso di rete alla cassetta di sicurezza.

Per configurare il firewall, scarica la chiave di Key Vault con Azure CLI. La chiave viene passata a --config-encryption-public-key quando crei un cluster con Google Cloud CLI.

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

Rotazione chiavi

A differenza della rotazione dei certificati, la rotazione della chiave consiste nell'atto di 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 o manualmente, solitamente dopo un incidente di sicurezza in cui le chiavi potrebbero essere state compromesse. La rotazione della chiave sostituisce solo il singolo campo della chiave contenente i dati non elaborati della chiave di crittografia/decrittografia.

Per ulteriori informazioni, consulta la sezione Rotazione delle chiavi.

Attendibilità cluster

Tutte le comunicazioni del cluster utilizzano Transport Layer Security (TLS). Per ogni cluster viene eseguito il provisioning delle 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 carichi di lavoro nei pool di nodi 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 piano di controllo e i nodi Kubernetes. Per ulteriori informazioni, 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 come utente root disabilitato

Per Ubuntu sono disponibili altre guide sulla sicurezza, ad esempio:

• CIS Benchmark

• DISA STIG

• FIPS 140-2

Proteggi i tuoi carichi di lavoro

Kubernetes consente agli utenti di eseguire il provisioning, scalare e aggiornare rapidamente i carichi di lavoro basati su container. Questa sezione descrive le tattiche che puoi utilizzare per limitare gli effetti collaterali dell'esecuzione di contenitori sui cluster e sui servizi. Google Cloud

Limita i privilegi dei processi dei container di pod

Limitare i privilegi dei processi in container è importante per la sicurezza del tuo cluster. Puoi impostare le opzioni relative alla sicurezza con un contesto di sicurezza. Queste impostazioni ti consentono di modificare le impostazioni di sicurezza delle tue procedure, 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 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 contenitori le seguenti funzionalità:

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

Limitare la capacità dei carichi di lavoro di automodificarsi

Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione per automodificarsi. Ad esempio, alcuni carichi di lavoro eseguono la scalabilità automatica verticale. Sebbene sia comodo, questo può consentire a un malintenzionato che ha già compromesso un nodo di eseguire un'ulteriore riassegnazione nel cluster. Ad esempio, un malintenzionato potrebbe modificare un carico di lavoro sul nodo in modo che venga eseguito come account di servizio con privilegi maggiori esistente nello stesso spazio dei nomi.

Idealmente, non dovrebbe essere concessa l'autorizzazione ai workload per modificarsi. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni installando Policy Controller o Gatekeeper nel cluster e applicando vincoli, ad esempio NoUpdateServiceAccount dalla libreria open source Gatekeeper, 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 aggirarli. 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 in pool di nodi dedicati

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

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

Per scoprire di più, consulta Isolare i workload in pool di nodi dedicati.

Passaggi successivi

• Scopri di più sulla rotazione delle chiavi.