Panoramica sulla sicurezza

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

I cluster GKE offrono funzionalità che ti aiutano a proteggere i carichi di lavoro, compresi 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 KMS di AWS

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

Per gli ambienti di produzione, consigliamo di utilizzare chiavi diverse per la configurazione e la crittografia del volume. Per ridurre al minimo i rischi se una chiave viene compromessa, puoi anche creare chiavi diverse per ognuno degli elementi seguenti:

Per maggiore sicurezza, puoi creare un criterio della chiave KMS di AWS che assegni solo l'insieme minimo di autorizzazioni richiesto. Per ulteriori informazioni, consulta Creazione di chiavi KMS con autorizzazioni specifiche.

Crittografia dei dati at-rest

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

GKE su cluster AWS archivia i dati nei volumi AWS Elastic Block Storage (EBS). Questi volumi EBS vengono sempre criptati at-rest con chiavi AWS Key Management System (AWS KMS). Quando crei cluster e pool di nodi, 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 all'interno della regione AWS in cui viene eseguito il cluster.

Inoltre, tutti i cluster GKE abilitano la crittografia dei secret a livello di applicazione per dati sensibili, come gli oggetti Secret di Kubernetes, archiviati in etcd. Anche se i malintenzionati riescono ad accedere al volume sottostante in cui sono archiviati i dati etcd, questi dati rimangono criptati.

Quando crei un cluster, devi passare una chiave KMS di AWS al campo --database-encryption-kms-key-arn. Questa chiave viene utilizzata per la crittografia busta dei dati dell'applicazione. Poiché questo campo delle risorse è immutabile e non può essere modificato dopo la creazione del cluster, ti consigliamo di utilizzare un alias della chiave KMS. Puoi utilizzare alias chiave 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 comunemente una chiave locale, comunemente chiamata chiave di crittografia dei dati (DEK). La DEK viene quindi criptata con una seconda chiave denominata chiave di crittografia della chiave (KEK). La KEK non viene archiviata da Kubernetes. Quando crei un nuovo secret di Kubernetes, il cluster effettua 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 in locale con la DEK.

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

  4. AWS KMS utilizza una KEK pregenerata per criptare la DEK e restituisce quella criptata al plug-in KMS AWS 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 al KMS AWS.

Quando un client richiede un secret al 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 nella cache la presenza di una voce della mappa esistente e, se trovata, decripta il secret con questa voce.

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

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

Rotazione chiavi

A differenza della rotazione dei certificati, la rotazione della chiave è l'atto di modificare il materiale crittografico sottostante contenuto in una chiave di crittografia della chiave (KEK). Può essere attivato automaticamente come parte di una rotazione pianificata o 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 nella chiave che contiene i dati non elaborati della chiave di crittografia/decrittografia.

Rotazione della chiave KMS

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

Per ulteriori informazioni, consulta Rotazione della chiave.

Attendibilità cluster

Tutte le comunicazioni tra cluster utilizzano TLS (Transport Layer Security). A ogni cluster viene eseguito il provisioning delle seguenti autorità di certificazione principali autofirmate:

  • 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 è compromessa, la CA di nessun altro cluster è interessata. Tutte le CA principali hanno un periodo di validità di 30 anni.

Sicurezza dei nodi

GKE su AWS esegue il deployment dei tuoi carichi di lavoro su pool di nodi delle istanze AWS EC2. La seguente sezione illustra le funzionalità di sicurezza dei nodi.

Ubuntu

I nodi eseguono una versione ottimizzata del sistema operativo Ubuntu per eseguire i nodi e il piano di controllo Kubernetes. Per ulteriori informazioni, consulta la sezione sulle funzionalità di sicurezza nella documentazione di Ubuntu.

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

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

Proteggi i tuoi carichi di lavoro

Kubernetes consente agli utenti di eseguire rapidamente il provisioning, la scalabilità 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 dei container sui cluster e sui servizi Google Cloud.

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 processi, ad esempio:

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

Ubuntu, il sistema operativo GKE predefinito su nodo AWS, utilizza i criteri di sicurezza predefiniti di Docker AppArmor 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 nei file direttamente in una directory di ID di processo (/proc/)
  • Scrittura in file non in /proc/
  • Scrittura in file in /proc/sys diversa da /proc/sys/kernel/shm*
  • Montaggio di file system

Limita la capacità dei carichi di lavoro di auto-modificarsi

Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione alla modifica automatica. Ad esempio, alcuni carichi di lavoro scalano automaticamente verticalmente. Sebbene sia pratico, questo può consentire a un utente malintenzionato che ha già compromesso un nodo di eseguire un'ulteriore scalabilità nel cluster. Ad esempio, un utente malintenzionato potrebbe gestire automaticamente un carico di lavoro sul nodo in modo che venga eseguito come account di servizio con privilegi più elevati, che esiste nello stesso spazio dei nomi.

Idealmente, ai carichi di lavoro non dovrebbe essere concessa l'autorizzazione per modificare autonomamente. Se è necessaria l'automodifica, puoi limitare le autorizzazioni installando Policy Controller o Gatekeeper nel tuo cluster e applicando vincoli, ad esempio 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 bypassare i criteri. Questo è necessario affinché i controller possano apportare modifiche al cluster, ad esempio applicare upgrade del cluster. Ad esempio, se esegui il deployment del criterio NoUpdateServiceAccount su GKE su AWS, 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.

Utilizza Autorizzazione binaria

Un altro modo per proteggere i carichi di lavoro è abilitare Autorizzazione binaria. Autorizzazione binaria è una funzionalità di sicurezza che garantisce il deployment nei cluster GKE solo delle immagini container attendibili.

Ecco come funziona la procedura:

  1. Gli amministratori creano un criterio che definisce i requisiti per il deployment di un'immagine. Ciò include specificare le 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 private e pubbliche).

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

  4. La firma digitale viene quindi "allegata" all'immagine. In altre parole, la firma viene archiviata nei metadati dell'immagine, solitamente 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 per il deployment di un container, il sistema Autorizzazione binaria recupera la firma digitale associata all'immagine nel registro.

  7. Il sistema Autorizzazione binaria utilizza la chiave pubblica registrata per verificare la firma digitale allegata all'immagine. Inoltre, verifica se l'immagine soddisfa tutti gli altri criteri definiti nel criterio. Se è possibile verificare la firma digitale utilizzando la chiave pubblica e i dati dell'immagine e se l'immagine soddisfa tutti gli altri criteri definiti nel criterio, il sistema di Autorizzazione binaria consente il deployment del container. Se non è possibile verificare la firma digitale 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 ulteriori informazioni 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, vedi Come abilitare Autorizzazione binaria.

Isola i carichi di lavoro su pool di nodi dedicati

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

L'isolamento dei carichi di lavoro tramite incompatibilità e tolleranze non è una misura di sicurezza garantita. Utilizza questa soluzione insieme alle altre misure di protezione avanzata offerte da GKE su AWS.

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

Passaggi successivi