Panoramica della sicurezza di GKE

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, tra cui 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 ai tuoi utenti e alla tua applicazione. In ogni livello, la tua organizzazione potrebbe dover scendere a compromessi diversi per consentire il giusto livello di flessibilità e sicurezza per eseguire il deployment e mantenere i workload in modo sicuro. 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 della tua infrastruttura e mostra come configurare le sue funzionalità di sicurezza per soddisfare al meglio le 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 scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli utente e attività comuni di GKE.

Autenticazione e autorizzazione

Kubernetes supporta due tipi di autenticazione:

  1. Gli account utente sono account noti a Kubernetes, ma non gestiti da Kubernetes. Ad esempio, non puoi crearli o eliminarli utilizzando kubectl.
  2. 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, gli account utente Kubernetes sono gestiti da Google Cloude possono essere di uno dei seguenti due tipi:

  1. Account Google
  2. Service accountGoogle Cloud

Una volta autenticate, devi autorizzare queste identità a creare, leggere, aggiornare o eliminare risorse Kubernetes.

Nonostante i nomi simili, i service account Kubernetes e i service account Google Cloud 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, i service accountGoogle Cloud fanno parte di un progetto Google Cloud e possono facilmente ricevere le autorizzazioni sia all'interno dei cluster sia per i cluster del progetto Google Cloud stessi, nonché per qualsiasi risorsa Google Cloud utilizzando Identity and Access Management (IAM). Questo rende i service account Google Cloud più potenti dei service account Kubernetes; per seguire il principio di sicurezza del privilegio minimo, dovresti prendere in considerazione l'utilizzo dei service account Google Cloud solo quando le loro funzionalità sono richieste.

Per configurare un accesso più granulare alle risorse Kubernetes a livello di cluster o all'interno degli spazi dei nomi Kubernetes, utilizza il controllo dell'accesso basato sui ruoli (RBAC). RBAC ti consente di creare policy dettagliate che definiscono le operazioni e le risorse a cui consenti l'accesso agli utenti e ai service account. Con RBAC, puoi controllare l'accesso per gli Account Google, i service account Google Cloud e i service account Kubernetes. Per semplificare e ottimizzare ulteriormente la strategia di autenticazione e autorizzazione per GKE, devi assicurarti che il controllo dell'accesso basato sugli attributi precedente sia disattivato in modo che RBAC di Kubernetes e IAM siano le fonti di riferimento.

Per ulteriori informazioni:

Sicurezza del control plane

In GKE, i componenti del control plane di Kubernetes sono gestiti e mantenuti da Google. I componenti del control plane ospitano il software che esegue il control plane Kubernetes, tra cui il server API, lo scheduler, il gestore dei controller e l'API etcd. Se il cluster esegue istanze del database etcd sulle VM del control plane, queste istanze vengono gestite e gestite anche da Google.

Puoi accedere al control plane 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 Controlli di servizio VPC per proteggere l'accesso al piano di controllo con policy basate su identità e rete.

Puoi gestire l'autenticazione del cluster in Google Kubernetes Engine utilizzando IAM come provider di identità. Per informazioni sull'autenticazione, vedi Autenticarsi nel server API Kubernetes.

Un altro modo per proteggere il tuo control plane è assicurarti di eseguire la rotazione delle credenziali regolarmente. Quando viene avviata la rotazione delle credenziali, vengono ruotati i certificati SSL e l'autorità di certificazione del cluster. Questa procedura viene automatizzata da GKE e contribuisce anche a garantire la rotazione dell'indirizzo IP del control plane.

Per ulteriori informazioni:

Sicurezza dei nodi

GKE esegue il deployment dei tuoi workload su istanze Compute Engine in esecuzione nel tuo progetto Google Cloud . 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 suoi 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 limitati e accesso root disattivato

I nodi GKE Autopilot utilizzano sempre Container-Optimized OS come sistema operativo.

Upgrade dei nodi

Una best practice consiste nell'applicare regolarmente 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 del 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 l'upgrade manuale dei nodi in un cluster Standard.

Proteggere i nodi da workload non attendibili

Per i cluster che eseguono workload sconosciuti o non attendibili, una buona pratica è proteggere il sistema operativo sul nodo dal workload 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 attivare GKE Sandbox sul tuo cluster per isolare i workload non attendibili in sandbox sul nodo. GKE Sandbox è basato su gVisor, un progetto open source.

Metadati dell'istanza sicuri

GKE utilizza i metadati dell'istanza delle istanze Compute Engine sottostanti per fornire ai nodi credenziali e configurazioni utilizzate per il bootstrap dei nodi e per connettersi al control plane. 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 delle istanze sensibili utilizzando Workload Identity Federation for GKE. Workload Identity Federation for GKE abilita il server metadati GKE nel tuo 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 la federazione delle identità dei carichi di lavoro per GKE.

Sicurezza di 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 consentito 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. Analogamente, per impostazione predefinita, il traffico in uscita consente 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 le policy di rete. Per impostazione predefinita, se non sono definite policy di rete, tutto il traffico in entrata e in uscita può fluire da e verso tutti i pod. Le policy di rete consentono di utilizzare i tag per definire il traffico che passa attraverso i pod.

