Questa pagina descrive le funzionalità, le configurazioni e le impostazioni di sicurezza in modalità Autopilot di Google Kubernetes Engine (GKE). Queste informazioni sono rivolte agli esperti di sicurezza che vogliono comprendere i vincoli di sicurezza applicati da Google in modalità Autopilot e le funzionalità di sicurezza disponibili per l'utilizzo in Autopilot. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.
Prima di leggere questa pagina, acquisisci familiarità con i seguenti argomenti:
- Panoramica generale della sicurezza di GKE
- Panoramica generale della modalità Autopilot e della modalità Standard
Terminologia
In GKE, puoi utilizzare Autopilot creando un cluster Autopilot o eseguendo un workload in una ComputeClass Autopilot in qualsiasi cluster Standard. Questa pagina descrive le misure di sicurezza per Autopilot in entrambe le situazioni utilizzando la seguente terminologia:
- Cluster Autopilot
- L'intero cluster utilizza la modalità Autopilot.
- Workload Autopilot nei cluster Standard
- Il cluster utilizza la modalità Standard e tu esegui workload specifici in Autopilot utilizzando le classi di computing.
Misure di sicurezza in Autopilot
GKE applica varie best practice e impostazioni di sicurezza per impostazione predefinita in modalità Autopilot, tra cui molti dei suggerimenti riportati nella panoramica della sicurezza e in Rafforza la sicurezza del cluster.
Nei cluster Autopilot, GKE applica rigorosamente tutte le misure descritte in questa pagina per impostazione predefinita. Questa configurazione predefinita rende i cluster Autopilot il modo consigliato per utilizzare GKE. Per i workload Autopilot nei cluster Standard, GKE applica le misure di sicurezza descritte nelle sezioni seguenti al meglio delle sue possibilità.
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 le seguenti policy:
- Privilegiato: nessuna limitazione di accesso. Non utilizzato in Autopilot.
- Baseline: impedisce i percorsi di escalation dei privilegi noti. Consente l'esecuzione della maggior parte dei workload senza modifiche significative.
- 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 Kubernetes. La policy di ammissione dei pod Autopilot predefinita include tutti i suggerimenti del livello Baseline degli standard di sicurezza dei pod, con alcune modifiche per l'usabilità. Inoltre, la policy di ammissione predefinita include molti vincoli del livello Restricted degli standard di sicurezza dei pod, ma evita le limitazioni che impedirebbero l'esecuzione della maggior parte dei workload.
Per applicare ulteriori limitazioni in modo da rispettare la policy Restricted completa, puoi utilizzare facoltativamente il controller di ammissione PodSecurity in spazi dei nomi specifici.
La tabella seguente descrive il confronto tra i controlli della policy di ammissione Autopilot predefinita e i controlli dei livelli Baseline e Restricted degli standard di sicurezza dei pod. Per saperne di più su ogni controllo in questa tabella, consulta la voce corrispondente in Standard di sicurezza dei pod.
Durante la valutazione della conformità, abbiamo considerato l'applicazione dei vincoli ai tuoi workload. 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 limitate | 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 host. | ||
| Container con privilegi | Autopilot blocca i container con privilegi per impostazione predefinita. Autopilot consente l'utilizzo di container con privilegi di partner verificati per scopi quali l'esecuzione di strumenti di sicurezza e monitoraggio. | ||
| Funzionalità di Linux | I workload Autopilot possono accedere solo alle funzionalità specificate nello standard di sicurezza dei pod di base per impostazione predefinita. Puoi attivare manualmente le seguenti funzionalità:
Autopilot consente inoltre ad alcuni workload dei partner verificati di impostare le funzionalità rimosse. |
||
| Volumi HostPath | Conformità parziale | Conformità parziale | 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 | L'impostazione di porte host specifiche non è consentita, 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 host da un intervallo noto per supportare applicazioni di networking con 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. | ||
Tipo di montaggio /proc |
In GKE versione 1.33 e successive, se il securityContext del pod imposta procMount su Unmasked, Autopilot rifiuta il pod. Nelle versioni precedenti alla 1.33, Autopilot sovrascrive automaticamente il valore nel campo procMount in Default. |
||
| profilo seccomp | Autopilot applica il profilo seccomp RuntimeDefault a tutti i workload. Puoi eseguire l'override manuale di questa impostazione per workload specifici impostando il profilo su Unconfined nella specifica del pod. |
||
| sysctl | 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 protezione aggiuntiva, a partire dall'11 luglio 2023, i nuovi cluster 1.27+ hanno anche una regola della policy per applicare le impostazioni securityContext e rifiutare i pod che utilizzano sysctl non sicuri. | ||
| Tipi di volume | Autopilot consente solo i tipi di volume nella policy Restricted 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 Network File System. |
||
| Escalation dei privilegi | Questa impostazione fornisce protezione solo ai 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 workload. Questa impostazione è utile anche per rimuovere i privilegi dei workload per i 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 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 workload. | ||
| Esegui come utente non root | I container possono impostare runAsUser su 0.
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 workload |
Configurazioni di sicurezza integrate
Oltre agli standard di sicurezza dei pod, Google applica molte impostazioni di sicurezza in Autopilot in base alle best practice del settore e alla nostra esperienza. Queste configurazioni di sicurezza integrate vengono applicate rigorosamente nei cluster Autopilot.
Nei cluster Standard, GKE applica automaticamente molte di queste configurazioni best-effort ai workload Autopilot nel cluster. Se vuoi, puoi applicare tutte queste configurazioni nel tuo cluster Standard attivando ogni policy di Autopilot per quel cluster, il che forza tutti i workload nel cluster Standard a utilizzare la modalità Autopilot.
La tabella seguente descrive alcune delle configurazioni di sicurezza che Autopilot applica 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à:
|
| Container con privilegi | I container non possono essere eseguiti in modalità con privilegi, a meno che non vengano distribuiti da un partnerGoogle Cloud . I container con privilegi 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 workload negli spazi dei nomi gestiti da GKE, come 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
|
| Applicazione delle policy di sicurezza a livello di pod | Autopilot supporta i meccanismi di applicazione delle policy 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. |
| 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à Kubernetes |
| Impersonificazione di un utente | Autopilot supporta l'impersonificazione di un utente per tutti gli utenti e i gruppi definiti dall'utente. Solo nei cluster Autopilot, non è possibile impersonare utenti e gruppi di sistema (come l'utente |
| Webhook di ammissione dinamica di mutazione | Solo nei cluster Autopilot, GKE modifica i webhook di mutazione per escludere dall'intercettazione le risorse negli spazi dei nomi gestiti, come 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 asterisco ( |
| ValidatingAdmissionPolicies | Solo nei cluster Autopilot, GKE modifica gli oggetti 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 asterisco ( |
| MutatingAdmissionPolicies | Solo nei cluster Autopilot, GKE modifica gli oggetti 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 asterisco ( |
| 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 di sistema, i cluster Autopilot rifiutano le CertificateSigningRequest per identità con privilegi note, come gruppi di sistema, agenti di sistema o agenti di servizio IAM gestiti da Google. Questo vincolo non si applica ai cluster Standard, che consentono di creare CertificateSigningRequest per identità con privilegi note. |
| Funzionalità di sicurezza di GKE | I cluster Autopilot attivano le funzionalità di sicurezza di GKE consigliate. Per un elenco delle funzionalità di sicurezza abilitate e facoltative, consulta Funzionalità di sicurezza in Autopilot. |
| Sistema operativo del nodo | Autopilot utilizza 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 l'upgrade del control plane e dei nodi all'ultima versione idonea nel canale di rilascio nel tempo. |
Confini 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 workload di avere accesso di basso livello alla VM del nodo, in modo cheGoogle Cloud possa offrire la gestione completa dei nodi e uno SLA a livello di pod.
Il nostro obiettivo è impedire l'accesso involontario alla VM del nodo. Accettiamo segnalazioni in tal senso tramite il Vulnerability Reward Program (VRP) di Google e premieremo le segnalazioni a discrezione del panel di premiazione del VRP di Google.
Per impostazione predefinita, gli utenti con privilegi, come gli amministratori dei cluster, hanno il controllo completo di 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, ove possibile, come descritto nella nostra guida alla multi-tenancy.
Autopilot esegue il provisioning di VM single-tenant nel tuo progetto per il tuo utilizzo esclusivo. Su ogni singola VM, i workload Autopilot potrebbero essere eseguiti insieme, condividendo un kernel con sicurezza avanzata. Poiché il kernel condiviso rappresenta un unico confine di sicurezza, se hai bisogno di un isolamento efficace, ad esempio per workload ad alto rischio o non attendibili, ti consigliamo di eseguire i workload su 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 suggerimenti per pianificare, implementare e gestire la sicurezza dei cluster Autopilot in base al tuo caso d'uso.
Pianifica la sicurezza del cluster
| Caso d'uso | Risorse |
|---|---|
| Comprendere l'approccio alla sicurezza di GKE come piattaforma |
|
| Comprendi il tuo ruolo nell'hardening dell'ambiente | Scopri di più sul modello di responsabilità condivisa. |
| Visualizza i consigli di Google per le misure di protezione e la risposta agli incidenti |
|
| Scopri come GKE implementa l'audit logging |
|
Autentica e autorizza
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 |
|---|---|
| Autenticare utenti o applicazioni sul server API del cluster |
|
| Autentica le applicazioni per API e servizi Google Cloud | I cluster Autopilot ti consentono di utilizzare Workload Identity Federation for GKE per autenticare in modo sicuro i tuoi workload nelle API Google Cloud configurando i service account Kubernetes in modo che agiscano come service account IAM. Per istruzioni, consulta Configura le applicazioni per l'utilizzo di 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 Crea policy 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 su ruoli (RBAC) integrato di Kubernetes. Per le istruzioni, consulta Autorizza le azioni nei cluster utilizzando RBAC. |
| Autorizza le azioni a livello di organizzazione | Puoi utilizzare il servizio policy dell'organizzazione Google Cloud per applicare vincoli a operazioni specifiche sulle risorse GKE nella tua organizzazione Google Cloud. Per istruzioni, consulta Limita le azioni sulle risorse GKE utilizzando le policy dell'organizzazione personalizzate. |
Rafforza i cluster e i workload
Se hai requisiti di isolamento o protezione specializzati che vanno oltre le misure di Autopilot preconfigurate, considera le seguenti risorse:
| Caso d'uso | Risorse |
|---|---|
| Limita 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 Configura l'accesso al control plane. |
| Limita 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. |
| Archivia le informazioni sensibili all'esterno 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 tuoi cluster Autopilot utilizzando Workload Identity Federation for GKE. Per istruzioni, consulta Accedi ai secret archiviati al di fuori dei cluster GKE utilizzando Workload Identity Federation for 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 Verifica le immagini container al momento del deployment utilizzando Autorizzazione binaria. |
Monitora la tua security posture
Dopo aver configurato i cluster ed eseguito il deployment dei workload, devi configurare il monitoraggio e il logging in modo da avere osservabilità sulla security posture del cluster. Ti consigliamo di procedere come segue:
- Registra i tuoi cluster nella dashboard della security posture di GKE per controllare i workload alla ricerca di problemi come configurazioni di sicurezza problematiche o vulnerabilità nei pacchetti del sistema operativo dei container e ottenere informazioni utili per la mitigazione.
- Ricevi notifiche sui nuovi bollettini sulla sicurezza e sugli eventi di upgrade utilizzando le notifiche del cluster.
- Osserva i tuoi cluster utilizzando la dashboard 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 della sicurezza di GKE.
- Leggi la guida alla protezione di GKE.
- Iscriviti ai bollettini sulla sicurezza e alle note di rilascio.