In questa pagina vengono descritte le funzionalità, le configurazioni e le impostazioni di sicurezza in Google Kubernetes Engine (GKE) Autopilot, che è il metodo consigliato per per eseguire GKE.
Chi dovrebbe utilizzare questa pagina?
Questa pagina è rivolta agli amministratori della sicurezza che desiderano conoscere il limitazioni di sicurezza che Google applica specificamente ad Autopilot cluster e le funzionalità di sicurezza disponibili per l'uso 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 abilitano e applicano le best practice per la sicurezza per impostazione predefinita, inclusi molti dei consigli nella panoramica e Rafforza la sicurezza del cluster.
Se vuoi utilizzare risorse consigliate in base al tuo caso d'uso, passa a Risorse per la sicurezza in base ai casi d'uso. Le seguenti sezioni descrivere 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 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 la maggior parte senza modifiche significative.
- Limitata: 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. Me applicare in modo forzato un criterio di sicurezza predefinito che includa tutti i suggerimenti il livello base degli standard di sicurezza dei pod, con alcune modifiche l'usabilità. Inoltre, il criterio di ammissione GKE Warden predefinito per Autopilot applica molti vincoli al livello Restricted gli standard di sicurezza dei pod, ma evita le restrizioni che potrebbero bloccare la 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 come vengono usati i controlli nella modalità Autopilot predefinita Confronto tra il criterio GKE Warden e i controlli della base di riferimento e ai livelli Restricted degli standard di sicurezza dei pod. Per le descrizioni per ciascun controllo in questa tabella, vedere la voce corrispondente in Standard di sicurezza dei pod.
Durante la valutazione della conformità, abbiamo considerato il modo in cui i vincoli si applicano carichi di lavoro con scale out impegnativi. Sono esclusi i carichi di lavoro verificati dei partner Google Cloud e e carichi di lavoro 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 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 ad esempio per l'esecuzione di strumenti di sicurezza e monitoraggio. | ||
| Funzionalità Linux | I carichi di lavoro Autopilot possono accedere solo alle funzionalità specificate nel Baseline Pod Security Standard per impostazione predefinita. 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 | Non è consentito impostare porte host specifiche, il che limita alcune problemi di pianificazione, e impedisce l'esposizione diretta e accidentale dei servizi alla rete. 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 è stato applicato perché AppArmor è già applicato. SELinux è non è inoltre 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 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. |
||
| sysctls | 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. Questa impostazione è attualmente utile anche per de-privilegidere i carichi di lavoro. a quelle non root, consentendo l'uso di funzionalità del file system per difetti nella gestione delle funzionalità root di Kubernetes. | ||
| Esegui come 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.
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 |
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 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à:
Nelle versioni GKE precedenti alla 1.21, la funzionalità |
| Container con privilegi | I container non possono essere eseguiti in modalità con privilegi a meno che non venga eseguito il deployment del container da un Partner Google Cloud. I container con privilegi possono apportare modifiche al nodo sottostante, ad esempio che modificano il kubelet. Questo accesso potrebbe aumentare l'impatto di un pod degli utenti. |
| Spazi dei nomi gestiti da GKE | Come misura di sicurezza, Autopilot non consente il deployment
carichi di lavoro negli spazi dei nomi gestiti da GKE,
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 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à 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 | Supporto per GKE versione 1.22.4-gke.1501 e successive
impersonificazione degli utenti per tutti gli utenti e i gruppi definiti dagli utenti. 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 uno o più le 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 - 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 abilitano i GKE consigliati le funzionalità di sicurezza. Per un elenco delle funzionalità di sicurezza abilitate e facoltative vedi le funzionalità di sicurezza in Autopilot. |
| Sistema operativo 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 GKE | I cluster Autopilot sono registrati in una release GKE canale al momento della creazione e gli upgrade automatici sono sempre attivati. Google esegue automaticamente l'upgrade del piano di controllo e dei nodi agli ultimi nel canale di rilascio. |
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. La l'obiettivo è limitare la possibilità di accedere, modificare o controllare direttamente il nodo di una macchina virtuale (VM). 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 in tal senso tramite Programma Google Vulnerability Reward Program (VRP) e premierà 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 in qualsiasi cluster GKE. Come best practice per la sicurezza, ti consigliamo eviterai di concedere a un ampio ventaglio i potenti privilegi di GKE o Kubernetes e utilizza invece la delega dell'amministratore dello spazio dei nomi, se possibile, come descritto nel nostro guida all'architettura multi-tenancy.
Autopilot esegue il provisioning di VM single-tenant nel tuo progetto per uso esclusivo. Su ogni singola VM, i tuoi carichi di lavoro Autopilot insieme, condividendo un kernel protetto dalla sicurezza. Poiché il kernel condiviso un singolo confine di sicurezza, ti consigliamo, se hai bisogno di di isolamento, ad esempio carichi di lavoro ad alto rischio o non attendibili, esegui i carichi di lavoro di pod di GKE Sandbox con una protezione multilivello.
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 |
|---|---|
| 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 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. |
| Autorizza azioni a livello di progetto | Per autorizzare le azioni tra i cluster a livello di progetto, utilizza o IAM. Puoi concedere o negare l'accesso a specifiche Risorse API GKE e Kubernetes con IAM ruoli e autorizzazioni. Per le istruzioni, consulta Creare criteri IAM. |
| Autorizza 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 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 i vincoli operazioni specifiche su risorse GKE in Google Cloud dell'organizzazione. 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 specifici di isolamento o protezione di 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, disabilita 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 | Usa 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 dal i tuoi cluster Autopilot utilizzando la federazione delle identità per i carichi di lavoro per GKE. Per istruzioni, consulta Accedi 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 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 e eseguito il deployment dei carichi di lavoro, devi configurare e configurare il monitoraggio e il logging in modo da avere l'osservabilità del della strategia di sicurezza del cluster. Ti consigliamo di eseguire tutte le seguenti operazioni:
- Registra i cluster nel Dashboard della strategia di sicurezza di GKE per verificare la presenza di problemi nei carichi di lavoro, ad esempio configurazioni di sicurezza problematiche o vulnerabilità nei pacchetti del sistema operativo dei container e ottieni informazioni fruibili per la mitigazione.
- Ricevi notifiche sui nuovi bollettini sulla sicurezza ed eventi di upgrade utilizzando notifiche di cluster.
- Osserva i cluster utilizzando Dashboard di GKE in Cloud Monitoring o Scheda Osservabilità in GKE.
- Scopri come visualizzare e gestisci Audit log di 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.