Panoramica sulla sicurezza

Google Kubernetes Engine (GKE) offre molti modi per proteggere i carichi di lavoro. La protezione dei carichi di lavoro in GKE prevede 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 la protezione dei cluster e dei 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 potrebbero essere necessari diversi compromessi che consentono alla tua organizzazione di eseguire il deployment e gestire i carichi di lavoro in modo sicuro. Ad esempio, alcune impostazioni di sicurezza potrebbero essere troppo vincolanti 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 sue funzionalità di sicurezza in base alle tue esigenze.

autentica e autorizza

Kubernetes supporta due tipi di autenticazione:

  1. Gli account utente sono account noti a Kubernetes, ma non sono 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, come i pod.

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

  1. Account Google
  2. Account di servizio Google Cloud

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

Nonostante 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 sono generalmente utilizzati all'interno del cluster. Al contrario, gli account di servizio Google Cloud fanno parte di un progetto Google Cloud e possono facilmente essere concesse le autorizzazioni sia all'interno dei cluster sia ai cluster di progetto 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, dovresti valutare l'utilizzo degli account di servizio 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 di Kubernetes, utilizza il controllo degli accessi basato su ruoli (RBAC). RBAC consente di creare criteri dettagliati che definiscono le operazioni e le risorse a cui gli utenti e gli account di servizio possono 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 ottimizzare ulteriormente la strategia di autenticazione e autorizzazione per GKE, devi assicurarti che il controllo dell'accesso basato su attributi legacy sia disabilitato, in modo che Kubernetes RBAC e IAM siano le fonti attendibili.

Per ulteriori informazioni:

Sicurezza del piano di controllo

In GKE, i componenti del piano di controllo Kubernetes sono gestiti e gestiti 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 è permanente la configurazione Kubernetes.

Per impostazione predefinita, i componenti del piano di controllo utilizzano un indirizzo IP pubblico. Puoi proteggere il server API Kubernetes utilizzando reti autorizzate e cluster privati, che ti consentono di assegnare un indirizzo IP privato al piano di controllo e disabilitare l'accesso sull'indirizzo IP pubblico.

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, i certificati SSL e l'autorità di certificazione del cluster vengono ruotati. 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 su istanze di 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 di GKE utilizzano il sistema operativo ottimizzato per i container 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 il sistema operativo ottimizzato per i container.

Upgrade dei nodi

Una best practice consiste nell'eseguire una patch al sistema operativo su base regolare. Di tanto in tanto, i problemi di sicurezza relativi al runtime del container, a Kubernetes stesso o al sistema operativo nodo potrebbero richiedere un upgrade dei nodi con maggiore urgenza. Quando esegui l'upgrade del nodo, viene eseguito l'upgrade del software del nodo 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.

Protezione dei nodi da carichi di lavoro non attendibili

Per i cluster che eseguono carichi di lavoro sconosciuti o non attendibili, è buona norma 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 provider SaaS (Software-as-a-Service) spesso eseguono codice sconosciuto inviato dai propri 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.

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

Protezione dei metadati dell'istanza

GKE utilizza i metadati delle istanze delle istanze Compute Engine sottostanti per fornire ai nodi credenziali e configurazioni utilizzate per eseguire il bootstrap 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 dell'account di servizio del nodo.

Puoi bloccare i percorsi dei metadati delle istanze sensibili utilizzando Federazione delle identità per i carichi di lavoro per GKE. La federazione di Workload Identity per GKE abilita il server di metadati GKE nel tuo cluster, che filtra le richieste in base a campi sensibili come kube-env.

La federazione delle identità per i carichi di lavoro per GKE è sempre abilitata nei cluster Autopilot. Nei cluster Standard, i pod hanno accesso ai metadati dell'istanza, a meno che non abiliti manualmente la federazione di Workload Identity per GKE.

Sicurezza della rete

