GKE Sandbox

I container che eseguono codice sconosciuto o non attendibile nei cluster Google Kubernetes Engine (GKE) rappresentano un potenziale rischio per la sicurezza del kernel host dei nodi. Puoi proteggere il kernel host da queste minacce isolando il codice dal kernel. Questo documento descrive come GKE Sandbox crea questo livello di isolamento utilizzando tecnologie come gVisor e microVM.

Questo documento è destinato agli esperti di sicurezza che vogliono ridurre la superficie di attacco nei nodi GKE e proteggerli da codice non attendibile. Dovresti già avere familiarità con quanto segue:

Informazioni sul sandboxing in GKE

Il runtime del container installato sui nodi, ad esempio containerd, fornisce un certo livello 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.

In Kubernetes e GKE, il sandboxing isola i container in esecuzione per limitare il potenziale impatto di exploit o errori che interessano altri container o il runtime del container. Puoi eseguire i container in sandbox per proteggere il kernel dell'istanza Compute Engine sottostante da codice non attendibile o sconosciuto. Il sandboxing è anche una buona misura di difesa in profondità per proteggere i container di alto valore dall'influenza di altri carichi di lavoro. Puoi eseguire i workload in sandbox utilizzando GKE Sandbox.

Potenziali minacce

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. I cluster multi-tenant e i cluster in cui i container eseguono workload non attendibili sono più esposti alle vulnerabilità di sicurezza rispetto ad altri cluster. Alcuni esempi sono:

  • Organizzazioni che consentono agli utenti di caricare ed eseguire codice, come fornitori SaaS e fornitori di hosting web.
  • Agenti AI che generano ed eseguono codice, spesso senza supervisione.

Le tecnologie di sandboxing utilizzate da GKE Sandbox aiutano a mitigare il seguente potenziale impatto dei container escape:

  • Codice dannoso o difettoso che causa l'arresto anomalo del kernel host e del nodo.
  • Tenant malintenzionati che sottraggono i dati di un altro tenant presenti in memoria o su un disco.
  • Workload non attendibili che accedono ad altri servizi Google Cloud o ai metadati del cluster.

Tecnologie sandbox in GKE

GKE Sandbox supporta le seguenti tecnologie sandbox, ognuna delle quali utilizza un approccio diverso per isolare i workload e funziona bene per diversi casi d'uso:

  • gVisor: una reimplementazione nello spazio utente dell'API del kernel Linux che non richiede privilegi elevati. Il kernel userspace e il runtime del container reimplementano la maggior parte delle chiamate di sistema e le gestiscono per conto del kernel host. L'accesso diretto al kernel host è limitato. Per maggiori informazioni sul funzionamento del kernel guest, consulta la Guida all'architettura di gVisor.

  • MicroVMs: macchine virtuali leggere che eseguono un kernel Linux completo e un sistema operativo. Ogni pod viene eseguito nella propria microVM, che fornisce un isolamento rigoroso dagli altri pod e dal nodo host. GKE Sandbox utilizza il software open source Kata Containers e il monitor della macchina virtuale Cloud Hypervisor (VMM) per creare e gestire le microVM.

La seguente tabella riassume le principali differenze tra gVisor e le microVM. Utilizza queste informazioni per scegliere la tecnologia sandbox appropriata per il tuo caso d'uso.

