Questa pagina descrive le funzionalità, le configurazioni e le impostazioni di sicurezza di Autopilot di Google Kubernetes Engine (GKE), che è 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 in modo specifico da Google ai cluster Autopilot e le funzionalità di sicurezza disponibili per l'uso in Autopilot.
Ti consigliamo di leggere anche la panoramica sulla sicurezza di GKE, in cui sono descritte le opzioni, le misure e i suggerimenti di protezione avanzata che si applicano a tutti i cluster GKE, a tutte le configurazioni di rete e a tutti 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 Proteggi la sicurezza del cluster.
Se vuoi trovare risorse consigliate in base al tuo caso d'uso, vai a Risorse di sicurezza per caso d'uso. Le seguenti sezioni descrivono i criteri di sicurezza che Autopilot si applica al tuo caso.
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: previene i percorsi noti di escalation dei privilegi. Consente l'esecuzione della maggior parte dei carichi di lavoro senza modifiche significative.
- Limitata: livello di sicurezza massimo. 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 il criterio completo con restrizioni, puoi facoltativamente utilizzare il controller di ammissione PodSecurity in spazi dei nomi specifici.
La tabella seguente descrive in che modo i cluster Autopilot implementano i criteri di riferimento e limitati. Per le descrizioni di ciascun controllo in questa tabella, consulta la voce corrispondente in Standard di sicurezza dei pod.
Durante la valutazione della conformità, abbiamo considerato come i vincoli si applicano ai tuoi carichi di lavoro. Sono esclusi i carichi di lavoro verificati dei partner Google Cloud e i carichi di lavoro di sistema che richiedono privilegi specifici per il funzionamento.
Controlli | 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 host. Alcuni container di partner verificati possono 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 come l'esecuzione di strumenti di sicurezza e monitoraggio. | ||
Funzionalità di Linux | I carichi di lavoro Autopilot possono accedere solo alle funzionalità specificate in Baseline Pod Security Standard per impostazione predefinita. Puoi attivare manualmente le seguenti funzionalità:
Autopilot consente inoltre 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 qualsiasi altro accesso 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 ai servizi di rete. Puoi configurare manualmente l'assegnazione casuale di porte host da un intervallo noto per supportare applicazioni di networking a connessione diretta come i server di gioco. | ||
AppArmor | Il profilo di sicurezza predefinito Docker di AppArmor viene applicato automaticamente a Container-Optimized OS. | ||
SELinux | SELinux non viene applicato perché è già applicato AppArmor. Inoltre, 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 "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 --allowed-unsafe-sysctls kubelet, pertanto i pod con sistemi di sistema non sicuri non possono essere pianificati. Per una maggiore protezione, a partire dall'11 luglio 2023, i nuovi cluster con oltre 1,27 anni hanno anche una regola del criterio per applicare le impostazioni securityContext e rifiutare i pod che utilizzano sistemi 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 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 che non sono in esecuzione come root. Sondaggi di settore mostrano che il 76% dei container viene eseguito come root, per cui Autopilot consente l'esecuzione come root per abilitare la maggior parte dei carichi di lavoro. Questa impostazione al momento è utile anche per rimuovere il privilegio dai carichi di lavoro a quelli non root, consentendo l'uso di funzionalità di file system per aggirare le carenze nella gestione delle funzionalità root di Kubernetes. | ||
Esegui come non root | I sondaggi di settore mostrano che il 76% dei container viene eseguito come root, per cui 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, per cui Autopilot consente l'esecuzione come root per abilitare la maggior parte dei carichi di lavoro |
Configurazioni di sicurezza integrate
Google applica ai cluster Autopilot molte impostazioni di sicurezza integrate in base alle best practice del settore e alla nostra esperienza. La tabella seguente descrive alcune delle configurazioni di sicurezza applicate da Autopilot per te:
Configurazione | Descrizione |
---|---|
Opzioni host |
|
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à:
Nelle versioni di GKE precedenti alla 1.21, la funzionalità |
Container con privilegi | I container non possono essere eseguiti in modalità con privilegi, a meno che il deployment del container non sia stato eseguito da un partner Google Cloud. I container con privilegi possono apportare modifiche al nodo sottostante, ad esempio modificare 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 dei carichi di lavoro in 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à dei container escape. Funzionalità Linux e sicurezza del kernel
|
Applicazione dei criteri di sicurezza a livello di pod | La modalità Autopilot supporta i meccanismi di applicazione per i criteri di sicurezza a livello di pod come PodSecurity controller di ammissione, Gatekeeper o Policy Controller.
Tuttavia, potrebbe non essere necessario utilizzare queste opzioni 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 tuoi container in esecuzione utilizzando la funzionalità |
Impersonificazione di un utente | GKE versione 1.22.4-gke.1501 e successive supporta
il furto dell'identità degli utenti per tutti gli utenti e i gruppi definiti dall'utente. Non è possibile impersonare utenti di sistema e gruppi come l'utente kube-apiserver e il gruppo system:masters . |
Modifica dei webhook di ammissione dinamici | Autopilot modifica i webhook mutanti per escludere le risorse negli spazi dei nomi gestiti, come 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 |
Richieste di firma del certificato | Puoi creare CertificateSigningRequest in Autopilot per creare certificati firmati dall'autorità di certificazione del cluster. Per evitare interferenze con i componenti del sistema, Autopilot rifiuta CertificateSigningRequests per identità con privilegi 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 di GKE consigliate per te. Per un elenco delle funzionalità di sicurezza abilitate e facoltative, consulta la pagina relativa alle funzionalità di sicurezza in Autopilot. |
Sistema operativo del nodo | I cluster Autopilot utilizzano Container-Optimized OS con
containerd come sistema operativo dei nodi. Container-Optimized OS
è creato e gestito da Google. |
Upgrade della versione 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 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 consente di accedere all'API Kubernetes, ma rimuove le autorizzazioni per usare alcune funzionalità Kubernetes con privilegi elevati. L'obiettivo è limitare la possibilità di accedere, modificare o controllare direttamente la macchina virtuale (VM) del nodo. Autopilot implementa queste restrizioni per limitare i carichi di lavoro derivanti dall'accesso di basso livello alla VM del nodo, in modo che Google Cloud possa offrire una gestione completa dei nodi e uno SLA a livello di pod.
Il nostro scopo è impedire l'accesso involontario alla VM del nodo. Accettiamo i contenuti inviati a tal fine tramite il Vulnerability Reward Program (VRP) di Google e premiamo i report a discrezione della giuria 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 ampiamente privilegi GKE o Kubernetes efficaci e di utilizzare invece la delega dell'amministratore dello spazio dei nomi ove possibile come descritto nelle nostre indicazioni sull'architettura multi-tenancy.
Autopilot esegue il provisioning di VM single-tenant nel tuo progetto per un uso esclusivo. Su ogni singola VM, i carichi di lavoro Autopilot potrebbero essere eseguiti insieme, condividendo un kernel con sicurezza protetta. Poiché il kernel condiviso rappresenta un unico confine di sicurezza, se hai bisogno di un forte isolamento, come carichi di lavoro ad alto rischio o non attendibili, esegui i carichi di lavoro sui pod di GKE Sandbox per fornire una protezione della sicurezza multilivello.
Risorse per la sicurezza in base al caso d'uso
Le sezioni seguenti forniscono link e suggerimenti per pianificare, implementare e gestire la sicurezza dei tuoi cluster Autopilot in base al caso d'uso.
Pianifica la sicurezza del cluster
Caso d'uso | Risorse |
---|---|
Comprendere l'approccio di GKE come piattaforma alla sicurezza |
|
Comprendi il tuo ruolo nella protezione dell’ambiente | Scopri di più sul modello di responsabilità condivisa. |
Vedi i consigli di Google su misure di protezione avanzata e risposta agli incidenti |
|
Comprendere 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 di Workload Identity per GKE per autenticare in modo sicuro i tuoi 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 l'utilizzo della federazione di Workload Identity per 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 specifiche risorse dell'API GKE e Kubernetes utilizzando ruoli e autorizzazioni IAM. Per le istruzioni, consulta Creare criteri IAM. |
Autorizza 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 sui ruoli (RBAC) integrato di Kubernetes. Per le istruzioni, consulta Autorizzare le azioni nei cluster utilizzando RBAC. |
Autorizza le azioni a livello di organizzazione | Puoi utilizzare il servizio criteri dell'organizzazione di Google Cloud 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. |
Proteggi cluster e carichi di lavoro
Se hai requisiti di isolamento o protezione specializzati oltre alle misure Autopilot preconfigurate, valuta 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. |
Limitare 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 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 tuoi cluster Autopilot utilizzando la federazione di Workload Identity per GKE. Per le istruzioni, consulta Accedere ai secret archiviati all'esterno dei cluster GKE utilizzando la federazione di Workload Identity 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 le istruzioni, consulta Verificare le immagini container al momento del deployment utilizzando Autorizzazione binaria. |
Monitora la tua strategia di sicurezza
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 avere l'osservabilità della strategia di sicurezza del cluster. Ti consigliamo di eseguire tutte le seguenti operazioni:
- Registra i tuoi cluster nella dashboard della strategia di sicurezza di GKE per controllare i carichi di lavoro alla ricerca di problemi quali configurazioni di sicurezza problematiche o vulnerabilità nei pacchetti dei sistemi operativi dei container e ottieni informazioni di mitigazione pratiche.
- Ricevi notifiche sui nuovi bollettini sulla sicurezza ed eventi di upgrade utilizzando le notifiche del cluster.
- Osserva i 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
- Leggi la panoramica sulla sicurezza di GKE.
- Leggi la guida di protezione avanzata di GKE.
- Iscriviti ai bollettini sulla sicurezza e alle note di rilascio.