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.
Dovresti leggere anche Panoramica sulla sicurezza di GKE, che descrive le opzioni, le misure e i consigli di protezione avanzata che si applicano per tutti i cluster GKE, le configurazioni di rete e i carichi di lavoro.
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 ha una serie di linee guida per la sicurezza chiamate 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.
- Con accesso limitato: il livello di sicurezza più elevato. Richiede modifiche significative a per la 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 carichi di lavoro.
Se devi applicare ulteriori limitazioni per rispettare i la versione completa delle norme sulle restrizioni, puoi utilizzare facoltativamente Controller di ammissione PodSecurity in spazi dei nomi specifici.
La tabella seguente descrive il confronto tra i controlli nel criterio GKE Warden predefinito di 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 il modo in cui 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 container di partner verificati possono usare 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à 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à:
Autopilot consente anche ad alcuni carichi di lavoro e configurare le funzionalità eliminate. |
||
| Volumi HostPath | Parzialmente conforme | Parzialmente conforme | Autopilot consente ai container di richiedere l'accesso in sola lettura
/var/log per il debug, ma nega tutte le altre operazioni di lettura o scrittura
l'accesso. |
| 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 assegnazione casuale di porte host in un intervallo noto per il supporto di applicazioni di rete a connessione diretta come i server di gioco. | ||
| AppArmor | Il profilo di sicurezza predefinito per la base di AppArmor è applicata automaticamente a Container-Optimized OS. | ||
| SELinux | SELinux non viene applicato perché AppArmor è già applicato. SELinux è non è inoltre obbligatorio negli standard di sicurezza dei pod. | ||
/proc tipo di montaggio |
GKE non imposta il flag di funzionalità ProcMountType.
Se securityContext del pod imposta procMount
su "Unmasked", GKE lo esegue automaticamente con
"Predefinito". |
||
| profilo seccomp | Autopilot applica la seccomp di RuntimeDefault
del profilo a tutti i carichi di lavoro. Puoi eseguire manualmente l'override di questa impostazione
carichi di lavoro specifici impostando il profilo su Unconfined
la specifica del pod. |
||
| sysctl | GKE non imposta il flag kubelet --allowed-unsafe-sysctls, quindi i pod con sysctl non sicuri non vengono pianificati. Per maggiore protezione, a partire dall'11 luglio 2023, le nuove versioni 1.27 e successive i cluster hanno anche una regola dei criteri per applicare le impostazioni securityContext e rifiutare i pod che usano sysctl non sicuri. | ||
| Tipi di volume | Autopilot consente solo i tipi di volume nel criterio Restricted con le seguenti aggiunte: volumi HostPath con accesso di sola lettura a
/var/log per il debug, gcePersistentDisk per Compute Engine
dischi permanenti e nfs per i volumi del file system di rete. |
||
| Escalation dei privilegi | Questa impostazione protegge solo i container che non sono eseguito come root. Le indagini di settore mostrano che il 76% dei container è 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 | Sondaggi di settore mostrano che il 76% dei container viene eseguito come root, 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 in base alle best practice del settore e alla nostra esperienza. La tabella seguente descrive alcune configurazioni di sicurezza applicate da Autopilot per te:
| Configurazione | Descrizione |
|---|---|
| Opzioni di hosting |
|
| Funzionalità di 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à:
Nelle versioni di GKE precedenti alla 1.21, la funzionalità |
| 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 fuga dal contenitore. Funzionalità Linux e sicurezza del kernel
|
| Applicazione dei criteri di sicurezza a livello di pod | Autopilot supporta i meccanismi di applicazione a livello di pod
criteri di sicurezza come
PodSecurity titolare di ammissione,
Gatekeeper,
o Policy Controller.
Tuttavia, potresti non dover utilizzare nessuna di queste funzionalità se la sicurezza integrata
le configurazioni descritte in questa pagina soddisfano già i requisiti. |
| SSH ai nodi | Autopilot blocca l'accesso SSH ai nodi. GKE gestisce tutti gli aspetti operativi dei nodi, tra cui l'integrità e tutti i componenti di Kubernetes in esecuzione sui nodi. Puoi comunque connetterti da remoto ai container in esecuzione utilizzando Kubernetes
|
| Furto d'identità di un utente | GKE versione 1.22.4-gke.1501 e successive supportano
l'usurpazione di identità dell'utente per tutti gli utenti e i gruppi definiti dall'utente. Utenti del sistema e
gruppi come l'utente kube-apiserver e
Impossibile impersonare gruppo system:masters. |
| mutazione dei webhook di ammissione dinamici | Autopilot modifica i webhook mutanti per escludere le risorse in
gestiti da Google, come 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 |
| ValidatingAdmissionPolicies | Autopilot modifica Autopilot rifiuta anche gli oggetti - 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 CertificateSigningRequests in Autopilot per creare certificati firmati dall'autorità di certificazione del cluster. Per evitare interferenze con i componenti di 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 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 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 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 l'uso di 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 limitare un accesso di basso livello alla VM nodo, per cui Google Cloud può offrire la gestione completa dei nodi e un servizio a livello di pod SLA.
Il nostro scopo è impedire l'accesso involontario alla VM 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 insieme, condividendo un kernel protetto dalla 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 per la sicurezza basate sul caso d'uso
Le sezioni seguenti forniscono link e consigli per pianificare, implementare e gestire la sicurezza dei cluster Autopilot in base in base al tuo 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 |
|
| Scopri come GKE implementa l'audit logging |
|
Autenticare e autorizzare
Dopo aver configurato i cluster Autopilot, potresti dover di autenticare gli utenti e le applicazioni per utilizzare risorse come o le API di 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 per autenticare in modo sicuro i tuoi carichi di lavoro nelle API Google Cloud Configurazione di account di servizio Kubernetes in modo che agiscano come servizio IAM. . Per istruzioni, consulta Configura le applicazioni per utilizzare la federazione delle identità per i carichi di lavoro 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 azioni sulle risorse API Kubernetes in cluster specifici, usano il meccanismo integrato di controllo dell'accesso basato su ruoli (RBAC, Role-Based Access Control) di Kubernetes. Per istruzioni, consulta Autorizzare le azioni nei cluster utilizzando RBAC. |
| Autorizza 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. |
Proteggi i cluster e i 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 |
|---|---|
| Limita l'accesso pubblico all'endpoint del cluster | Crea i cluster Autopilot come cluster privati, che disattivano l'indirizzo IP pubblico del piano di controllo del cluster. Per istruzioni, fai riferimento a Cluster privati. |
| Limita l'accesso ai cluster a reti specifiche | Utilizza le reti autorizzate del control plane per specificare gli intervalli di indirizzi IP che possono accedere al tuo cluster. |
| Archivia le 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 tuoi dati e accedervi dal i 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 eseguire tutte le seguenti operazioni:
- Registra i tuoi cluster nella dashboard della strategia di sicurezza di GKE per eseguire il controllo dei carichi di lavoro per rilevare 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
- Leggi la panoramica sulla sicurezza di GKE.
- Leggi la guida alla protezione avanzata di GKE.
- Iscriviti ai bollettini sulla sicurezza e alle note di rilascio.