La maggior parte dei carichi di lavoro in esecuzione in GKE deve comunicare con altri servizi 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 in un cluster possono essere raggiunti sulla rete tramite il relativo indirizzo IP del pod. Analogamente, per impostazione predefinita, il traffico in uscita consente le connessioni in uscita verso 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, se non sono definiti criteri di rete, tutto il traffico in entrata e in uscita può entrare e uscire da tutti i pod. I criteri di rete consentono di usare i tag per definire il traffico che passa attraverso i pod.

Quando un criterio di rete viene applicato in uno spazio dei nomi, tutto il traffico viene trasferito 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 garantire che tutti i nuovi carichi di lavoro aggiunti al cluster debbano autorizzare esplicitamente il traffico richiesto.

Per ulteriori informazioni:

Filtro del traffico con bilanciamento del carico

Per bilanciare il carico dei tuoi 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 IP rivolto all'esterno che mappa alle porte sui 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 potranno accedere al servizio tramite il suo IP esterno.

Per i casi in cui l'accesso esterno al servizio non è necessario, valuta l'utilizzo di 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.

Protezione dei 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 di un container in esecuzione sugli altri container nello stesso cluster, i nodi in cui possono essere eseguiti i container e i servizi Google Cloud abilitati nei progetti degli utenti.

Limitazione dei privilegi del processo per i container dei pod

Limitare i privilegi dei processi containerizzati è importante per la sicurezza complessiva del tuo cluster. I cluster GKE Autopilot limitano sempre privilegi specifici, come descritto in Funzionalità di sicurezza di Autopilot.

GKE consente inoltre 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 pubblicare 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 dei cluster possono utilizzare PodSecurityAdmission per assicurarsi che tutti i pod in un cluster o in 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 predefiniti di Docker AppArmor a tutti i container avviati da Kubernetes. Puoi visualizzare il modello del profilo su GitHub. Tra le altre cose, il profilo denies ai container le seguenti funzionalità:

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

Per ulteriori informazioni:

Concedere ai pod l'accesso alle risorse Google Cloud

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

Il modo più sicuro per autorizzare i pod ad accedere alle risorse Google Cloud è con la federazione delle identità per i carichi di lavoro per GKE. La federazione delle identità per i carichi di lavoro per GKE consente l'esecuzione di un account di servizio Kubernetes come account di servizio IAM. I pod eseguiti come account di servizio Kubernetes hanno le autorizzazioni dell'account di servizio IAM.

La federazione delle identità per i carichi di lavoro per GKE può essere utilizzata con GKE Sandbox.

Account di servizio del nodo

Nei cluster Standard, i tuoi pod possono anche eseguire l'autenticazione in Google Cloud utilizzando le credenziali dell'account di servizio utilizzate 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.

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 degli 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 affinché l'applicazione associata funzioni correttamente. Mantenere gli account di servizio specifici per l'applicazione semplifica la revoca dell'accesso in caso di compromissione senza influire sulle altre applicazioni. Dopo aver assegnato all'account di servizio i ruoli IAM corretti, puoi creare una chiave dell'account di servizio JSON, quindi montarla nel pod utilizzando un Secret di Kubernetes.

Utilizzo di Autorizzazione binaria

Autorizzazione binaria è un servizio su Google Cloud che fornisce sicurezza della catena di fornitura del software per le applicazioni eseguite 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 garantire che i processi interni a tutela della qualità e dell'integrità del software siano stati completati correttamente prima del 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 di Autorizzazione binaria (CV), puoi garantire 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 avvisi sugli eventi che si verificano nei tuoi ambienti GKE. Gli amministratori possono utilizzare le informazioni registrate per effettuare analisi forensi, avvisi in tempo reale o per catalogare come e da chi viene utilizzato 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 interessa esaminare.

Per ulteriori informazioni:

Misure di sicurezza integrate

GKE applica restrizioni specifiche su ciò che puoi fare per gli oggetti di 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 richiesta in base a un insieme di operazioni limitate e decide se consentirla.

Misure di sicurezza dei cluster Autopilot

I cluster Autopilot applicano più impostazioni di sicurezza sulla base della nostra esperienza e delle best practice del settore. Per maggiori dettagli, consulta Misure di sicurezza in Autopilot.

Misure di sicurezza standard dei cluster

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 il 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.