Funzionalità di sicurezza di GKE Autopilot


Questa pagina descrive le funzionalità, le configurazioni e le impostazioni di sicurezza in GKE Autopilot (Google Kubernetes Engine), il modo consigliato per eseguire GKE.

Chi dovrebbe utilizzare questa pagina?

Questa pagina è rivolta agli amministratori della sicurezza che vogliono comprendere le limitazioni di sicurezza applicate da Google specificamente ai cluster Autopilot e le funzionalità di sicurezza disponibili per l'utilizzo in Autopilot.

Ti consigliamo inoltre di leggere la panoramica della sicurezza di GKE, che descrive le opzioni, le misure e i consigli di hardening che si applicano a tutti i cluster, le configurazioni di rete e i carichi di lavoro GKE.

Misure di sicurezza in Autopilot

I cluster Autopilot attivano e applicano per impostazione predefinita le impostazioni e le best practice per la sicurezza, inclusi molti dei consigli nella panoramica della sicurezza e in Migliorare la sicurezza del cluster.

Se vuoi risorse consigliate in base al tuo caso d'uso, vai a Risorse per la sicurezza in base al caso d'uso. Le sezioni seguenti descrivono i criteri di sicurezza applicati da Autopilot.

Autopilot e gli standard di sicurezza dei pod di Kubernetes

Il progetto Kubernetes dispone di un insieme di linee guida per la sicurezza denominate Standard di sicurezza dei pod che definiscono i seguenti criteri:

  • Con privilegi: nessuna limitazione di accesso. Non utilizzato in Autopilot.
  • Base: impedisce i percorsi di escalation dei privilegi noti. Consente di eseguire la maggior parte dei carichi di lavoro senza modifiche significative.
  • Con accesso limitato: il livello di sicurezza più elevato. Richiede modifiche significative alla maggior parte dei carichi di lavoro.

In modalità Autopilot, GKE applica i vincoli di sicurezza dei pod utilizzando un controller di ammissione personalizzato denominato GKE Warden. Applichiamo un criterio di sicurezza predefinito che include tutti i consigli del livello Baseline degli standard di sicurezza dei pod, con alcune modifiche per l'usabilità. Inoltre, il criterio di ammissione GKE Warden predefinito per Autopilot applica molti vincoli del livello Con restrizioni degli standard di sicurezza dei pod, ma evita le restrizioni che bloccherebbero l'esecuzione della maggior parte dei tuoi carichi di lavoro.

Se devi applicare ulteriori limitazioni per rispettare il criterio restricted completo, puoi utilizzare facoltativamente il controller di ammissione PodSecurity in spazi dei nomi specifici.

La tabella seguente descrive il confronto tra i controlli nel criterio GKE Warden predefinito per Autopilot e i controlli nei livelli Baseline e Con restrizioni degli standard di sicurezza dei pod. Per le descrizioni di ciascun controllo in questa tabella, consulta la voce corrispondente negli standard di sicurezza dei pod.

Durante la valutazione della conformità, abbiamo preso in considerazione in che modo i vincoli si applicano ai tuoi carichi di lavoro. Sono esclusi i carichi di lavoro dei partner Google Cloud verificati e i carichi di lavoro di sistema che richiedono privilegi specifici per funzionare.

Controllo Conformità alle norme di riferimento Conformità alle norme relative ai contenuti con limitazioni Informazioni aggiuntive
HostProcess Autopilot blocca HostProcess.
Spazi dei nomi host Autopilot blocca gli spazi dei nomi dell'host. Alcuni contenitori di partner verificati sono autorizzati a utilizzare gli spazi dei nomi host.
Container con privilegi Autopilot blocca i container con privilegi per impostazione predefinita. Autopilot consente i container con privilegi di partner verificati per scopi quali l'esecuzione di strumenti di sicurezza e monitoraggio.
Funzionalità di Linux

Per impostazione predefinita, i carichi di lavoro Autopilot possono accedere solo alle funzionalità specificate nello standard di sicurezza dei pod di riferimento.

