Misure di sicurezza di GKE Autopilot

Questa pagina descrive le funzionalità, le configurazioni e le impostazioni di sicurezza in Google Kubernetes Engine (GKE) Autopilot. I cluster GKE Autopilot implementano molte configurazioni di sicurezza per te, il che rende Autopilot il modo consigliato per eseguire GKE.

Questa pagina è destinata agli esperti di sicurezza che vogliono comprendere le limitazioni di sicurezza che Google applica specificamente ai cluster Autopilot e le funzionalità di sicurezza disponibili per l'uso in Autopilot. 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.

Prima di leggere questa pagina, assicurati di avere familiarità con quanto segue:

Misure di sicurezza in Autopilot

I cluster Autopilot attivano e applicano per impostazione predefinita le best practice e le impostazioni di sicurezza, tra cui molti dei suggerimenti riportati nella panoramica della sicurezza e in Rafforzare la sicurezza del cluster.

Se vuoi risorse consigliate in base al tuo caso d'uso, vai a Risorse per la sicurezza per caso d'uso. Le sezioni seguenti descrivono le norme di sicurezza che Autopilot applica per te.

Applicazione degli standard di sicurezza dei pod di Kubernetes

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

  • Privilegiato: nessuna limitazione di accesso. Non utilizzato in Autopilot.
  • Baseline: 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 workload.

In modalità Autopilot, GKE applica i vincoli di sicurezza dei pod utilizzando i controller di ammissione. 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, la policy di ammissione predefinita per Autopilot applica molti vincoli del livello Restricted degli standard di sicurezza dei pod, ma evita le limitazioni che impedirebbero l'esecuzione della maggior parte dei tuoi workload.

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

La seguente tabella descrive il confronto tra i controlli nella policy di controllo degli accessi Autopilot predefinita e i controlli nei livelli Baseline e Restricted degli standard di sicurezza dei pod. Per le descrizioni di ogni controllo in questa tabella, consulta la voce corrispondente in Standard di sicurezza dei pod.

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

Controllo Conformità alle norme di base Conformità alle norme con limitazioni Informazioni aggiuntive
HostProcess Autopilot blocca HostProcess.
Spazi dei nomi host Autopilot blocca gli spazi dei nomi host. Alcuni container di partner verificati possono utilizzare gli spazi dei nomi host.
Container con privilegi Per impostazione predefinita, Autopilot blocca i container con privilegi. Autopilot consente container privilegiati 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 base.

Puoi attivare manualmente le seguenti funzionalità:

  • NET_RAW per ping e SYS_PTRACE per il debug: Aggiungi a Pod SecurityContext
  • NET_ADMIN per i service mesh come Istio: specifica --workload-policies=allow-net-admin nel comando di creazione del cluster. Disponibile sui cluster esistenti nuovi e aggiornati che eseguono GKE versione 1.27 e successive.

Autopilot consente inoltre ad alcuni carichi di lavoro dei partner verificati di impostare funzionalità eliminate.
Volumi HostPath Conforme parzialmente Conforme parzialmente Autopilot consente ai container di richiedere l'accesso di sola lettura a /var/log per il debug, ma nega tutti gli altri accessi 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 e accidentale o intenzionale dei servizi alla rete. Puoi configurare manualmente l'assegnazione casuale della porta host da un intervallo noto per supportare applicazioni di rete a connessione diretta come i server di gioco.
AppArmor Il profilo di sicurezza docker-default di AppArmor viene applicato automaticamente a Container-Optimized OS.
SELinux SELinux non viene applicato perché AppArmor è già applicato. SELinux non è obbligatorio nemmeno 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 RuntimeDefault seccomp a tutti i workload. Puoi eseguire l'override manuale di questa impostazione per carichi di lavoro specifici impostando il profilo su Unconfined nella specifica del pod.
sysctls GKE non imposta il flag kubelet --allowed-unsafe-sysctls, quindi la pianificazione dei pod con sysctl non sicuri non va a buon fine. Per una maggiore protezione, a partire dall'11 luglio 2023, i nuovi cluster 1.27+ 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 volumi nella policy con limitazioni 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 protegge solo i container che non vengono eseguiti come utente root. I sondaggi del 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 ridurre i privilegi dei carichi di lavoro a non root consentendo l'utilizzo delle funzionalità del file system per aggirare le carenze nella gestione delle funzionalità root di Kubernetes.
Esegui come non root I sondaggi del 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 per l'organizzatore
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 il ping: aggiungi al pod SecurityContext.
  • SYS_PTRACE per il debug: aggiungi al pod SecurityContext.
  • NET_ADMIN per i service mesh 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 implementati da un Google Cloud partner. I container privilegiati possono apportare modifiche al nodo sottostante, ad esempio modificare il kubelet. Questo accesso potrebbe aumentare l'impatto di una compromissione del pod.