gVisor MicroVMs
Accesso al kernel Sottoinsieme di chiamate di sistema del kernel Linux Kernel Linux completo
Livello di isolamento Intercettazione delle chiamate di sistema in un kernel userspace Virtualizzazione hardware completa con un kernel guest dedicato
Overhead di CPU e memoria Overhead dinamico con memoria di base ridotta per il kernel dello spazio utente Overhead fisso di 250 mCPU e 130 MiB di memoria per ogni pod
Ora di inizio Meno di 200 ms Circa 1-2 secondi
Configurazione dei nodi GKE Disponibile in tutti i pool di nodi Standard e nei nodi Autopilot. Abilitato per impostazione predefinita nei cluster Autopilot. Disponibile solo nei nodi che abilitano la virtualizzazione nidificata.
Supporto delle immagini dei nodi Solo Container-Optimized OS Container-Optimized OS o Ubuntu
Compatibilità dei tipi di macchina Supportato dalla maggior parte delle CPU, dall'architettura Arm e dai tipi di macchine con acceleratore. Supportato solo dai tipi di macchine che supportano la virtualizzazione nidificata.
Supporto degli acceleratori Supporta modelli di GPU e versioni di TPU specifici. Non supporta GPU o TPU.
Container con privilegi Non supportati. Supportato. I container con privilegi ottengono l'accesso root solo al sistema operativo guest nella microVM e non al nodo host.
Esempi di casi d'uso
  • Applicazioni non attendibili o di terze parti che utilizzano runtime come Rust, Java, Python, PHP, Node.js o Golang
  • Frontend, cache o proxy di server web
  • Applicazioni che elaborano contenuti multimediali o dati esterni utilizzando le CPU
  • Workload che richiedono un uso intensivo di GPU e TPU
  • Carichi di lavoro di inferenza AI che elaborano input arbitrari o eseguono codice
  • Workload di addestramento che elaborano modelli e set di dati di terze parti di grandi dimensioni
  • Agenti AI che generano ed eseguono codice senza supervisione
  • Codice autonomo eseguito nei browser, ad esempio Puppeteer
  • Carichi di lavoro che prevedono l'accesso al kernel Linux completo
  • Workload che generano un volume elevato di chiamate di sistema a basso overhead, come un numero elevato di piccole operazioni di I/O

Per ulteriori informazioni che potrebbero aiutarti a decidere quali applicazioni eseguire in un tipo specifico di sandbox, consulta Limitazioni.

Come funziona la richiesta di sandbox

Per eseguire un'applicazione in una sandbox:

  1. Abilita una tecnologia sandbox nei nodi utilizzando ComputeClass per creare automaticamente i nodi o creando manualmente i node pool.
  2. Richiedi una sandbox per i pod utilizzando la classe RuntimeClass corrispondente per quel tipo di sandbox, ad esempio gvisor o microvm. Per maggiori informazioni, consulta Rafforzare l'isolamento dei workload con GKE Sandbox.

GKE pianifica i pod sui nodi che utilizzano la tecnologia della sandbox richiesta, che poi gestisce l'esecuzione dell'applicazione nella sandbox. Se vuoi, puoi eseguire i pod che non richiedono sandbox sui nodi in cui è abilitato GKE Sandbox utilizzando selettori di nodi e tolleranze, il che è utile per i workload attendibili, come gli strumenti di monitoraggio, che vuoi eseguire su ogni nodo.

Altri suggerimenti per la sicurezza

Quando utilizzi GKE Sandbox, ti consigliamo di seguire anche questi suggerimenti:

  • Specifica limiti delle risorse su tutti i container in esecuzione in un sandbox. In questo modo si protegge dal rischio che un'applicazione difettosa o dannosa privi il nodo di risorse e influenzino negativamente 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 Network Policy per bloccare l'accesso a 169.254.169.254. In questo modo, si protegge dal rischio che un'applicazione malintenzionata acceda a informazioni potenzialmente private come ID progetto, nome del nodo e zona. La federazione delle identità per i workload per GKE è sempre abilitata 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

Puoi eseguire i workload della GPU in sandbox utilizzando gVisor. gVisor non mitiga tutte le vulnerabilità dei driver NVIDIA, ma mantiene la protezione contro le vulnerabilità del kernel Linux. Non utilizzare la condivisione del tempo della GPU nei pod in sandbox, perché la GPU non è completamente isolata tra i pod. Per saperne di più su come gVisor protegge i workload GPU, consulta la Guida al supporto delle GPU.

Ai carichi di lavoro GPU in GKE Sandbox si applicano le seguenti limitazioni:

  • Le microVM non supportano le GPU.
  • Per gVisor si applicano le seguenti limitazioni:
    • Sono supportati solo i carichi di lavoro CUDA.
    • È supportato solo un sottoinsieme dei modelli di GPU disponibili. Per ulteriori informazioni, vedi Supporto dei modelli di GPU.
    • Per ogni versione di GKE sono supportate solo le versioni dei driver NVIDIA latest e default. Altre versioni del driver potrebbero non funzionare.
    • Non tutte le funzionalità della GPU, come RDMA o IMEX, sono supportate. A seconda delle esigenze dei clienti, gVisor potrebbe supportare funzionalità specifiche caso per caso. Per richiedere assistenza per una funzionalità specifica, apri una richiesta di assistenza o apri una richiesta di funzionalità gVisor.