Puoi attivare manualmente le seguenti funzionalità:

  • NET_RAW per il ping e SYS_PTRACE per il debug: Aggiungi a SecurityContext del pod
  • NET_ADMIN per mesh di servizi come Istio: specifica --workload-policies=allow-net-admin nel comando di creazione del cluster. Disponibile nei cluster nuovi ed esistenti di cui è stato eseguito l'upgrade che eseguono GKE 1.27 e versioni successive.

Autopilot consente inoltre ad alcuni carichi di lavoro dei partner verificati di impostare funzionalità non più disponibili.

Volumi HostPath Parzialmente conforme Parzialmente conforme Autopilot consente ai contenitori di richiedere l'accesso di sola lettura a /var/log per il debug, ma nega qualsiasi altro accesso di lettura o scrittura.
HostPorts L'impostazione di porte host specifiche non è consentita, il che riduce alcuni problemi di pianificazione, e impedisce l'esposizione diretta dei servizi alla rete accidentale o deliberata. Puoi configurare manualmente la assegnazione casuale delle porte host da un intervallo noto per supportare le applicazioni di rete con connessione diretta, come i server di gioco.
AppArmor Il profilo di sicurezza AppArmor docker-default viene applicato automaticamente a Container-Optimized OS.
SELinux SELinux non viene applicato perché AppArmor è già applicato. Anche SELinux non è obbligatorio negli standard di sicurezza dei pod.
/proc tipo di montaggio GKE non imposta il flag funzionalità ProcMountType. Se il securityContext del pod imposta procMount su "Senza maschera", GKE lo sostituisce automaticamente con "Predefinito".
profilo seccomp Autopilot applica il profilo RuntimeDefault seccomp a tutti i workload. Puoi eseguire l'override manuale di questa impostazione per workload specifici impostando il profilo su Unconfined nella specifica del pod.
sysctls GKE non imposta il flag kubelet --allowed-unsafe-sysctls, pertanto la pianificazione dei pod con sysctl non sicuri non va a buon fine. Per una protezione aggiuntiva, a partire dall'11 luglio 2023, i nuovi cluster 1.27 e versioni successive hanno anche una regola del criterio per applicare le impostazioni di securityContext e rifiutare i pod che utilizzano sysctl non sicuri.
Tipi di volume Autopilot consente solo i tipi di volumi nel criterio Con restrizioni con le seguenti aggiunte: volumi HostPath con accesso in sola lettura a /var/log per il debug, gcePersistentDisk per i dischi permanenti di Compute Engine e nfs per i volumi del file system di rete.
Escalation dei privilegi Questa impostazione fornisce protezione solo ai container non eseguiti come utente root. I sondaggi del settore mostrano che il 76% dei container viene eseguito come root, pertanto Autopilot consente l'esecuzione come root per abilitare la maggior parte dei carichi di lavoro. Al momento, questa impostazione è utile anche per rimuovere i privilegi dai carichi di lavoro non root consentendo l'utilizzo delle funzionalità del file system per aggirare le carenze nella gestione delle funzionalità di root di Kubernetes.
Esegui come utente non root I sondaggi del settore dimostrano che il 76% dei container viene eseguito come root, pertanto Autopilot consente l'esecuzione come root per abilitare la maggior parte dei carichi di lavoro.
Esegui come utente non root I container possono impostare runAsUser su 0. I sondaggi del settore dimostrano che il 76% dei container viene eseguito come root, pertanto Autopilot consente l'esecuzione come root per abilitare la maggior parte dei carichi di lavoro

Configurazioni di sicurezza integrate

Google applica molte impostazioni di sicurezza integrate ai cluster Autopilot basandosi sulle best practice del settore e sulla nostra esperienza. La tabella seguente descrive alcune delle configurazioni di sicurezza applicate da Autopilot per te:

Configurazione Descrizione
Opzioni di hosting
Funzionalità di Linux

Puoi utilizzare le seguenti funzionalità di Linux:

"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE"

Puoi anche attivare manualmente le seguenti funzionalità:

  • NET_RAW per ping: Aggiungi a Pod SecurityContext.
  • SYS_PTRACE per il debug: Aggiungi al pod SecurityContext.
  • NET_ADMIN per i mesh di servizi come Istio: utilizza --workload-policies=allow-net-admin quando crei un cluster o aggiorni un cluster esistente. Dopodiché, aggiungi la funzionalità al pod SecurityContext. Disponibile su GKE 1.27 e versioni successive.