Spazi dei nomi gestiti da GKE Come misura di sicurezza, Autopilot non consente 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à Linux e sicurezza del kernel

  • Autopilot applica il RuntimeDefault profilo seccomp 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 seccomp specificate nel manifest del pod. La sandbox è considerata il confine di sicurezza per i pod GKE Sandbox.
  • Autopilot elimina la funzionalità CAP_NET_RAW Linux per tutti i container. Questa autorizzazione non viene utilizzata spesso e è stata oggetto di più vulnerabilità di escape. Il comando ping potrebbe non riuscire all'interno dei container perché questa funzionalità viene eliminata. Puoi riattivare manualmente questa funzionalità impostandola in Pod SecurityContext.
  • Autopilot elimina la funzionalità CAP_NET_ADMIN Linux per tutti i container. Per riattivare questa funzionalità, specifica il flag --workload-policies=allow-net-admin nel comando di creazione o aggiornamento del cluster. NET_ADMIN è richiesto da alcuni workload come Istio.
  • Autopilot abilita Workload Identity Federation for GKE, che impedisce l'accesso dei pod ai metadati sensibili sul nodo.
  • Autopilot blocca i servizi Kubernetes che impostano il campo spec.externalIPs per 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 in sola lettura ai percorsi /var/log per il debug.
Applicazione dei criteri di sicurezza a livello di pod Autopilot supporta meccanismi di applicazione per criteri di sicurezza a livello di pod, come il controller di ammissione PodSecurity, Gatekeeper o Policy Controller. Tuttavia, potresti non doverne utilizzare nessuno se le configurazioni di sicurezza integrate descritte in questa pagina soddisfano già i tuoi requisiti.
Accesso SSH ai nodi

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

Puoi comunque connetterti in remoto ai container in esecuzione utilizzando la funzionalità exec di Kubernetes per eseguire comandi nei container per il debug, 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 1.22.4-gke.1501 e versioni successive supportano l'impersonificazione dell'utente per tutti gli utenti e i gruppi definiti dall'utente. Non è possibile eseguire l'impersonificazione di utenti e gruppi di sistema, ad esempio l'utente kube-apiserver e il gruppo system:masters.
Modifica dei webhook di ammissione dinamici

Autopilot modifica i webhook di mutazione per escludere le risorse negli spazi dei nomi gestiti, ad esempio kube-system, dall'essere intercettate.

Autopilot rifiuta anche i webhook che specificano una o più delle seguenti risorse e qualsiasi risorsa secondaria 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 risorse o gruppi per aggirare questa limitazione.
ValidatingAdmissionPolicies

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

Autopilot rifiuta anche gli oggetti ValidatingAdmissionPolicy che specificano una o più delle seguenti risorse e qualsiasi risorsa secondaria 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 risorse o gruppi per aggirare 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 di sistema, Autopilot rifiuta le richieste di firma dei certificati 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 abilitano le funzionalità di sicurezza GKE consigliate per te. Per un elenco delle funzionalità di sicurezza abilitate e facoltative, consulta 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 è creato e gestito da Google.
Upgrade delle versioni di 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 control plane e dei nodi alla versione qualificata più recente nel canale di rilascio nel tempo.

Limiti di sicurezza in Autopilot

Autopilot fornisce l'accesso all'API Kubernetes, ma rimuove le autorizzazioni per utilizzare alcune funzionalità di Kubernetes con privilegi elevati, 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 carichi di lavoro di avere accesso di basso livello alla VM nodo, in modo cheGoogle Cloud possa offrire la gestione completa dei nodi e un SLA a livello di pod.

Il nostro scopo è impedire l'accesso non intenzionale alla VM del nodo. Accettiamo le segnalazioni a questo proposito tramite il programma a premi per il rilevamento delle vulnerabilità (VRP) di Google e premieremo le segnalazioni a discrezione del panel di premi del VRP di Google.

