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 fare compromessi diversi per consentire il giusto livello di flessibilità e sicurezza per eseguire il deployment e gestire in modo sicuro i tuoi 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 scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE Enterprise.

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 due tipi seguenti:

  1. Account Google
  2. Google Cloud service account

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

Nonostante i nomi simili, gli account di servizio Kubernetes e gli Google Cloud account di servizio sono entità diverse. Gli account di servizio Kubernetes fanno parte del cluster in cui sono definiti e vengono in genere utilizzati all'interno di questo cluster. Al contrario, gli account di servizioGoogle Cloud fanno parte di un progetto Google Cloud e possono facilmente ricevere autorizzazioni sia all'interno dei cluster sia per i cluster di progetto Google Cloud stessi, nonché per qualsiasi risorsa Google Cloud utilizzando Identity and Access Management (IAM). Ciò rende i service account Google Cloud più potenti dei service account Kubernetes; per seguire il principio di sicurezza dei privilegi minimi, devi prendere in considerazione l'utilizzo dei service account Google Cloud solo quando sono necessarie 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 criteri dettagliati che definiscono a quali operazioni e risorse 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 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 piano di controllo

In GKE, i componenti del control plane di Kubernetes vengono gestiti e gestiti da Google. I componenti del control plane ospitano il software che esegue il control plane 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, anche queste istanze vengono gestite e mantenute 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 control plane 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 Autenticazione nel server dell'API Kubernetes.

Un altro modo per proteggere il piano di controllo è assicurarsi 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. Questo processo è automatizzato da GKE e garantisce anche la rotazione dell'indirizzo IP del piano di controllo.

Per ulteriori informazioni:

Sicurezza dei nodi

GKE esegue il deployment dei carichi di lavoro sulle istanze Compute Engine in esecuzione nel tuo progetto Google Cloud . Queste istanze sono collegate al tuo 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, se possibile
  • Account utente limitati 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 in modo più urgente. 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 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 è 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ù efficace rispetto a 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 è creato utilizzando gVisor, un progetto open source.

Metadati dell'istanza sicuri

GKE utilizza i metadati dell'istanza delle istanze di Compute Engine sottostanti per fornire ai nodi credenziali e configurazioni utilizzate per il bootstrap dei nodi e per la connessione al control plane. Questi metadati contengono informazioni sensibili a cui i pod sul nodo non devono accedere, ad esempio la chiave delaccount di serviziot del nodo.

Puoi bloccare i percorsi dei metadati delle istanze sensibili utilizzando Workload Identity Federation for GKE. Workload Identity Federation per GKE abilita il server metadati GKE nel cluster, che filtra le richieste ai campi sensibili come kube-env.

Workload Identity Federation for GKE è sempre abilitata 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à per i carichi di lavoro per 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 che può attraversare i tuoi 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 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 scorre 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. 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 garantire che tutti i nuovi workload aggiunti al cluster debbano autorizzare esplicitamente il traffico di cui hanno bisogno.

Per ulteriori informazioni:

Filtra il traffico bilanciato 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 possono 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 saperne di più, segui il tutorial sul bilanciamento del carico interno.

Filtra 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 firewall non sono sufficienti per controllare da quali registri 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.

Proteggere i carichi di lavoro

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 contenitore in esecuzione può avere su altri contenitori nello stesso cluster, sui nodi in cui possono essere eseguiti i contenitori e sui Google Cloud servizi abilitati nei progetti degli utenti.

Limitare i privilegi per i processi dei pod containerizzati

Limitare i privilegi dei processi in container è 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 per l'esecuzione
  • Funzionalità Linux disponibili
  • Possibilità di elevare 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 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 criteri di sicurezza dei pod personalizzati 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 ai container le seguenti capacità:

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

Per ulteriori informazioni:

Concedere ai pod l'accesso alle risorse Google Cloud

I tuoi container e pod potrebbero aver bisogno di accedere ad altre risorse in Google Cloud. Puoi procedere in tre modi.

Il modo più sicuro per autorizzare i pod ad accedere alle risorse Google Cloud è con 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 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 su Google Cloud utilizzando le credenziali dell'account di servizio utilizzato dalla macchina virtuale (VM) di 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 dell'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 gli account di servizio specifici per l'applicazione semplifica la revoca dell'accesso in caso di compromissione senza influire su altre applicazioni. Dopo aver assegnato all'account di servizio i ruoli IAM corretti, puoi creare una chiave dell'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. 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, consulta Creazione di un cluster nella documentazione di Autorizzazione binaria.

Con la convalida continua (CV) dell'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

Il logging di controllo consente agli amministratori di conservare, interrogare, elaborare e inviare avvisi sugli eventi che si verificano nei tuoi 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 questo criterio 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:

  • Non puoi aggiornare ServiceAccount 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-admin ai gruppi system:anonymous, system:unauthenticated o system:authenticated.