Nelle versioni di GKE precedenti alla 1.21, la funzionalità "SYS_PTRACE" non è supportata.

Container con privilegi I container non possono essere eseguiti in modalità privilegiata, a meno che non vengano di cui non sia stato eseguito il deployment da parte di un partner Google Cloud. I contenitori con privilegi possono apportare modifiche al nodo sottostante, ad esempio modificare il kubelet. Questo accesso potrebbe aumentare l'impatto di un compromesso del Pod.
Spazi dei nomi gestiti da GKE Come misura di sicurezza, Autopilot non consente di eseguire il deployment dei carichi di lavoro negli spazi dei nomi gestiti da GKE, ad esempio kube-system.
Isolamento del container

Autopilot applica le seguenti limitazioni ai container per limitare l'impatto delle vulnerabilità di container escape.

Funzionalità di Linux e sicurezza del kernel

  • Autopilot applica il RuntimeDefault profilo seccomp a tutti i pod del cluster, a meno che i pod non utilizzino GKE Sandbox. GKE Sandbox applica l'isolamento dell'host e ignora le regole seccomp specificate nel file manifest del pod. La sandbox è considerata il confine di sicurezza per i pod GKE Sandbox.
  • Autopilot elimina la funzionalità Linux CAP_NET_RAW per tutti i container. Questa autorizzazione non viene utilizzata spesso ed è stata oggetto di più vulnerabilità di evasione. Il comando ping potrebbe non riuscire all'interno dei contenitori perché questa funzionalità viene ignorata. Puoi riattivare manualmente questa funzionalità impostandola nel SecurityContext del pod.
  • Autopilot elimina la funzionalità Linux CAP_NET_ADMIN per tutti i container. Per riattivare questa funzionalità, specifica il --workload-policies=allow-net-admin flag nel comando di creazione o aggiornamento del cluster. NET_ADMIN è obbligatorio per alcuni workload come Istio.
  • Autopilot abilita la federazione delle identità per i carichi di lavoro per GKE, che impedisce ai pod di accedere ai metadati sensibili sul nodo.
  • Autopilot blocca i servizi Kubernetes che impostano il spec.externalIPs campo per proteggersi da CVE-2020-8554.
  • Autopilot consente solo i seguenti tipi di volumi:

    "configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk", "nfs", "persistentVolumeClaim", "projected", "secret"

    Altri tipi di volumi sono bloccati perché richiedono privilegi del nodo. I volumi hostPath sono bloccati per impostazione predefinita, ma i container possono richiedere accesso di sola lettura ai percorsi /var/log per il debug.

Applicazione dei criteri di sicurezza a livello di pod Autopilot supporta i meccanismi di applicazione per i criteri di sicurezza a livello di pod, come il controller di ammissione PodSecurity, Gatekeeper o Policy Controller. Tuttavia, potresti non dover utilizzare nessuna di queste se le configurazioni di sicurezza integrate descritte in questa pagina soddisfano già i tuoi requisiti.
Accesso tramite SSH ai nodi

Autopilot blocca l'accesso SSH ai nodi. GKE gestisce tutti gli aspetti operativi dei nodi, inclusa la loro integrità e tutti i componenti Kubernetes in esecuzione sui nodi.

Puoi comunque connetterti da remoto ai container in esecuzione utilizzando la funzionalità exec di Kubernetes per eseguire comandi nei container per il debugging, inclusa la connessione a una shell interattiva, ad esempio con kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh.

Utilizzare l'identità di un altro utente GKE versione 1.22.4-gke.1501 e successive supportano l'impersonificazione dell'utente per tutti gli utenti e i gruppi definiti dall'utente. Non è possibile rubare l'identità di utenti e gruppi di sistema come l'utente kube-apiserver e il gruppo system:masters.
Mutazione dei webhook di ammissione dinamici

Autopilot modifica i webhook con mutazioni per escludere l'intercettazione delle risorse negli spazi dei nomi gestiti, come kube-system.

Autopilot rifiuta anche i webhook che specificano una o più delle seguenti risorse e le relative risorse secondarie.

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

