Funzionalità di sicurezza di GKE Autopilot

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

Chi dovrebbe utilizzare questa pagina?

Questa pagina è rivolta agli amministratori della sicurezza che vogliono conoscere le limitazioni di sicurezza che Google applica in modo specifico ai cluster Autopilot e le funzionalità di sicurezza disponibili per l'uso in Autopilot.

Devi leggere anche la panoramica sulla sicurezza di GKE, in cui vengono descritte le opzioni, le misure e i suggerimenti di protezione avanzata applicabili a tutti i cluster GKE, le configurazioni di rete e i carichi di lavoro.

Misure di sicurezza in Autopilot

I cluster Autopilot abilitano e applicano le best practice e le impostazioni di sicurezza per impostazione predefinita, inclusi molti dei suggerimenti nella panoramica sulla sicurezza e in Rafforzare la sicurezza del cluster.

Se vuoi risorse consigliate in base al tuo caso d'uso, passa a Risorse di sicurezza per caso d'uso. Le seguenti sezioni descrivono i criteri di sicurezza che Autopilot applica per te.

Autopilot e gli standard di sicurezza dei pod di Kubernetes

Il progetto Kubernetes ha una serie 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 di riferimento: impedisce i percorsi noti di escalation dei privilegi. Consente di eseguire la maggior parte dei carichi di lavoro senza modifiche significative.
  • Limitata: il livello di sicurezza più elevato. Richiede modifiche significative alla maggior parte dei carichi di lavoro.

Autopilot applica il criterio Baseline con alcune modifiche per l'usabilità. Autopilot applica anche molti vincoli del criterio Limitato, ma evita le restrizioni che bloccano l'esecuzione della maggior parte dei carichi di lavoro. Autopilot applica questi vincoli a livello di cluster utilizzando un controller di ammissione controllato da Google. Se devi applicare ulteriori restrizioni per rispettare la versione completa del criterio Restricted, puoi facoltativamente utilizzare il controller di ammissione PodSecurity in spazi dei nomi specifici.

La seguente tabella descrive in che modo i cluster Autopilot implementano i criteri di base e con restrizioni. Per descrizioni di ogni controllo in questa tabella, consulta la voce corrispondente in Standard di sicurezza dei pod.

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

Controllo Conformità alle norme di riferimento Conformità alle norme limitata Informazioni aggiuntive
HostProcess Autopilot blocca HostProcess.
Spazi dei nomi host Autopilot blocca gli spazi dei nomi dell'host. Alcuni container di partner verificati possono utilizzare gli spazi dei nomi dell'host.
Container con privilegi Autopilot blocca i container con privilegi per impostazione predefinita. Autopilot consente i container con privilegi di partner verificati per scopi come l'esecuzione di strumenti di sicurezza e monitoraggio.
Funzionalità Linux

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

Puoi attivare manualmente le seguenti funzionalità:

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

Autopilot consente anche ad alcuni carichi di lavoro dei partner verificati di impostare funzionalità eliminate.
Volumi HostPath Parzialmente conforme Parzialmente conforme Autopilot consente ai container di richiedere l'accesso di sola lettura a /var/log per il debug, ma nega tutti gli altri accessi in lettura o scrittura.
HostPorts Non è consentito impostare porte host specifiche, il che riduce alcuni problemi di pianificazione e impedisce l'esposizione diretta accidentale o intenzionale dei servizi alla rete. Puoi configurare manualmente l'assegnazione casuale delle porte dell'host da un intervallo noto per supportare le applicazioni di rete con connessione diretta come i server di gioco.
AppArmor Il profilo di sicurezza predefinito per Docker di AppArmor viene applicato automaticamente a Container-Optimized OS.
SELinux SELinux non è stato applicato perché AppArmor è già applicato. Inoltre, SELinux non è obbligatorio negli standard di sicurezza dei pod.
/proc tipo di montaggio GKE non imposta il flag funzionalità ProcMountType. Se securityContext del pod imposta procMount su "Unmasked", GKE lo sostituisce automaticamente con "Default".
profilo seccomp Autopilot applica il profilo seccomp RuntimeDefault a tutti i carichi di lavoro. Puoi eseguire manualmente l'override di questa impostazione per carichi di lavoro specifici impostando il profilo su Unconfined nella specifica del pod.
sysctl GKE non imposta il flag kubelet --allowed-unsafe-sysctls, pertanto i pod con sysctls non sicuri non vengono pianificati. Per ulteriore protezione, a partire dall'11 luglio 2023, i nuovi cluster 1.27 e versioni successive hanno anche una regola dei criteri per applicare le impostazioni securityContext e rifiutare i pod che utilizzano sysctl non sicuri.
Tipi di volume Autopilot consente solo i tipi di volume nel criterio Con restrizioni con le seguenti aggiunte: volumi HostPath con accesso di 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 protegge solo i container che non vengono eseguiti come root. I sondaggi di settore mostrano che il 76% dei container viene eseguito come root, quindi Autopilot consente l'esecuzione come root per abilitare la maggior parte dei carichi di lavoro. Questa impostazione è attualmente utile anche per de-privilegizzare i carichi di lavoro verso i file non root, consentendo l'uso delle funzionalità del file system per aggirare le deficienze con la gestione delle capacità radice di Kubernetes.
Esegui come non root I sondaggi di settore mostrano che il 76% dei container viene eseguito come root, quindi 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 di settore mostrano che il 76% dei container viene eseguito come root, quindi 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 in base alle best practice del settore e alla nostra esperienza. La tabella seguente descrive alcune delle configurazioni di sicurezza che Autopilot applica per te:

Configurazione Descrizione
Opzioni host
Funzionalità Linux

Puoi utilizzare le seguenti funzionalità 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 SecurityContext al pod.
  • SYS_PTRACE per il debug: aggiungi SecurityContext al pod.
  • 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 GKE precedenti alla 1.21, la funzionalità "SYS_PTRACE" non è supportata.
Container con privilegi I container non possono essere eseguiti in modalità con privilegi, a meno che il deployment del container non venga eseguito da un Partner Google Cloud. I container con privilegi possono apportare modifiche al nodo sottostante, ad esempio modificando il kubelet. Questo accesso potrebbe aumentare l'impatto della compromissione di un pod.
Spazi dei nomi gestiti da GKE Come misura di sicurezza, Autopilot non consente il deployment di carichi di lavoro negli spazi dei nomi gestiti da GKE, come kube-system.
Isolamento del container

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

Funzionalità Linux e sicurezza del kernel

  • Autopilot applica il profilo seccomp RuntimeDefault a tutti i pod nel cluster, a meno che i pod non utilizzino GKE Sandbox. GKE Sandbox applica l'isolamento dell'host e ignora le regole di seccomp specificate nel manifest del pod. La sandbox è considerata il confine di sicurezza per i pod di GKE Sandbox.
  • Autopilot elimina la funzionalità Linux CAP_NET_RAW per tutti i container. Questa autorizzazione non viene utilizzata di frequente ed è stata oggetto di diverse vulnerabilità di escape. Il comando ping potrebbe non riuscire all'interno dei tuoi container perché questa funzionalità viene ignorata. Puoi riabilitare manualmente questa funzionalità impostandola nel SecurityContext del pod.
  • Autopilot elimina la funzionalità Linux CAP_NET_ADMIN per tutti i container. Per abilitare nuovamente questa funzionalità, specifica il flag --workload-policies=allow-net-admin nel comando di creazione o aggiornamento del cluster. NET_ADMIN è richiesto da alcuni carichi di lavoro come Istio.
  • Autopilot abilita la Federazione delle identità per i carichi di lavoro per GKE, impedendo l'accesso ai pod ai metadati sensibili sul nodo.
  • Autopilot blocca i servizi Kubernetes che impostano il campo spec.externalIPs da proteggere 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 di nodo. I volumi HostPath sono bloccati per impostazione predefinita, ma i container possono richiedere l'accesso di sola lettura ai percorsi /var/log per il debug.
Applicazione dei criteri di sicurezza a livello di pod Autopilot supporta meccanismi di applicazione per i criteri di sicurezza a livello di pod come il controller di ammissione PodSecurity, il Gatekeeper o il Controller dei criteri. Tuttavia, potresti non doverlo utilizzare se le configurazioni di sicurezza integrate descritte in questa pagina soddisfano già i tuoi requisiti.
SSH ai nodi

Autopilot blocca l'accesso SSH ai nodi. GKE gestisce tutti gli aspetti operativi dei nodi, tra cui l'integrità dei nodi 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 a fini di debug, inclusa la connessione a una shell interattiva, ad esempio con kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh.
Furto d'identità di un utente GKE 1.22.4-gke.1501 e versioni successive supportano la rappresentazione degli utenti per tutti gli utenti e i gruppi definiti dall'utente. Non è possibile impersonare 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 mutanti per escludere le risorse negli spazi dei nomi gestiti, come kube-system, dall'intercettazione.

Autopilot rifiuta anche i webhook che specificano una o più delle seguenti risorse e le eventuali sottorisorse 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 fare in modo che risorse o gruppi ignorino questa limitazione.
ValidatingAdmissionPolicies

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

Autopilot rifiuta anche gli oggetti ValidatingAdmissionPolicy che specificano una o più delle seguenti risorse e le eventuali sottorisorse 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 fare in modo che risorse o gruppi ignorino questa limitazione.
Richieste di firma del certificato Puoi creare CertificateSigningRequests in Autopilot per creare certificati firmati dall'autorità di certificazione del cluster. Per evitare interferenze con i componenti del sistema, Autopilot rifiuta le richieste CertificateSigningRequest per le identità con privilegi noti, come gruppi di sistema, agenti di sistema o agenti di servizio IAM gestiti da Google.
Funzionalità di sicurezza di GKE I cluster Autopilot abilitano per te le funzionalità di sicurezza GKE consigliate. Per un elenco delle funzionalità di sicurezza abilitate e facoltative, consulta la pagina relativa alle funzionalità di sicurezza in Autopilot.
Sistema operativo nodo I cluster Autopilot utilizzano Container-Optimized OS con containerd come sistema operativo dei nodi. 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 nel tempo l'upgrade del piano di controllo e dei nodi alla versione qualificata più recente nel canale di rilascio.

Confini di sicurezza in Autopilot

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

Il nostro scopo è impedire l'accesso involontario alla VM nodo. Accettiamo i contenuti inviati in tal senso tramite il Google Vulnerability Reward Program (VRP) e premiamo i report a discrezione dell'apposito riquadro di Google VRP.

Per impostazione predefinita, gli utenti con privilegi, come gli amministratori di cluster, hanno il controllo completo di qualsiasi cluster GKE. Come best practice per la sicurezza, ti consigliamo di evitare di concedere su larga scala privilegi potenti per GKE o Kubernetes e, se possibile, di utilizzare la delega dell'amministratore dello spazio dei nomi, come descritto nelle nostre linee guida sull'architettura multi-tenancy.

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 possono essere eseguiti contemporaneamente, Poiché il kernel condiviso rappresenta un singolo confine di sicurezza, ti consigliamo di eseguire i carichi di lavoro sui pod GKE Sandbox se hai bisogno di un forte isolamento, ad esempio ad esempio carichi di lavoro ad alto rischio o non attendibili.

Risorse per la sicurezza basate sul caso d'uso

Le sezioni seguenti forniscono link e suggerimenti 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
Comprendere in che modo GKE come piattaforma affronta la sicurezza
Comprendi il tuo ruolo nella protezione dell'ambiente Scopri di più sul modello di responsabilità condivisa.
Visualizza le raccomandazioni di Google per le misure di protezione avanzata e la risposta agli incidenti
Scopri come GKE implementa l'audit logging

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 sul server API del cluster
Autentica le applicazioni nelle API e nei servizi Google Cloud I cluster Autopilot consentono di utilizzare la federazione delle identità per i carichi di lavoro per GKE al fine di autenticare in modo sicuro i carichi di lavoro nelle 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 la federazione delle identità per i carichi di lavoro per GKE.
Autorizza 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 specifiche risorse GKE e API Kubernetes utilizzando ruoli e autorizzazioni IAM. Per le istruzioni, consulta Creare criteri IAM.
Autorizza azioni a livello di cluster Per autorizzare le azioni sulle risorse dell'API Kubernetes in cluster specifici, utilizza il meccanismo integrato di controllo degli accessi basato su ruoli (RBAC, Role-Based Access Control) di Kubernetes. Per le istruzioni, consulta Autorizzare le azioni nei cluster utilizzando RBAC.
Autorizza azioni a livello di organizzazione Puoi utilizzare il servizio Criteri dell'organizzazione di Google Cloud per applicare vincoli su operazioni specifiche sulle risorse GKE in tutta l'organizzazione Google Cloud. Per le istruzioni, consulta Limitare le azioni sulle risorse GKE utilizzando i criteri dell'organizzazione personalizzati.

Proteggi i cluster e i carichi di lavoro

Se hai requisiti di isolamento o protezione specifici oltre le misure Autopilot preconfigurate, considera le seguenti risorse:

Caso d'uso Risorse
Limita l'accesso pubblico all'endpoint del cluster Crea i tuoi cluster Autopilot come cluster privati, in modo da disabilitare l'indirizzo IP pubblico del piano di controllo del cluster. Per le istruzioni, consulta Cluster privati.
Limita l'accesso ai cluster a reti specifiche Utilizza le reti autorizzate del piano di controllo per specificare gli intervalli di indirizzi IP che possono accedere al cluster.
Archivia le informazioni sensibili all'esterno del cluster L'archiviazione di dati sensibili in un provider di archiviazione esterno criptato con il controllo delle versioni abilitato è un requisito di conformità comune e una best practice. Utilizza Secret Manager per archiviare i tuoi dati e accedervi dai cluster Autopilot utilizzando la federazione delle identità per i carichi di lavoro per GKE. Per istruzioni, consulta Accedere ai secret archiviati all'esterno 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 controllare l'integrità delle immagini container a cui viene fatto riferimento nei manifest dei pod al momento del deployment. Per istruzioni, consulta Verificare le immagini container in fase di deployment utilizzando Autorizzazione binaria.

Monitora la tua security posture

Dopo aver impostato i cluster ed eseguito il deployment dei carichi di lavoro, devi impostare e configurare il monitoraggio e il logging in modo da poter osservare la strategia di sicurezza del cluster. Ti consigliamo di eseguire tutte le seguenti operazioni:

  • Registra i tuoi cluster nella dashboard della postura di sicurezza di GKE per verificare la presenza di problemi dei carichi di lavoro in eventuali problemi quali configurazioni di sicurezza problematiche o vulnerabilità nei pacchetti del sistema operativo dei container e ottieni informazioni strategiche sulla mitigazione.
  • Ricevi notifiche sui nuovi bollettini sulla sicurezza ed eventi di upgrade utilizzando le notifiche dei cluster.
  • Osserva i tuoi cluster utilizzando la dashboard di GKE in Cloud Monitoring o la scheda Osservabilità in GKE.
  • Scopri come visualizzare e gestire gli audit log di GKE in Cloud Logging.

Passaggi successivi