Supporto dei modelli di GPU

La tabella seguente descrive il supporto per diversi modelli di GPU in GKE Sandbox:

Modello Anteprima Assistenza GA Note
  • NVIDIA RTX PRO 6000
    		•
  • Tipi di macchine con una o più GPU: 1.34.1-gke.2037001 e versioni successive
  • Tipi di macchine con meno di una GPU: non supportati
    		• - -
  • NVIDIA GB200
  • NVIDIA B200
  • NVIDIA H200 141GB
    		•
  • 1.34.0-gke.1713000 e versioni successive
    		•  - -
  • NVIDIA H100 da 80 GB
  • NVIDIA A100 da 80 GB
  • NVIDIA A100 da 40 GB
  • NVIDIA L4
  • NVIDIA T4
    		•  -
  • 1.29.15-gke.1134000 e versioni successive
  • 1.30.11-gke.1093000 e versioni successive
  • 1.31.7-gke.1149000 e versioni successive
  • 1.32.2-gke.1182003 e versioni successive
    		•  Supportato dal lancio iniziale.
  • NVIDIA V100
  • NVIDIA P100 (fine del supporto imminente)
    		•  non supportato non supportato Le GPU V100 e P100 utilizzano driver proprietari e non saranno supportate.
  • NVIDIA T4 VWS
  • NVIDIA L4 VWS
    		•  - - GKE Sandbox non supporta i tipi di nodi Windows o Ubuntu, che sono richiesti per i nodi delle workstation virtuali.

    TPU in GKE Sandbox

    In GKE versione 1.31.3-gke.1111001 e successive, puoi eseguire i workload TPU in sandbox utilizzando gVisor. gVisor non mitiga tutte le vulnerabilità dei driver TPU, ma mantiene la protezione contro le vulnerabilità del kernel Linux. Per saperne di più su come il progetto gVisor protegge i carichi di lavoro TPU, consulta la Guida all'assistenza TPU.

    Ai carichi di lavoro TPU in GKE Sandbox si applicano le seguenti limitazioni:

    • Le microVM non supportano le TPU.

    • gVisor supporta le seguenti versioni di TPU:

      • V4pod
      • V4lite
      • V5litepod
      • V5pod
      • V6e

    Configurazione dei nodi

    Ai nodi che utilizzano GKE Sandbox si applicano le seguenti limitazioni:

    • gVisor e le microVM supportano solo i nodi Linux. I nodi Windows Server non sono supportati.
    • gVisor supporta solo l'immagine del nodo Container-Optimized OS. Le microVM supportano le immagini del nodo Container-Optimized OS e Ubuntu.
    • Le microVM richiedono l'abilitazione della virtualizzazione nidificata sui nodi. Si applicano tutti i requisiti e le limitazioni della virtualizzazione nidificata.
    • Nei cluster Standard, non puoi abilitare GKE Sandbox nel pool di nodi predefinito. Il cluster deve avere sempre almeno un pool di nodi che non utilizza GKE Sandbox. Questo pool di nodi deve contenere almeno un nodo, anche se tutti i tuoi workload sono in sandbox. Questa limitazione esiste per separare i servizi di sistema dai carichi di lavoro non attendibili.

    Accesso ai metadati del cluster

    Se i tuoi nodi utilizzano il tipo di sandbox gVisor, i pod sui nodi non possono accedere ai metadati del cluster a livello di sistema operativo del nodo. Inoltre, i pod non possono accedere ai servizi Google Cloud a meno che tu non utilizzi Workload Identity Federation for GKE per concedere ruoli alle identità dei pod.

    Questa limitazione non si applica al tipo di sandbox microVM. Per impedire l'accesso ai metadati del cluster dai pod nelle microVM, utilizza una NetworkPolicy che nega il traffico in uscita a 169.254.169.252/32 sulla porta 988 o, nei cluster che utilizzano GKE Dataplane V2, a 169.254.169.254/32 sulla porta 80.

    SMT potrebbe essere disattivato

    Le impostazioni di multi-threading simultaneo (SMT), noto anche come Hyper-Threading sulle CPU Intel, vengono utilizzate per mitigare le vulnerabilità dei canali laterali che sfruttano i thread che condividono lo stato del core, come le vulnerabilità di Microarchitectural Data Sampling (MDS).

    Per mitigare gli attacchi side-channel, gVisor utilizza Linux Core Scheduling. Le impostazioni SMT sono invariate rispetto ai valori predefiniti. La pianificazione dei core Linux si applica solo ai pod eseguiti nei sandbox gVisor.

    L'impostazione SMT o Hyper-Threading predefinita per un tipo di macchina dipende dalla vulnerabilità della macchina a MDS, come segue:

    • Pod Autopilot che utilizzano la Scale-Out ComputeClass: SMT è sempre disabilitato.
    • Tipi di macchine che utilizzano processori Intel: l'hyperthreading è disattivato per impostazione predefinita.
    • Tipi di macchine che utilizzano processori AMD: SMT è attivato per impostazione predefinita.
    • Tipi di macchina che utilizzano un solo thread per core, come i processori Arm: nessun supporto SMT. Tutte le vCPU richieste sono visibili.

    Abilita SMT

    Nei pool di nodi GKE Standard, puoi abilitare SMT se è disabilitato per impostazione predefinita per il tipo di macchina selezionato. Ti viene addebitato il costo di ogni vCPU, indipendentemente dal fatto che tu attivi o disattivi SMT. Per ulteriori informazioni, consulta i prezzi quando modifichi il numero di thread per core. Per modificare l'impostazione SMT, esegui una delle seguenti operazioni:

    • Imposta il flag --threads-per-core quando crei un pool di nodi GKE Sandbox che utilizza gVisor:

      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.

    • Utilizza un DaemonSet per attivare SMT su un pool di nodi esistente:

      1. Aggiungi l'etichetta del nodo cloud.google.com/gke-smt-disabled=false a un pool di nodi esistente che utilizza gVisor:

        gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --node-labels=cloud.google.com/gke-smt-disabled=false

        Sostituisci quanto segue:

        • NODE_POOL_NAME: il nome del pool di nodi esistente.
        • 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.

      2. Esegui il deployment di DaemonSet. 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.yaml

      3. Assicurati che i pod DaemonSet siano in stato di 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

      4. Verifica che SMT has been enabled venga visualizzato nei log dei pod:

        kubectl logs enable-smt-2xnnc enable-smt -n kube-system

    Funzionalità

    Applicabile ai cluster Standard

    Per impostazione predefinita, al container viene impedito di aprire socket non elaborati per ridurre il potenziale di attacchi dannosi. Alcuni strumenti correlati alla rete, come ping e tcpdump, creano socket non elaborati nell'ambito del loro funzionamento principale. Per attivare i raw socket, 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 di 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 vengono eseguiti al di fuori del limite della sandbox e devono essere protetti singolarmente. Un malintenzionato 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 privilegiato all'host e ai servizi. Un exploit in 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 Compute Engine Persistent Disk.

    Funzionalità incompatibili

    A GKE Sandbox si applicano le seguenti limitazioni delle funzionalità:

    • Si applicano le seguenti limitazioni sia alle sandbox gVisor che alle microVM:

    • Le seguenti limitazioni si applicano solo alle sandbox gVisor:

    • Le seguenti limitazioni si applicano solo alle sandbox microVM:

      • I pod che utilizzano l'impostazione hostNetwork: true non sono supportati. I pod che vengono eseguiti in un sandbox microVM e utilizzano l'impostazione hostNetwork: true non possono accedere a risorse esterne al pod.
      • Qualsiasi strumento di diagnostica che si basa sul tracciamento a livello di socket può accedere solo alle interfacce di rete collegate alla microVM.

    Passaggi successivi