Per progettazione, gli utenti con privilegi come gli amministratori del cluster hanno il controllo completo di qualsiasi cluster GKE. Come best practice di sicurezza, ti consigliamo di evitare di concedere privilegi GKE o Kubernetes potenti in modo ampio e di utilizzare invece la delega dell'amministratore dello spazio dei nomi, ove possibile, come descritto nelle nostre indicazioni sul multi-tenancy.

Autopilot esegue il provisioning di VM single-tenant nel tuo progetto per il tuo uso esclusivo. Su ogni singola VM, i tuoi carichi di lavoro Autopilot potrebbero essere eseguiti insieme, condividendo un kernel con sicurezza avanzata. Poiché il kernel condiviso rappresenta un singolo perimetro di sicurezza, se hai bisogno di un isolamento efficace, ad esempio per carichi di lavoro ad alto rischio o non attendibili, ti consigliamo di eseguire i carichi di lavoro sui pod GKE Sandbox per fornire una protezione di sicurezza multilivello.

Suggerimenti per la sicurezza in base al caso d'uso

Le sezioni seguenti forniscono link e consigli per pianificare, implementare e gestire la sicurezza dei cluster Autopilot a seconda del caso d'uso.

Pianificare la sicurezza del cluster

Caso d'uso Risorse
Scopri come GKE come piattaforma si avvicina alla sicurezza
Comprendere il tuo ruolo nel rafforzamento della sicurezza del tuo ambiente Scopri di più sul modello di responsabilità condivisa.
Visualizza i consigli di Google per le misure di hardening e la risposta agli incidenti
Informazioni su come GKE implementa il logging di controllo

Autenticare e autorizzare

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

Caso d'uso Risorse
Autenticare utenti o applicazioni nel server API del cluster
Autenticare le applicazioni per Google Cloud API e servizi I cluster Autopilot ti consentono di utilizzare la federazione delle identità dei carichi di lavoro per GKE per autenticare in modo sicuro i tuoi carichi di lavoro alle API Google Cloud configurando i service account Kubernetes in modo che fungano da service account IAM. Per istruzioni, consulta Configurare le applicazioni per utilizzare Workload Identity Federation for GKE.
Autorizza 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 ruoli e autorizzazioni IAM. Per le istruzioni, consulta Creare policy IAM.
Autorizza le azioni a livello di cluster Per autorizzare le azioni sulle risorse API Kubernetes in cluster specifici, utilizza il meccanismo dicontrollo dell'accessoo basato sui ruoli (RBAC) di Kubernetes integrato. Per istruzioni, consulta Autorizzare le azioni nei cluster utilizzando RBAC.
Autorizzare le azioni a livello di organizzazione Puoi utilizzare Google Cloud Organization Policy Service per applicare vincoli a operazioni specifiche sulle risorse GKE nella tua Google Cloud organizzazione. Per istruzioni, consulta l'articolo Limitare le azioni sulle risorse GKE utilizzando policy dell'organizzazione personalizzate.

Rafforzare i cluster e i carichi di lavoro

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

Caso d'uso Risorse
Limitare l'accesso pubblico all'endpoint del cluster Configura l'isolamento di rete dei cluster Autopilot e disabilita l'endpoint esterno del control plane del cluster. Per istruzioni, consulta Configurare l'accesso al control plane.
Limitare l'accesso al cluster a reti specifiche Utilizza le reti autorizzate del control plane per specificare gli intervalli di indirizzi IP che possono accedere al tuo cluster.
Archiviare informazioni sensibili al di fuori del cluster L'archiviazione di dati sensibili in un provider di archiviazione esterno e criptato con il controllo delle versioni abilitato è un requisito di conformità comune e una best practice. Utilizza Secret Manager per archiviare i dati e accedervi dai cluster Autopilot utilizzando la federazione delle identità dei carichi di lavoro per GKE. Per istruzioni, consulta Accedere ai secret memorizzati al di fuori dei cluster GKE utilizzando la federazione delle identità dei carichi di lavoro per GKE.
Verifica le immagini container prima del deployment nel cluster Utilizza Autorizzazione binaria per verificare 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 al momento del deployment utilizzando Autorizzazione binaria.

Monitorare la tua postura di sicurezza

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

Passaggi successivi