Una volta applicata una policy di rete in uno spazio dei nomi, tutto il traffico viene eliminato da e verso i pod che non corrispondono alle etichette configurate. Durante la 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 workload aggiunti al cluster debbano autorizzare esplicitamente il traffico di cui hanno bisogno.

Per ulteriori informazioni:

Filtra 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. Con il servizio creato, avrai un IP rivolto all'esterno che esegue il mapping alle porte dei tuoi pod Kubernetes. Il filtraggio 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 che vuoi consentire per l'accesso al servizio. Se non configuri loadBalancerSourceRanges, tutti gli indirizzi sono autorizzati ad accedere al servizio tramite il suo IP esterno.

Per i casi in cui non è necessario 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 entità esterne e il tuo cluster, utilizza Cloud Next Generation Firewall. Puoi utilizzare le configurazioni firewall per, ad esempio, bloccare il traffico in uscita dai tuoi pod verso destinazioni non approvate.

Le configurazioni del firewall non sono sufficienti per controllare da quali registry provengono le immagini container nel cluster. Per limitare i pull delle immagini container a un insieme di registri approvati, consulta Bloccare le immagini container provenienti da registri non approvati.

Proteggi i tuoi workload

Kubernetes consente agli utenti di eseguire rapidamente il provisioning, lo scaling 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 i container possono essere eseguiti e sui servizi Google Cloud abilitati nei progetti degli utenti.

Limita 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 su pod e container. Queste impostazioni ti consentono di modificare le impostazioni di sicurezza dei tuoi processi, ad esempio:

  • Utente e gruppo da utilizzare
  • Funzionalità Linux disponibili
  • Possibilità di aumentare i privilegi

Per applicare queste limitazioni a livello di cluster anziché di pod o container, utilizza il controller PodSecurityAdmission. Gli amministratori del cluster possono utilizzare PodSecurityAdmission per garantire che tutti i pod di un cluster o di uno spazio dei nomi rispettino un criterio predefinito 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 che Ubuntu, applicano i criteri di sicurezza AppArmor di Docker predefiniti a tutti i container avviati da Kubernetes. Puoi visualizzare il modello del profilo su GitHub. Tra le altre cose, il profilo nega le seguenti capacità ai container:

  • Scrivere i file direttamente in /proc/
  • Scrittura in file che non si trovano in una directory dell'ID di processo (/proc/<number>)
  • Scrivi nei file in /proc/sys diversi da /proc/sys/kernel/shm*
  • Monta file system

Per ulteriori informazioni:

Concedi ai pod l'accesso alle risorse Google Cloud

I container e i pod potrebbero aver bisogno di accedere ad altre risorse inGoogle Cloud. Puoi farlo in tre modi.

Il modo più sicuro per autorizzare i pod ad accedere alle risorse Google Cloud è 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 che vengono eseguiti come account di servizio Kubernetes dispongono delle 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 autenticarsi suGoogle 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 metadati di Compute Engine.

Puoi concedere le credenziali per le risorse Google Cloud alle applicazioni utilizzando la chiave del service account. Questo approccio è fortemente sconsigliato a causa della difficoltà di gestire in modo sicuro le chiavi degli account.

Se scegli questo metodo, utilizza service account IAM personalizzati per ogni applicazione in modo che le applicazioni dispongano delle autorizzazioni minime necessarie. Concedi a ogni service account i ruoli IAM minimi necessari per il corretto funzionamento dell'applicazione accoppiata. 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 del account di servizio JSON e poi montarla nel pod utilizzando un secret di Kubernetes.

Utilizza Autorizzazione binaria

Autorizzazione binaria è un servizio su Google Cloud che fornisce la sicurezza della catena di fornitura del software per le applicazioni che vengono eseguite nel cloud. L'autorizzazione binaria funziona con le immagini di cui esegui il deployment su GKE da Artifact Registry o da un altro registro di immagini container.

Con l'applicazione dell'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, visita la sezione Creazione di 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 tuoi processi interni in evoluzione.

Audit logging

L'audit logging consente agli amministratori di conservare, eseguire query, elaborare e generare avvisi sugli eventi che si verificano negli ambienti GKE. Gli amministratori possono utilizzare le informazioni registrate per eseguire analisi forensi, avvisi in tempo reale o per catalogare come e da chi viene utilizzata una flotta di cluster GKE.

Per impostazione predefinita, GKE registra i log delle attività di amministrazione. Se vuoi, puoi anche registrare gli eventi di accesso ai dati, a seconda dei tipi di operazioni che ti interessano.

Per ulteriori informazioni:

Misure di sicurezza integrate

GKE applica limitazioni specifiche a ciò che puoi fare agli oggetti di sistema nei tuoi cluster. Quando esegui un'operazione come la creazione o l'applicazione di patch a un workload, un webhook di controllo dell'ammissione denominato warden-validating convalida la tua richiesta in base a un insieme di operazioni con limitazioni 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 del cluster Autopilot

I cluster Autopilot applicano più impostazioni di sicurezza in base alla nostra esperienza e alle best practice del settore. Per maggiori dettagli, vedi Misure di sicurezza in Autopilot.

Misure di sicurezza del cluster standard

I cluster Standard sono più permissivi per impostazione predefinita rispetto ai cluster Autopilot. I cluster GKE Standard hanno le seguenti impostazioni di sicurezza: