Questo documento descrive in che modo GKE Sandbox protegge il kernel host sui nodi quando i container nel pod eseguono codice sconosciuto o non attendibile. Questo documento presuppone che tu conosca le seguenti informazioni:
- gVisor, il progetto open source utilizzato da GKE Sandbox.
Questo documento è destinato agli specialisti della sicurezza per scoprire i vantaggi di GKE Sandbox. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti GKE.
Puoi utilizzare GKE Sandbox quando esegui cluster multi-tenant perché i fornitori di software as a service (SaaS) spesso eseguono codice sconosciuto inviato dai loro utenti. GKE Sandbox è anche una misura di difesa in profondità utile per l'esecuzione di container di alto valore.
Per scoprire come abilitare e utilizzare GKE Sandbox, consulta Configurare GKE Sandbox.
Panoramica
GKE Sandbox fornisce un ulteriore livello di sicurezza per impedire che il codice non attendibile influisca sul kernel host sui nodi del cluster. Prima di parlare del funzionamento di GKE Sandbox, è utile comprendere la natura dei potenziali rischi che aiuta a mitigare.
Un runtime del 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 al kernel host.
Potenziali minacce
I cluster multi-tenant e i cluster i cui container eseguono carichi di lavoro non attendibili sono più esposti alle vulnerabilità di sicurezza rispetto ad altri cluster. Esempi includono fornitori di SaaS, fornitori di web hosting o altre organizzazioni che consentono ai propri 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 "uscire" dal container e influire sul kernel del nodo, potenzialmente causando l'arresto del nodo.
Esiste anche la possibilità che un tenant malintenzionato ottenga l'accesso ai dati di un altro tenant in memoria o su disco ed esfiltri i dati sfruttando un difetto di questo tipo.
Infine, un carico di lavoro non attendibile potrebbe potenzialmente accedere ad altri Google Cloud servizi o ai metadati del cluster.
In che modo GKE Sandbox mitiga le potenziali minacce
gVisor è una riimplementazione nello spazio utente dell'API del kernel Linux che non richiede privilegi elevati. Insieme a un runtime del container come containerd , il kernel dello spazio utente riimplementa la maggior parte delle chiamate di sistema e le gestisce per conto del kernel host. L'accesso diretto al kernel host è limitato. Per informazioni dettagliate sul funzionamento, consulta la
guida all'architettura di gVisor. Dal punto di vista del container, gVisor è quasi trasparente e non richiede modifiche all'applicazione containerizzata.
Quando richiedi GKE Sandbox in un pod nei 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 presente 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 per i seguenti tipi di applicazioni. Per ulteriori informazioni che ti aiutino a decidere quali applicazioni inserire nella sandbox, consulta Limitazioni.
- Applicazioni non attendibili o di terze parti che utilizzano runtime come Rust, Java, Python, PHP, Node.js o Golang
- Front-end, cache o proxy del server web
- Applicazioni che elaborano contenuti multimediali o dati esterni utilizzando le CPU
- Carichi di lavoro di machine learning che utilizzano le CPU
- Applicazioni che utilizzano molta CPU o memoria
I carichi di lavoro o i servizi AI/ML spesso richiedono un deployment più rapido in produzione. gVisor è progettato per proteggere da intere classi di vulnerabilità comuni di Linux. Con GKE Sandbox, puoi migliorare la tua postura di sicurezza sui carichi di lavoro intensivi di GPU e TPU senza apportare modifiche significative al codice. I casi d'uso principali in cui GKE Sandbox si adatta bene sono comuni ai carichi di lavoro AI/ML:
- Carichi di lavoro intensivi di GPU e TPU.
- Servizi che accettano ed eseguono codice utente non attendibile.
- Servizi che elaborano input utente arbitrari.
- Carichi di lavoro che elaborano modelli e set di dati di terze parti di grandi dimensioni.
- Applicazioni che utilizzano librerie di terze parti.
Scopri di più sulla progettazione e sulla sicurezza dell'accesso agli acceleratori, consulta le guide alle GPU e alle TPU di gVisor.
Altri suggerimenti sulla sicurezza
Quando utilizzi GKE Sandbox, ti consigliamo di seguire anche questi suggerimenti:
Specifica i limiti delle risorse per tutti i container in esecuzione in una sandbox. In questo modo, puoi proteggerti dal rischio che un'applicazione difettosa o dannosa privi il nodo di risorse e influisca negativamente su altre applicazioni o processi di sistema in esecuzione sul nodo.
Se utilizzi Workload Identity Federation for GKE, blocca l'accesso ai metadati del cluster utilizzando la policy di rete per bloccare l'accesso a
169.254.169.254. In questo modo, puoi proteggerti dal rischio che un'applicazione dannosa acceda a informazioni potenzialmente private come ID progetto, nome del nodo e zona. Workload Identity Federation for GKE è sempre abilitato nei cluster GKE Autopilot.
Limitazioni
GKE Sandbox funziona bene con molte applicazioni, ma non con tutte. Questa sezione fornisce maggiori informazioni sulle limitazioni attuali di GKE Sandbox.
GPU in GKE Sandbox
Nella versione GKE 1.29.2-gke.1108000 e successive, GKE Sandbox supporta l'utilizzo di GPU NVIDIA.
GKE Sandbox non mitiga tutte le vulnerabilità dei driver NVIDIA, ma mantiene la protezione dalle vulnerabilità del kernel Linux. Quando utilizzi GKE Sandbox, non ti consigliamo di utilizzare la condivisione del tempo della GPU perché la GPU non è completamente isolata tra i pod. Per informazioni dettagliate su come il progetto gVisor protegge i carichi di lavoro GPU, consulta la Guida al supporto delle GPU.
Le seguenti limitazioni si applicano ai carichi di lavoro GPU in GKE Sandbox:
- Sono supportati solo i carichi di lavoro CUDA.
- Un sottoinsieme di GPU supportate su GKE è supportato su GKE Sandbox. Per maggiori informazioni, consulta la tabella di supporto.
- gVisor supporta solo alcune versioni dei driver NVIDIA. GKE Sandbox garantisce che sia il driver
latestsia il driverdefaultper ogni GPU supportata per ogni versione GKE siano compatibili. Non è garantito che gli altri driver funzionino. - Non tutte le funzionalità della GPU funzioneranno in modo nativo (ad es. RDMA o IMEX). Le funzionalità della GPU saranno supportate caso per caso in base alle esigenze del cliente. Invia una richiesta di assistenza o segnala un bug su GitHub Issues di gVisor.
Puoi utilizzare GKE Sandbox con i carichi di lavoro GPU senza costi aggiuntivi.
Supporto del modello GPU di GKE Sandbox
La tabella seguente descrive il supporto per i diversi modelli di GPU su GKE Sandbox:
| Modello | Anteprima | Assistenza GA | Note |
|---|---|---|---|
|
|
|
- | - |
|
|
|
- | - |
|
|
- |
|
Supportato dal lancio iniziale. |
|
|
non supportato | non supportato | V100 e P100 utilizzano driver proprietari e non saranno supportati. |
|
|
- | - | GKE Sandbox non supporta i tipi di nodi Windows o Ubuntu, necessari per i nodi delle workstation virtuali. |
TPU in GKE Sandbox
Nella versione GKE 1.31.3-gke.1111001 e successive, GKE Sandbox supporta l'utilizzo di TPU.
GKE Sandbox non mitiga tutte le vulnerabilità dei driver TPU, ma mantiene la protezione dalle vulnerabilità del kernel Linux. Per informazioni dettagliate su come il progetto gVisor protegge i carichi di lavoro TPU, consulta la Guida al supporto delle TPU.
Sono supportate le seguenti versioni hardware TPU: V4pod, V4lite, V5litepod, V5pod e V6e.
Puoi utilizzare GKE Sandbox con i carichi di lavoro TPU senza costi aggiuntivi.
Configurazione del node pool
Si applica ai cluster Standard
- Non puoi utilizzare GKE Sandbox sui node pool 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 che utilizzano GKE Sandbox.
- Quando utilizzi GKE Sandbox, il cluster deve avere almeno due node pool. 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 in sandbox.
- Le versioni di GKE precedenti alla 1.24.2-gke.300 non supportano i tipi di macchine e2-micro, e2-small ed e2-medium. La versione GKE 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 in 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 abilitato. Tuttavia, per impostazione predefinita, questi pod normali non possono accedere ai Google Cloud servizi o ai metadati del cluster.
- Utilizza Workload Identity Federation for GKE per concedere ai pod l'accesso ai Google Cloud servizi.
SMT potrebbe essere disabilitato
Si applica ai cluster Autopilot e Standard
Le impostazioni del multi-threading simultaneo (SMT) vengono utilizzate per mitigare le vulnerabilità dei canali laterali che sfruttano lo stato del core di condivisione dei thread, come le vulnerabilità di Microarchitectural Data Sampling (MDS).
Nelle versioni GKE 1.25.5-gke.2500 o successive e 1.26.0-gke.2500 o successive, gVisor è configurato per utilizzare la pianificazione dei core Linux per mitigare gli attacchi dei canali laterali. Le impostazioni SMT rimangono invariate rispetto a quelle predefinite. La pianificazione dei core viene utilizzata solo per i carichi di lavoro in esecuzione con gVisor.
A partire dalla versione GKE 1.24.2-gke.300, SMT viene configurato in base al tipo di macchina in base alla vulnerabilità della macchina a MDS, come segue:
Pod Autopilot in esecuzione sulla
Scale-Outclasse di computing: SMT disabilitato.Tipi di macchine con processori Intel: SMT disabilitato per impostazione predefinita.
Tipi di macchine senza processori Intel: SMT abilitato per impostazione predefinita.
Tipi di macchine 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 macchine.
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 dal fatto che tu attivi o disattivi SMT. Per informazioni sui prezzi, consulta i prezzi di Compute Engine.
Versione GKE 1.24.2-gke.300 e successive
Imposta il --threads-per-core flag quando
crei un pool di nodi GKE Sandbox:
gcloud container node-pools create smt-enabled \
--cluster=CLUSTER_NAME \
--location=LOCATION \
--machine-type=MACHINE_TYPE \
--threads-per-core=2 \
--sandbox type=gvisor
CLUSTER_NAME: il nome di un cluster esistente in cui vuoi creare il nuovo pool di nodi.LOCATION: la regione o la zona di Compute Engine del cluster.MACHINE_TYPE: il tipo di macchina.
Per saperne di più su --threads-per-core, consulta
Imposta il numero di thread per core.
Versioni GKE precedenti alla 1.24.2-gke.300
Crea un nuovo pool di nodi nel tuo cluster con l'etichetta nodo
cloud.google.com/gke-smt-disabled=false:gcloud container node-pools create smt-enabled \ --cluster=CLUSTER_NAME \ --location=LOCATION \ --machine-type=MACHINE_TYPE \ --node-labels=cloud.google.com/gke-smt-disabled=false \ --image-type=cos_containerd \ --sandbox type=gvisorSostituisci quanto segue:
CLUSTER_NAME: il nome di un cluster esistente in cui vuoi creare il nuovo pool di nodi.LOCATION: la regione o la zona di Compute Engine del cluster.MACHINE_TYPE: il tipo di macchina.
Esegui il deployment di DaemonSet nel pool di nodi. DaemonSet viene 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.yamlVerifica che i pod di DaemonSet siano in esecuzione.
kubectl get pods --selector=name=enable-smt -n kube-systemL'output è simile al seguente:
NAME READY STATUS RESTARTS AGE enable-smt-2xnnc 1/1 Running 0 6mControlla che nei log dei pod sia presente la dicitura
SMT has been enabled.kubectl logs enable-smt-2xnnc enable-smt -n kube-system
Funzionalità
Si applica ai cluster Standard
Per impostazione predefinita, il container non può aprire socket non elaborati, per ridurre il potenziale di attacchi dannosi. Alcuni strumenti correlati alla rete, come ping e tcpdump, creano socket non elaborati come parte della loro operazione principale. 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 non puoi
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 all'interno della sandbox potrebbe essere autorizzato a raggiungere servizi esterni come server di database, API, altri container e driver CSI. Questi servizi sono in esecuzione al di fuori del limite della sandbox e devono essere protetti singolarmente. Un attaccante può tentare di sfruttare le vulnerabilità di questi servizi per uscire dalla sandbox. Devi considerare il rischio e l'impatto di questi servizi raggiungibili dal codice in esecuzione all'interno della sandbox e applicare le misure necessarie per proteggerli.
Sono incluse le implementazioni del file system per i volumi dei container, come ext4 e i driver CSI. I driver CSI vengono eseguiti al di fuori dell'isolamento della sandbox e potrebbero avere accesso con privilegi all'host e ai servizi. Uno sfruttamento di questi driver può influire sul kernel 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à non compatibili
Non puoi utilizzare GKE Sandbox con le seguenti funzionalità di Kubernetes:
- Metriche di memoria utilizzata a livello di container. Tuttavia, l'utilizzo della memoria dei pod è supportato.
- Archiviazione hostPath
- I limiti di CPU e memoria vengono applicati solo ai pod Guaranteed e Burstable e solo quando i limiti di CPU e memoria vengono specificati per tutti i container in esecuzione nel pod.
- Container in esecuzione in modalità con privilegi
- VolumeDevices
- Portforward
- Moduli di sicurezza del kernel Linux come Seccomp, Apparmor o Selinux,
Sysctl,
NoNewPrivileges, MountPropagation bidirezionale, o ProcMount. FSGroup è supportato nella versione GKE 1.22 e 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 di indirezione per l'accesso al kernel del nodo comporta compromessi in termini di prestazioni. GKE Sandbox offre il vantaggio più tangibile sui cluster multi-tenant di grandi dimensioni in cui l'isolamento è importante. Tieni presente le seguenti linee guida quando testi i 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 a basso overhead, ad esempio un numero elevato di piccole operazioni di I/O, potrebbero richiedere più risorse di sistema quando vengono eseguiti 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 richiede uno dei seguenti elementi, GKE Sandbox potrebbe non essere adatto perché impedisce l'accesso diretto al kernel 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.