Non puoi utilizzare il carattere jolly * per le risorse o i gruppi per bypassare questa limitazione.

ValidatingAdmissionPolicies

Autopilot modifica gli oggetti ValidatingAdmissionPolicy per escludere l'intercettazione delle risorse negli spazi dei nomi gestiti, come kube-system.

Autopilot rifiuta anche gli oggetti ValidatingAdmissionPolicy che specificano una o più delle seguenti risorse e le eventuali risorse secondarie di queste risorse.

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

Non puoi utilizzare il carattere jolly * per le risorse o i gruppi per aggirare questa limitazione.

Richieste di firma del certificato Puoi creare richieste di firma del certificato in Autopilot per creare certificati firmati dall'autorità di certificazione del cluster. Per evitare interferenze con i componenti di sistema, Autopilot rifiuta le richieste di firma del certificato per le identità privilegiate note, come gruppi di sistema, agenti di sistema o agenti di servizio IAM gestiti da Google.
Funzionalità di sicurezza di GKE I cluster Autopilot attivano per te le funzionalità di sicurezza GKE consigliate. Per un elenco di funzionalità di sicurezza attivate e facoltative, consulta le funzionalità di sicurezza in Autopilot.
Sistema operativo del nodo I cluster Autopilot utilizzano Container-Optimized OS con containerd come sistema operativo del nodo. Container-Optimized OS viene creato e gestito da Google.
Upgrade delle versioni GKE I cluster Autopilot vengono registrati in un canale di rilascio GKE al momento della creazione e gli upgrade automatici sono sempre abilitati. Google esegue automaticamente l'upgrade del piano di controllo e dei nodi alla versione qualificata più recente nel canale di rilascio nel tempo.

Confini di sicurezza in Autopilot

Autopilot fornisce l'accesso all'API Kubernetes, ma rimuove le autorizzazioni per l'utilizzo di alcune funzionalità Kubernetes ad accesso elevato, come i pod con privilegi. L'obiettivo è limitare la possibilità di accedere, modificare o controllare direttamente la macchina virtuale (VM) del nodo. Autopilot implementa queste limitazioni per impedire ai workload di avere accesso a basso livello alla VM del nodo, in modo che Google Cloud possa offrire una gestione completa dei nodi e un SLA a livello di pod.

Il nostro obiettivo è impedire l'accesso non intenzionale alla VM del nodo. Accettiamo i contenuti inviati per questo scopo tramite il programma a premi per il rilevamento delle vulnerabilità di Google (VRP) e assegneremo i premi alle segnalazioni a discrezione della commissione per i premi del programma VRP di Google.

Per impostazione predefinita, gli utenti con privilegi, come gli amministratori del cluster, hanno il controllo completo su qualsiasi cluster GKE. Come best practice di sicurezza, ti consigliamo di evitare di concedere ampiamente privilegi GKE o Kubernetes potenti e di utilizzare invece la delega dell'amministratore dello spazio dei nomi, se possibile, come descritto nelle nostre linee guida sulla multitenancy.

Autopilot esegue il provisioning di VM single-tenant nel tuo progetto per il tuo uso esclusivo. Su ogni singola VM, i carichi di lavoro Autopilot potrebbero essere eseguiti insieme, condividendo un kernel rafforzato per la sicurezza. Poiché il kernel condiviso rappresenta un singolo confine di sicurezza, se hai bisogno di un isolamento rigoroso, ad esempio per carichi di lavoro ad alto rischio o non attendibili, ti consigliamo di eseguirli su pod GKE Sandbox per fornire protezione di sicurezza a più livelli.

Risorse di sicurezza in base al caso d'uso

Le sezioni seguenti forniscono link e consigli per pianificare, implementare e gestire la sicurezza dei cluster Autopilot in base al caso d'uso.

Pianifica la sicurezza del cluster

Caso d'uso Risorse
Informazioni sull'approccio alla sicurezza di GKE come piattaforma
Comprendi il tuo ruolo nel rafforzare l'ambiente Scopri di più sul modello di responsabilità condivisa.
Visualizza i consigli di Google per le misure di rafforzamento e la risposta agli incidenti
Informazioni su come GKE implementa il logging di controllo

Autenticare e autorizzare

