Panoramica sulla sicurezza

Google Kubernetes Engine (GKE) offre molti modi per proteggere i tuoi workload. La protezione dei carichi di lavoro in GKE coinvolge molti livelli dello stack, inclusi i contenuti dell'immagine del contenitore, il runtime del contenitore, 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 all'applicazione. In ogni livello possono essere necessari diversi compromessi per garantire il giusto livello di flessibilità e sicurezza per il deployment e la gestione in sicurezza dei carichi di lavoro della tua organizzazione. Ad esempio, alcune impostazioni di sicurezza potrebbero essere troppo limitanti per consentire a determinati tipi di applicazioni o casi d'uso di funzionare senza un refactoring significativo.

Questo documento fornisce una panoramica di ogni livello dell'infrastruttura e mostra come configurare le relative funzionalità di sicurezza in base alle tue esigenze.

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. Gli account di servizio sono account creati e gestiti da Kubernetes, ma possono essere utilizzati solo da entità create da Kubernetes, ad esempio i pod.

In un cluster GKE, gli account utente Kubernetes sono gestiti da Google Cloud e possono essere di uno dei seguenti due tipi:

  1. Account Google
  2. Account di servizio Google Cloud

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

Nonostante i nomi simili, gli account di servizio Kubernetes e gli account di servizio Google Cloud sono entità diverse. Gli account di servizio Kubernetes fanno parte del cluster in cui sono definiti e vengono in genere utilizzati all'interno di quel cluster. Al contrario, gli account di servizio Google Cloud fanno parte di un progetto Google Cloud e possono essere facilmente concesse le autorizzazioni sia all'interno dei cluster sia ai cluster dei progetti Google Cloud stessi, nonché a qualsiasi risorsa Google Cloud utilizzando Identity and Access Management (IAM). Questo rende gli account di servizio Google Cloud più potenti degli account di servizio Kubernetes. Per seguire il principio di sicurezza del privilegio minimo, ti consigliamo di utilizzare gli account di servizio Google Cloud solo quando sono necessarie le relative 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). Il RBAC ti consente di creare criteri dettagliati che definiscono le operazioni e le risorse a cui consenti agli utenti e ai service account di accedere. Con RBAC, puoi controllare l'accesso per gli Account Google, gli account di servizio Google Cloud e gli account di servizio Kubernetes. Per semplificare e snellire ulteriormente la strategia di autenticazione e autorizzazione per GKE, devi assicurarti che il controllo dell'accesso basato sugli attributi precedente sia disabilitato in modo che RBAC e IAM di Kubernetes siano le fonti attendibili.

Per ulteriori informazioni:

Sicurezza del piano di controllo

In GKE, i componenti del piano di controllo di 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 il database etcd in cui viene mantenuta la configurazione di Kubernetes.

Puoi accedere al control plane utilizzando un endpoint basato su DNS (opzione consigliata), endpoint basati su IP o entrambi. Se utilizzi endpoint basati su IP, puoi proteggere il server API Kubernetes utilizzando le reti autorizzate e disattivando l'endpoint esterno del piano di controllo. In questo modo puoi assegnare un indirizzo IP interno al piano di controllo e disattivare l'accesso sull'indirizzo IP esterno. Se utilizzi un endpoint basato su DNS, puoi utilizzare IAM e Controlli di servizio VPC per proteggere l'accesso al tuo control plane con criteri che tengono conto sia dell'identità sia della 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 dell'API Kubernetes.

Un altro modo per contribuire a proteggere il piano di controllo è assicurarti 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 è automatizzato da GKE e garantisce inoltre 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 progetto Google Cloud. Queste istanze sono collegate al tuo cluster GKE come nodi. Le sezioni seguenti mostrano come utilizzare 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 con limitazioni e accesso come utente root disabilitato

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

Upgrade dei nodi

Una best practice consiste nell'aggiornare regolarmente il sistema operativo. Di tanto in tanto, i problemi di sicurezza nel runtime del contenitore, 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.

Protezione dei nodi da carichi di lavoro non attendibili

Per i cluster che eseguono workload sconosciuti o non attendibili, è buona prassi proteggere il sistema operativo sul nodo dal carico di lavoro non attendibile in esecuzione in un pod.

Ad esempio, 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 di quello fornito dai nodi per impostazione predefinita.

Puoi attivare GKE Sandbox sul tuo cluster per isolare i carichi di lavoro non attendibili in sandbox sul nodo. GKE Sandbox è realizzato utilizzando gVisor, un progetto open source.

