Questa pagina descrive in che modo GKE Sandbox protegge il kernel dell'host sui nodi quando i container nel pod eseguono codice sconosciuto o non attendibile. Ad esempio, i cluster multi-tenant come i provider SaaS (Software-as-a-Service) spesso eseguono codice sconosciuto inviato dai propri utenti. GKE Sandbox è anche una misura di difesa in profondità per l'esecuzione di container di alto valore.
GKE Sandbox utilizza gVisor, un progetto open source. Questo argomento tratta ampiamente di gVisor, ma puoi scoprire maggiori dettagli leggendo la documentazione ufficiale di gVisor.
Per istruzioni su come abilitare e utilizzare GKE Sandbox, consulta Configurare GKE Sandbox.
Panoramica
GKE Sandbox fornisce un ulteriore livello di sicurezza per impedire che codice non attendibile influisca sul kernel dell'host sui nodi del cluster. Prima di discutere del funzionamento di GKE Sandbox, è utile comprendere la natura dei potenziali rischi che aiuta a mitigare.
Un runtime di container come containerd
fornisce un certo grado di isolamento tra i processi del container e il kernel in esecuzione sul nodo.
Tuttavia, il runtime del container viene spesso eseguito come utente con privilegi sul nodo e ha accesso alla maggior parte delle chiamate di sistema nel kernel dell'host.
Minacce potenziali
I cluster multi-tenant e i cluster i cui container eseguono carichi di lavoro non attendibili sono più esposti alle vulnerabilità della sicurezza rispetto ad altri cluster. Alcuni esempi sono i provider SaaS, i provider di hosting web o altre organizzazioni che consentono ai loro utenti di caricare ed eseguire codice. Un difetto nel runtime del container o nel kernel host potrebbe consentire a un processo in esecuzione all'interno di un container di eseguire l'"escape" del container e influire sul kernel del nodo, portando potenzialmente in pausa il nodo.
Esiste anche la possibilità che un tenant dannoso possa accedere ed esfiltrare i dati di un altro tenant in memoria o su disco sfruttando questo difetto.
Infine, un carico di lavoro non attendibile potrebbe potenzialmente accedere ad altri servizi Google Cloud o ai metadati del cluster.
In che modo GKE Sandbox attenua queste minacce
gVisor è una reimplementazione dello spazio utente dell'API Linux kernel che non richiede privilegi elevati. Insieme a un runtime di container come containerd
, il kernel dello spazio utente reimplementa la maggior parte delle chiamate di sistema e le gestisce per conto del kernel dell'host. L'accesso diretto al kernel
dell'host è limitato. Consulta la guida all'architettura di gVisor per informazioni dettagliate su come funziona. Dal punto di vista del container, gVisor è quasi trasparente e non richiede alcuna modifica all'applicazione containerizzata.
Quando richiedi GKE Sandbox in un pod in cluster Autopilot, GKE esegue il pod in una sandbox. In GKE Standard, se abiliti GKE Sandbox sui nodi, tutti i pod in esecuzione su questi nodi vengono eseguiti in sandbox.
Ogni sandbox utilizza il proprio kernel dello spazio utente. Tenendo conto di questo, puoi decidere come raggruppare i container nei pod in base al livello di isolamento richiesto e alle caratteristiche delle tue applicazioni.
GKE Sandbox è particolarmente adatto ai seguenti tipi di applicazioni. Consulta Limiti per ulteriori informazioni che ti aiutino a decidere per quali applicazioni eseguire la sandbox.
- Applicazioni non attendibili o di terze parti che utilizzano runtime come Rust, Java, Python, PHP, Node.js o Golang
- Front-end, cache o proxy di server web
- Applicazioni che elaborano dati o supporti esterni utilizzando le CPU
- Carichi di lavoro di machine learning mediante CPU
- Applicazioni che utilizzano molta CPU o memoria
- Carichi di lavoro ad alta intensità di GPU
Suggerimenti aggiuntivi per la sicurezza
Quando utilizzi GKE Sandbox, ti consigliamo di seguire anche questi consigli:
Specifica i limiti delle risorse per tutti i container in esecuzione in una sandbox. Ciò protegge dal rischio che un'applicazione difettosa o dannosa esaurisca il nodo di risorse e abbia un impatto negativo su altre applicazioni o processi di sistema in esecuzione sul nodo.
Se utilizzi Federazione delle identità per i carichi di lavoro per GKE, blocca l'accesso ai metadati del cluster utilizzando Criterio di rete per bloccare l'accesso a
169.254.169.254
. Ciò protegge dal rischio che un'applicazione dannosa acceda alle informazioni su dati potenzialmente privati come ID progetto, nome nodo e zona. La federazione delle identità per i carichi di lavoro per GKE è sempre abilitata nei cluster GKE Autopilot.
Limitazioni
GKE Sandbox funziona bene con molte applicazioni, ma non con tutte. Questa sezione fornisce ulteriori informazioni sulle attuali limitazioni di GKE Sandbox.
GPU in GKE Sandbox
In GKE versione 1.29.2-gke.1108000 e successive, GKE Sandbox supporta l'uso di GPU NVIDIA.
GKE Sandbox non mitiga tutte le vulnerabilità dei driver NVIDIA, ma mantiene la protezione contro le vulnerabilità del kernel Linux. Per maggiori dettagli su come il progetto gVisor protegge i carichi di lavoro GPU, consulta la guida di supporto delle GPU
Le seguenti limitazioni si applicano ai carichi di lavoro GPU all'interno di GKE Sandbox:
- È supportata solo la versione del driver NVIDIA
latest
su una determinata versione di GKE. I cluster Autopilot installano automaticamente le versioni dei driver NVIDIA che supportano GKE Sandbox. - Sono supportati solo i carichi di lavoro CUDA.
- Sono supportati i seguenti modelli di GPU: nvidia-tesla-t4, nvidia-tesla-a100, nvidia-a100-80 GB, nvidia-l4 e nvidia-h100-80 GB.
Puoi utilizzare GKE Sandbox con carichi di lavoro GPU senza costi aggiuntivi.
Configurazione del pool di nodi
Si applica ai cluster standard
- Non puoi utilizzare GKE Sandbox sui pool di nodi di Windows Server.
- Non puoi abilitare GKE Sandbox sul pool di nodi predefinito per separare i servizi di sistema in esecuzione nel pool di nodi predefinito dai carichi di lavoro non attendibili utilizzando GKE Sandbox.
- Quando utilizzi GKE Sandbox, il cluster deve avere almeno due pool di nodi. Devi sempre avere almeno un pool di nodi in cui GKE Sandbox è disabilitato. Questo pool di nodi deve contenere almeno un nodo, anche se tutti i carichi di lavoro sono sottoposti a sandbox.
- Le versioni GKE precedenti alla 1.24.2-gke.300 non supportano i tipi di macchine e2-micro, e2-small ed e2-medium. GKE versione 1.24.2-gke.300 e successive supportano questi tipi di macchine.
- I nodi devono utilizzare l'immagine del nodo Container-Optimized OS con containerd (
cos_containerd
).
Accesso ai metadati del cluster
Si applica ai cluster Autopilot e Standard
- I nodi che eseguono pod con sandbox non possono accedere ai metadati del cluster a livello del sistema operativo sul nodo.
- In GKE Standard, puoi eseguire pod normali su un nodo con GKE Sandbox abilitata. Tuttavia, per impostazione predefinita i pod normali non possono accedere ai servizi Google Cloud o ai metadati del cluster.
- Utilizza la Federazione delle identità per i carichi di lavoro per GKE per concedere ai pod l'accesso ai servizi Google Cloud.
SMT potrebbe essere disattivato
Si applica ai cluster Autopilot e Standard
Le impostazioni di multi-threading simultaneo (SMT) vengono utilizzate per mitigare le vulnerabilità del canale laterale che sfruttano i thread che condividono lo stato principale, ad esempio le vulnerabilità del campionamento dati Microarchitectural Data Sampling (MDS).
Nelle versioni GKE 1.25.5-gke.2500 o successive e 1.26.0-gke.2500 o successive, gVisor è configurato in modo da utilizzare Linux Core Scheduling per mitigare gli attacchi al canale laterale. Le impostazioni SMT non sono state modificate rispetto a quelle predefinite. Core Scheduler viene utilizzato solo per i carichi di lavoro in esecuzione con gVisor.
A partire da GKE versione 1.24.2-gke.300, SMT viene configurato per tipo di macchina in base alla vulnerabilità rispetto a MDS, come segue:
Pod Autopilot in esecuzione sulla classe di computing
Scale-Out
: SMT disabilitato.Tipi di macchine con processori Intel: SMT disabilitato per impostazione predefinita.
Tipi di macchina senza processori Intel: SMT abilitato per impostazione predefinita.
Tipi di macchina con un solo thread per core: nessun supporto SMT. Tutte le vCPU richieste sono visibili.
Prima della versione 1.24.2-gke.300, SMT è disabilitato su tutti i tipi di macchina.
Abilita SMT
Si applica ai cluster standard
Nei cluster GKE Standard, puoi abilitare SMT se è disabilitato sul tipo di macchina selezionato. Ti vengono addebitati i costi per ogni vCPU, indipendentemente dall'attivazione o meno di SMT. Per informazioni sui prezzi, fai riferimento ai prezzi di Compute Engine.
GKE 1.24.2-gke.300 e versioni successive
Imposta il flag --threads-per-core
durante la creazione di un pool di nodi GKE Sandbox:
gcloud container node-pools create smt-enabled \
--cluster=CLUSTER_NAME \
--machine-type=MACHINE_TYPE \
--threads-per-core=2 \
--sandbox type=gvisor
CLUSTER_NAME
: il nome del cluster esistente.MACHINE_TYPE
: il tipo di macchina.
Per maggiori informazioni su --threads-per-core
, consulta l'articolo
Impostare il numero di thread per core.
Versioni di GKE precedenti alla 1.24.2-gke.300
Crea un nuovo pool di nodi nel cluster con l'etichetta nodo
cloud.google.com/gke-smt-disabled=false
:gcloud container node-pools create smt-enabled \ --cluster=CLUSTER_NAME \ --machine-type=MACHINE_TYPE \ --node-labels=cloud.google.com/gke-smt-disabled=false \ --image-type=cos_containerd \ --sandbox type=gvisor
Esegui il deployment del DaemonSet nel pool di nodi. Il DaemonSet verrà eseguito solo sui nodi con l'etichetta
cloud.google.com/gke-smt-disabled=false
.kubectl create -f \ https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yaml
Assicurati che i pod del DaemonSet siano in esecuzione.
kubectl get pods --selector=name=enable-smt -n kube-system
L'output è simile al seguente:
NAME READY STATUS RESTARTS AGE enable-smt-2xnnc 1/1 Running 0 6m
Verifica che
SMT has been enabled
sia presente nei log dei pod.kubectl logs enable-smt-2xnnc enable-smt -n kube-system
Funzionalità
Si applica ai cluster standard
Per impostazione predefinita, al container non è consentito aprire socket non elaborati, per ridurre il rischio di attacchi dannosi. Alcuni strumenti relativi alla rete, come ping
e tcpdump
, creano socket non elaborati come parte della loro funzionalità di base. Per abilitare
i socket non elaborati, devi aggiungere esplicitamente la funzionalità NET_RAW
al
contesto di sicurezza del container:
spec:
containers:
- name: my-container
securityContext:
capabilities:
add: ["NET_RAW"]
Se utilizzi GKE Autopilot, Google Cloud ti impedisce di aggiungere l'autorizzazione NET_RAW
ai container a causa delle implicazioni per la sicurezza di questa funzionalità.
Dipendenze esterne
Si applica ai cluster Autopilot e Standard
Il codice non attendibile in esecuzione nella sandbox può raggiungere servizi esterni come server di database, API, altri container e driver CSI. Questi servizi sono in esecuzione al di fuori dei confini della sandbox e devono essere protetti singolarmente. Un utente malintenzionato può provare a sfruttare le vulnerabilità in questi servizi per uscire dalla sandbox. È necessario considerare il rischio e l'impatto di questi servizi che sono raggiungibili dal codice in esecuzione all'interno della sandbox e applicare le misure necessarie per proteggerli.
Ciò include implementazioni di file system per volumi dei container come i driver ext4 e CSI. I driver CSI vengono eseguiti al di fuori dell'isolamento sandbox e possono avere accesso privilegiato all'host e ai servizi. Un exploit in questi driver può influire sul kernel dell'host e compromettere l'intero nodo. Ti consigliamo di eseguire il driver CSI all'interno di un container con la quantità minima di autorizzazioni richieste, per ridurre l'esposizione in caso di exploit. GKE Sandbox supporta l'utilizzo del driver CSI per il disco permanente di Compute Engine.
Funzionalità incompatibili
Non puoi utilizzare GKE Sandbox con le seguenti funzionalità di Kubernetes:
- Metriche di utilizzo della memoria a livello di container. Tuttavia, l'utilizzo della memoria dei pod è supportato.
- Archiviazione del percorso host
- I limiti di CPU e memoria vengono applicati solo ai pod garantiti e ai pod bursabili e solo quando vengono specificati limiti di CPU e memoria per tutti i container in esecuzione nel pod.
- Container in esecuzione in modalità con privilegi
- VolumeDevices
- Port-forward
- Moduli di sicurezza kernel Linux come Seccomp, Apparmor o Selinux,
Sysctl,
NoNewPrivileges
, bidirezionale MountPropagation o ProcMount. - Traffic Director
ASM con Istio CNI
FSGroup è supportato in GKE 1.22 e versioni successive.
Cloud Service Mesh non è supportato per i pod GKE Sandbox nei cluster Autopilot.
Caratteristiche del carico di lavoro
Si applica ai cluster Autopilot e Standard
L'imposizione di un ulteriore livello indiretto per l'accesso al kernel del nodo comporta compromessi in termini di prestazioni. GKE Sandbox offre i vantaggi più tangibili sui cluster multi-tenant di grandi dimensioni in cui l'isolamento è importante. Tieni presente le seguenti linee guida quando testi i tuoi carichi di lavoro con GKE Sandbox.
Chiamate di sistema
Si applica ai cluster Autopilot e Standard
I carichi di lavoro che generano un volume elevato di chiamate di sistema con costi ridotti, ad esempio un numero elevato di operazioni di I/O di piccole dimensioni, potrebbero richiedere più risorse di sistema quando vengono eseguite in una sandbox, quindi potrebbe essere necessario utilizzare nodi più potenti o aggiungere altri nodi al cluster.
Accesso diretto all'hardware o alla virtualizzazione
Si applica ai cluster Autopilot e Standard
Se il tuo carico di lavoro ha bisogno di uno dei seguenti requisiti, GKE Sandbox potrebbe non essere adatto perché impedisce l'accesso diretto al kernel dell'host sul nodo:
- Accesso diretto all'hardware del nodo
- Funzionalità di virtualizzazione a livello di kernel
- Container con privilegi
Passaggi successivi
- Configura GKE Sandbox.
- Leggi la panoramica sulla sicurezza.
- Scopri di più sul ciclo di vita dei pod.