Dopo aver configurato i cluster Autopilot, potresti dover autenticare gli utenti e le applicazioni per utilizzare risorse come l'API Kubernetes o le API Google Cloud.

Caso d'uso Risorse
Autentica gli utenti o le applicazioni nel server API del cluster
Autentica le applicazioni per le API e i servizi Google Cloud I cluster Autopilot ti consentono di utilizzare la federazione delle identità per i carichi di lavoro per GKE per autenticare in modo sicuro i tuoi carichi di lavoro alle API Google Cloud configurando gli account di servizio Kubernetes in modo che agiscano come account di servizio IAM. Per le istruzioni, consulta Configurare le applicazioni per utilizzare Workload Identity Federation per GKE.
Autorizzare le azioni a livello di progetto Per autorizzare le azioni tra i cluster a livello di progetto, utilizza IAM. Puoi concedere o negare l'accesso a risorse API GKE e Kubernetes specifiche utilizzando i ruoli e le autorizzazioni IAM. Per le istruzioni, consulta Creare criteri IAM.
Autorizzare le azioni a livello di cluster Per autorizzare le azioni sulle risorse dell'API Kubernetes in cluster specifici, utilizza il meccanismo di controllo dell'accesso basato su ruoli (RBAC) di Kubernetes integrato. Per istruzioni, consulta Autorizzare le azioni nei cluster utilizzando RBAC.
Autorizzare le azioni a livello di organizzazione Puoi utilizzare il servizio Google Cloud Organization Policy per applicare vincoli su operazioni specifiche sulle risorse GKE nella tua organizzazione Google Cloud. Per le istruzioni, consulta Limitare le azioni sulle risorse GKE utilizzando criteri dell'organizzazione personalizzati.

Rafforzamento della sicurezza di cluster e carichi di lavoro

Se hai requisiti di isolamento o hardening specializzati oltre alle misure di Autopilot preconfigurate, valuta le seguenti risorse:

Caso d'uso Risorse
Limitare l'accesso pubblico all'endpoint del cluster Configura l'isolamento della rete dei cluster Autopilot e disabilita l'endpoint esterno del control plane del cluster. Per le istruzioni, consulta Configurare l'accesso al control plane.
Limitare l'accesso del cluster a reti specifiche Utilizza le reti autorizzate del control plane per specificare gli intervalli di indirizzi IP che possono accedere al tuo cluster.
Memorizzare informazioni sensibili all'esterno del cluster L'archiviazione di dati sensibili in un provider di archiviazione esterno criptato con la funzionalità di versionamento attivata è un requisito di conformità comune e una best practice. Utilizza Secret Manager per archiviare i dati e accedervi dai tuoi cluster Autopilot utilizzando la federazione delle identità per i carichi di lavoro per GKE. Per istruzioni, consulta Accedere agli oggetti Secret archiviati al di fuori dei cluster GKE utilizzando la federazione delle identità per i carichi di lavoro per GKE.
Verifica le immagini container prima del deployment nel cluster Utilizza Autorizzazione binaria per verificare l'integrità delle immagini container richiamate nei manifest dei pod al momento del deployment. Per le istruzioni, consulta Verificare le immagini container al momento del deployment utilizzando Autorizzazione binaria.

Monitora la tua security posture

Dopo aver configurato i cluster e aver eseguito il deployment dei carichi di lavoro, devi impostare e configurare il monitoraggio e la registrazione in modo da avere l'osservabilità della postura di sicurezza del cluster. Ti consigliamo di procedere come segue:

  • Registra i tuoi cluster nella dashboard della strategia di sicurezza di GKE per eseguire il controllo dei workload alla ricerca di problemi come configurazioni di sicurezza problematiche o vulnerabilità nei pacchetti del sistema operativo del contenitore e ricevi informazioni utili per la mitigazione.
  • Ricevi notifiche relative a nuovi bollettini sulla sicurezza ed eventi di upgrade utilizzando notifiche sul cluster.
  • Osserva i tuoi cluster utilizzando la dashboard GKE in Cloud Monitoring o la scheda Osservabilità in GKE.
  • Scopri come visualizzare e gestire i log di controllo GKE in Cloud Logging.

Passaggi successivi