Google Kubernetes Engine (GKE) offre molti modi per proteggere i tuoi carichi di lavoro. La protezione dei carichi di lavoro in GKE coinvolge molti livelli dello stack, inclusi i contenuti dell'immagine container, il runtime del container, la rete del cluster e l'accesso al server API del cluster.
È preferibile adottare un approccio a più livelli per proteggere i cluster e i carichi di lavoro. Puoi applicare il principio del privilegio minimo al livello di accesso fornito agli utenti e alla tua applicazione. In ogni livello, la tua organizzazione potrebbe dover effettuare diversi compromessi per consentire il giusto livello di flessibilità e sicurezza per eseguire il deployment e gestire in sicurezza i carichi di lavoro. Ad esempio, alcune impostazioni di sicurezza potrebbero essere troppo restrittive per il funzionamento di determinati tipi di applicazioni o casi d'uso senza un refactoring significativo.
Questo documento fornisce una panoramica di ogni livello dell'infrastruttura e mostra come configurare le funzionalità di sicurezza in base alle tue esigenze.
Questo documento è destinato agli specialisti della sicurezza che definiscono, gestiscono e implementano policy e procedure per proteggere i dati di un'organizzazione da accessi non autorizzati. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti GKE.
Autenticazione e autorizzazione
Kubernetes supporta due tipi di autenticazione:
- I conti utente sono account noti a Kubernetes, ma non gestiti da Kubernetes. Ad esempio, non puoi crearli o eliminarli utilizzando
kubectl. - I service account sono account creati e gestiti da Kubernetes, ma possono essere utilizzati solo da entità create da Kubernetes, come i pod.
In un cluster GKE , i conti utente Kubernetes sono gestiti da Google Cloud, e possono essere di uno dei due tipi seguenti:
Una volta autenticate, devi autorizzare queste identità a creare, leggere, aggiornare o eliminare le risorse Kubernetes.
Nonostante i nomi simili, i service account Kubernetes e i Google Cloud service account sono entità diverse. I service account Kubernetes fanno parte del cluster in cui sono definiti e vengono in genere utilizzati all'interno di quel cluster. Al contrario, Google Cloud i service account fanno parte di un Google Cloud progetto e possono essere facilmente concessi le autorizzazioni sia all'interno dei cluster sia ai Google Cloud cluster di progetto stessi, nonché a qualsiasi Google Cloud risorsa che utilizzi Identity and Access Management (IAM). Questo rende i Google Cloud service account più potenti dei service account Kubernetes; per seguire il principio di sicurezza del privilegio minimo, dovresti prendere in considerazione l'utilizzo dei Google Cloud service account solo quando sono richieste le loro funzionalità.
Per configurare un accesso più granulare alle risorse Kubernetes a livello di cluster o all'interno degli spazi dei nomi Kubernetes, utilizza il controllo degli accessi basato sui ruoli (RBAC). RBAC ti consente di creare policy dettagliate che definiscono le operazioni e le risorse a cui consenti l'accesso a utenti e service account. Con RBAC, puoi controllare l'accesso per gli Account Google, Google Cloud i service account e i service account Kubernetes. Per semplificare ulteriormente la strategia di autenticazione e autorizzazione per GKE, devi assicurarti che il controllo degli accessi basato sugli attributi legacy sia disabilitato in modo che Kubernetes RBAC e IAM siano le fonti di verità.
Per ulteriori informazioni:
- Leggi la documentazione di GKE RBAC.
- Scopri di più sui metodi di autenticazione supportati quando ti connetti al server API Kubernetes in Autenticazione nel server API Kubernetes.
Sicurezza del piano di controllo
In GKE, i componenti del piano di controllo Kubernetes vengono gestiti e mantenuti da Google. I componenti del piano di controllo ospitano il software che esegue il piano di controllo Kubernetes, inclusi il server API, lo scheduler, il gestore del controller e l'API etcd. Se il cluster esegue istanze del database etcd sulle VM del piano di controllo, queste istanze vengono gestite e mantenute anche da Google.
Puoi accedere al piano di controllo utilizzando un endpoint basato su DNS (consigliato), endpoint basati su IP o entrambi. Se utilizzi endpoint basati su IP, puoi proteggere il server API Kubernetes utilizzando le reti autorizzate e non abilitando l'endpoint esterno del control plane. In questo modo puoi assegnare un indirizzo IP interno al control plane e disabilitare l'accesso all'indirizzo IP esterno. Se utilizzi un endpoint basato su DNS, puoi utilizzare IAM e i Controlli di servizio VPC per proteggere l'accesso al piano di controllo con policy basate sull'identità e sulla rete.
Puoi gestire l'autenticazione del cluster in Google Kubernetes Engine utilizzando IAM come provider di identità. Per informazioni sull'autenticazione, consulta Autenticazione nel server API Kubernetes.
Un altro modo per proteggere il piano di controllo è assicurarsi di eseguire regolarmente la rotazione delle credenziali. Quando viene avviata la rotazione delle credenziali, vengono ruotati i certificati SSL e l'autorità di certificazione del cluster. Questo processo viene automatizzato da GKE e contribuisce anche a garantire la rotazione dell'indirizzo IP del piano di controllo.
Per ulteriori informazioni:
- Scopri di più sulla sicurezza del piano di controllo.
- Leggi la documentazione sul controllo degli accessi basato sui ruoli.
- Segui la guida alla rotazione delle credenziali.
Sicurezza dei nodi
GKE esegue il deployment dei carichi di lavoro sulle istanze di Compute Engine in esecuzione nel tuo Google Cloud progetto. Queste istanze sono collegate al cluster GKE come nodi. Le sezioni seguenti mostrano come sfruttare le funzionalità di sicurezza a livello di nodo disponibili in Google Cloud.
Container-Optimized OS
Per impostazione predefinita, i nodi GKE utilizzano Container-Optimized OS di Google come sistema operativo su cui eseguire Kubernetes e i relativi componenti. Container-Optimized OS implementa diverse funzionalità avanzate per migliorare la sicurezza dei cluster GKE, tra cui:
- Firewall bloccato
- File system di sola lettura, ove possibile
- Account utente con limitazioni e accesso root disabilitato
I nodi GKE Autopilot utilizzano sempre Container-Optimized OS come sistema operativo.
Upgrade dei nodi
Una best practice consiste nell'applicare regolarmente le patch al sistema operativo. Di tanto in tanto, i problemi di sicurezza nel runtime del container, in Kubernetes stesso o nel sistema operativo del nodo potrebbero richiedere l'upgrade dei nodi con maggiore urgenza. Quando esegui l'upgrade di un nodo, il software del nodo viene aggiornato alle versioni più recenti.
I cluster GKE supportano gli upgrade automatici. Nei cluster Autopilot, gli upgrade automatici sono sempre abilitati. Puoi anche eseguire manualmente l'upgrade dei nodi in un cluster Standard.
Proteggere i nodi da carichi di lavoro non attendibili
Per i cluster che eseguono carichi di lavoro sconosciuti o non attendibili, una buona pratica consiste nel proteggere il sistema operativo sul nodo dal carico di lavoro non attendibile in esecuzione in un pod.
Ad esempio, i cluster multi-tenant come i fornitori di software as a service (SaaS) spesso eseguono codice sconosciuto inviato dai loro utenti. La ricerca sulla sicurezza è un'altra applicazione in cui i carichi di lavoro potrebbero richiedere un isolamento più forte di quello fornito dai nodi per impostazione predefinita.
Puoi abilitare GKE Sandbox sul cluster per isolare i carichi di lavoro non attendibili nelle sandbox sul nodo. GKE Sandbox è basato su gVisor, un progetto open source.
Proteggere i metadati dell'istanza
GKE utilizza metadati dell'istanza delle istanze di Compute Engine sottostanti per fornire ai nodi le credenziali e le configurazioni utilizzate per il bootstrapping dei nodi e per la connessione al piano di controllo. Questi metadati contengono informazioni sensibili a cui i pod sul nodo non devono accedere, ad esempio la chiave del account di servizio del nodo.
Puoi bloccare i percorsi dei metadati dell'istanza sensibili utilizzando
Workload Identity Federation for GKE.
Workload Identity Federation for GKE abilita il
server metadati GKE
nel cluster, che filtra le richieste ai campi sensibili come kube-env.
Workload Identity Federation for GKE è sempre abilitato nei cluster Autopilot. Nei cluster Standard, i pod hanno accesso ai metadati dell'istanza a meno che tu non abiliti manualmente Workload Identity Federation for GKE.
Sicurezza della rete
La maggior parte dei carichi di lavoro in esecuzione in GKE deve comunicare con altri servizi che potrebbero essere in esecuzione all'interno o all'esterno del cluster. Puoi utilizzare diversi metodi per controllare il traffico autorizzato a fluire attraverso i cluster e i relativi pod.
Limitare la comunicazione tra pod
Per impostazione predefinita, tutti i pod di un cluster sono raggiungibili tramite la rete tramite il loro indirizzo IP del pod. Allo stesso modo, per impostazione predefinita, il traffico in uscita consente le connessioni in uscita a qualsiasi indirizzo accessibile nel VPC in cui è stato eseguito il deployment del cluster.
Gli amministratori e gli utenti del cluster possono bloccare le connessioni in entrata e in uscita create da e verso i pod in uno spazio dei nomi utilizzando i criteri di rete. Per impostazione predefinita, quando non sono definiti criteri di rete, tutto il traffico in entrata e in uscita è consentito in tutti i pod. I criteri di rete ti consentono di utilizzare i tag per definire il traffico che transita attraverso i pod.
Una volta applicato un criterio di rete in uno spazio dei nomi, tutto il traffico viene eliminato da e verso i pod che non corrispondono alle etichette configurate. Nell'ambito della creazione di cluster e/o spazi dei nomi, puoi applicare il traffico di negazione predefinito sia in entrata che in uscita di ogni pod per assicurarti che tutti i nuovi carichi di lavoro aggiunti al cluster debbano autorizzare esplicitamente il traffico richiesto.
Per ulteriori informazioni:
- Scopri di più sui criteri di rete
- Segui il tutorial sui criteri di rete
- Scopri di più sui criteri predefiniti
Filtrare il traffico con bilanciamento del carico
Per bilanciare il carico dei pod Kubernetes con un
bilanciatore del carico di rete,
devi creare un servizio di tipo LoadBalancer che corrisponda alle etichette del pod. Una volta creato il servizio, avrai un IP esterno che esegue il mapping alle porte dei pod Kubernetes. Il filtro del traffico autorizzato viene eseguito a
livello di nodo da
kube-proxy, che
filtra in base all'indirizzo IP.
Per configurare questo filtro, puoi utilizzare la configurazione loadBalancerSourceRanges dell'oggetto Service. Con questo parametro di configurazione, puoi fornire un elenco di intervalli CIDR a cui vuoi consentire l'accesso al servizio. Se non configuri loadBalancerSourceRanges, tutti gli indirizzi possono accedere al servizio tramite il suo IP esterno.
Nei casi in cui non è richiesto l'accesso esterno al servizio, valuta la possibilità di utilizzare un
bilanciatore del carico interno.
Il bilanciatore del carico interno rispetta anche loadBalancerSourceRanges quando è necessario filtrare il traffico dall'interno del VPC.
Per ulteriori informazioni, segui il tutorial sul bilanciamento del carico interno.
Filtrare il traffico al di fuori del cluster
Per controllare il flusso di traffico di rete tra le entità esterne e il cluster, utilizza Cloud Next Generation Firewall. Puoi utilizzare le configurazioni firewall per, ad esempio, bloccare il traffico in uscita dai pod verso destinazioni non approvate.
Le configurazioni firewall non sono sufficienti per controllare i registri da cui provengono le immagini container nel cluster. Per limitare le estrazioni di immagini container a un insieme di registri approvati, consulta Bloccare le immagini container da registri non approvati.
Proteggere i 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 amministratori e utenti possono utilizzare per limitare l'effetto che un container in esecuzione può avere su altri container nello stesso cluster, sui nodi in cui possono essere eseguiti i container e sui Google Cloud servizi abilitati nei progetti degli utenti.
Limitare i privilegi per i processi dei pod containerizzati
Limitare i privilegi dei processi containerizzati è importante per la sicurezza complessiva del cluster. I cluster GKE Autopilot limitano sempre privilegi specifici, come descritto in Funzionalità di sicurezza di Autopilot.
GKE ti consente anche di impostare opzioni relative alla sicurezza tramite il contesto di sicurezza sia sui pod sia sui container. Queste impostazioni ti consentono di modificare le impostazioni di sicurezza dei processi, ad esempio:
- Utente e gruppo da eseguire come
- Funzionalità Linux disponibili
- Possibilità di aumentare i privilegi
Per applicare queste limitazioni a livello di cluster anziché a livello di pod o container, utilizza il controller PodSecurityAdmission. Gli amministratori del cluster possono utilizzare PodSecurityAdmission per assicurarsi che tutti i pod in un cluster o in uno spazio dei nomi rispettino una policy predefinita negli standard di sicurezza dei pod. Puoi anche impostare policy di sicurezza dei pod personalizzate a livello di cluster utilizzando Gatekeeper.
I sistemi operativi dei nodi GKE, sia Container-Optimized OS sia Ubuntu, applicano le policy di sicurezza AppArmor di Docker predefinite a tutti i container avviati da Kubernetes. Puoi visualizzare il modello del profilo su GitHub. Tra le altre cose, il profilo nega le seguenti funzionalità ai container:
- Scrivere file direttamente in
/proc/ - Scrivere file che non si trovano in una directory dell'ID processo (
/proc/<number>). - Scrivere file in
/proc/sysdiversi da/proc/sys/kernel/shm* - Montare i file system
Per ulteriori informazioni:
- Leggi la documentazione sul contesto di sicurezza dei pod.
- Scopri di più sulle protezioni esistenti nella documentazione di AppArmor di Container-Optimized OS.
Concedere ai pod l'accesso alle Google Cloud risorse
I container e i pod potrebbero aver bisogno di accedere ad altre risorse in Google Cloud. Esistono tre modi per farlo.
Workload Identity Federation for GKE (consigliato)
Il modo più sicuro per autorizzare i pod ad accedere alle Google Cloud risorse è utilizzare Workload Identity Federation for GKE. Workload Identity Federation for GKE consente a un account di servizio Kubernetes di essere eseguito come account di servizio IAM. I pod eseguiti come account di servizio Kubernetes hanno le autorizzazioni del account di servizio IAM.
Workload Identity Federation for GKE può essere utilizzato con GKE Sandbox.
Account di servizio del nodo
Nei cluster Standard, i pod possono anche eseguire l'autenticazione in Google Cloud utilizzando le credenziali del service account utilizzato dalla macchina virtuale (VM) Compute Engine del nodo.
Questo approccio non è compatibile con GKE Sandbox perché GKE Sandbox blocca l'accesso al server di metadati di Compute Engine.
Chiave JSON del service account (non consigliato)
Puoi concedere le credenziali per Google Cloud risorse a applicazioni utilizzando la chiave del service account. Questo approccio è fortemente sconsigliato a causa della difficoltà di gestire in sicurezza le chiavi degli account.
Se scegli questo metodo, utilizza i service account IAM personalizzati per ogni applicazione in modo che le applicazioni abbiano le autorizzazioni minime necessarie. Concedi a ogni service account i ruoli IAM minimi necessari per il corretto funzionamento dell'applicazione associata. Mantenere i service account specifici per l'applicazione semplifica la revoca dell'accesso in caso di compromissione senza influire su altre applicazioni. Dopo aver assegnato al account di servizio i ruoli IAM corretti, puoi creare una chiave JSON del account di servizio e poi montarla nel pod utilizzando un secret Kubernetes Secret.
Utilizzare Autorizzazione binaria
Autorizzazione binaria è un servizio su Google Cloud che fornisce la sicurezza della catena di fornitura del software per le applicazioni in esecuzione nel cloud. Autorizzazione binaria funziona con le immagini di cui esegui il deployment in GKE da Artifact Registry o da un altro registro di immagini container.
Con l'applicazione di Autorizzazione binaria, puoi assicurarti che i processi interni che salvaguardano la qualità e l'integrità del software vengano completati correttamente prima che sia eseguito il deployment di un'applicazione nell'ambiente di produzione. Per istruzioni sulla creazione di un cluster con Autorizzazione binaria abilitata, consulta Creare un cluster nella documentazione di Autorizzazione binaria.
Con la convalida continua (CV) di Autorizzazione binaria, puoi assicurarti che le immagini container associate ai pod vengano monitorate regolarmente per garantire che siano conformi ai processi interni in evoluzione.
Audit logging
L'audit logging consente agli amministratori di conservare, eseguire query, elaborare e inviare avvisi sugli eventi che si verificano negli ambienti GKE. Gli amministratori possono utilizzare le informazioni registrate per eseguire analisi forensi, inviare avvisi in tempo reale o catalogare la modalità di utilizzo e gli utenti di un parco risorse di cluster GKE.
Per impostazione predefinita, GKE registra i log delle attività di amministrazione. Facoltativamente, puoi anche registrare gli eventi di accesso ai dati, a seconda dei tipi di operazioni che ti interessano esaminare.
Per ulteriori informazioni:
- Segui il tutorial sull'audit logging di GKE.
- Scopri di più sugli audit log di Cloud.
Misure di sicurezza integrate
GKE applica limitazioni specifiche alle operazioni che puoi eseguire sugli oggetti di sistema nei cluster. Quando esegui un'operazione come la creazione o l'applicazione di patch a un carico di lavoro, un webhook di ammissione denominato warden-validating convalida la richiesta rispetto a un insieme di operazioni limitate e decide se consentire la richiesta.
Gli errori di ammissione causati da questa policy sono simili ai seguenti:
GKE Warden rejected the request because it violates one or more constraints.
Misure di sicurezza dei cluster Autopilot
I cluster Autopilot applicano più impostazioni di sicurezza basate sulla nostra esperienza e sulle best practice del settore. Per i dettagli, consulta Misure di sicurezza in Autopilot.
Misure di sicurezza dei cluster Standard
Per impostazione predefinita, i cluster Standard sono più permissivi dei cluster Autopilot. I cluster GKE Standard hanno le seguenti impostazioni di sicurezza:
- Non puoi aggiornare il service account utilizzato dai carichi di lavoro di sistema gestiti da GKE, ad esempio i carichi di lavoro nello spazio dei nomi
kube-system. - Non puoi associare il ClusterRole predefinito
cluster-adminai gruppisystem:anonymous,system:unauthenticatedosystem:authenticated.