Protezione dei metadati delle istanze

GKE utilizza i metadati delle istanze delle istanze Compute Engine sottostanti per fornire ai nodi le credenziali e le configurazioni utilizzate per avviare i nodi e connettersi 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 delle istanze sensibili utilizzando Workload Identity Federation for GKE. La federazione delle identità per i carichi di lavoro per 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 delle istanze, a meno che non abbiate abilitato 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ò passare attraverso i tuoi cluster e i relativi pod.

Limitare la comunicazione tra pod

Per impostazione predefinita, tutti i pod di un cluster possono essere raggiunti sulla rete tramite il loro indirizzo IP. Analogamente, per impostazione predefinita, il traffico in uscita consente le connessioni in uscita a qualsiasi indirizzo accessibile nella 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 verso e dai 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 entrata e in uscita da tutti i pod. I criteri di rete ti consentono di utilizzare i tag per definire il traffico che passa attraverso i pod.

Una volta applicato un criterio di rete in uno spazio dei nomi, tutto il traffico viene eliminato verso e da pod che non corrispondono alle etichette configurate. Durante la creazione di cluster e/o spazi dei nomi, puoi applicare il traffico di rifiuto 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:

Filtrare il traffico bilanciato in base al 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 tuo pod. Una volta creato il servizio, avrai un indirizzo IP rivolto all'esterno che mappa le porte dei tuoi 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 che vorresti 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 è richiesto l'accesso esterno al Servizio, ti consigliamo di utilizzare un bilanciatore del carico interno. Il bilanciatore del carico interno rispetta anche loadBalancerSourceRanges quando è necessario filtrare il traffico dall'interno della VPC.

Per ulteriori informazioni, segui il tutorial sul bilanciamento del carico interno.

Protezione dei 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 amministratori e utenti possono impiegare 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 servizi Google Cloud abilitati nei progetti degli utenti.

Limitare i privilegi dei processi dei container dei pod

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 sia sui pod che sui container. Queste impostazioni ti consentono di modificare le impostazioni di sicurezza delle tue procedure, ad esempio:

  • Utente e gruppo da eseguire
  • Funzionalità Linux disponibili
  • Possibilità di eseguire l'escalation dei 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 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 Docker AppArmor predefiniti a tutti i container avviati da Kubernetes. Puoi visualizzare il modello del profilo su GitHub. Tra le altre cose, il profilo nega ai contenitori le seguenti funzionalità:

  • Scrivere file direttamente in /proc/
  • Scrivere in file che non si trovano in una directory di ID processo (/proc/<number>)
  • Scrivere in 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 container e i pod potrebbero dover 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 è tramite la federazione delle identità per i carichi di lavoro per GKE. La federazione delle identità per i carichi di lavoro per GKE consente a un account di servizio Kubernetes di funzionare come account di servizio IAM. I pod che vengono eseguiti come account di servizio Kubernetes dispongono delle autorizzazioni dell'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) 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 dell'account di servizio. Questo approccio è vivamente sconsigliato a causa della difficoltà di gestire in modo sicuro le chiavi dell'account.

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

Utilizzo di Autorizzazione binaria

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

Con l'applicazione dell'autorizzazione binaria, puoi assicurarti che i processi interni che salvaguardano la qualità e l'integrità del software siano stati completati correttamente prima che sia eseguito il deployment di un'applicazione nell'ambiente di produzione. Per istruzioni su come creare un cluster con Autorizzazione binaria abilitata, consulta la sezione Creare 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 verificare che siano conformi ai tuoi processi interni in evoluzione.

Audit logging

Il logging di controllo consente agli amministratori di conservare, eseguire query, elaborare e generare avvisi sugli eventi che si verificano nei tuoi ambienti GKE. Gli amministratori possono utilizzare le informazioni registrate per eseguire analisi forensi, invio di avvisi in tempo reale o per catalogare come e da chi viene utilizzato un parco 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 interessa esaminare.

Per ulteriori informazioni:

Misure di sicurezza integrate

GKE applica limitazioni specifiche a ciò che puoi fare con gli oggetti sistema nei tuoi cluster. Quando esegui un'operazione come l'applicazione di patch a un carico di lavoro, un webhook di ammissione denominato GKE Warden convalida la tua richiesta rispetto a un insieme di operazioni limitate e decide se autorizzarla.

Misure di sicurezza del cluster Autopilot

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

Misure di sicurezza standard del cluster

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

  • Non puoi aggiornare l'account 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.