GKE Sandbox

Questa pagina descrive in che modo GKE Sandbox protegge il kernel 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 è un'utile 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 di più consultando 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 contribuisce 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 spesso viene 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 e i cluster multi-tenant i cui container eseguono carichi di lavoro non attendibili sono più esposti alle vulnerabilità della sicurezza rispetto ad altri cluster. Alcuni esempi sono i fornitori SaaS, i provider 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 eseguire l'escape del container e influire sul kernel del nodo, con la possibilità di arrestare il nodo.

Esiste anche la possibilità che un tenant dannoso possa accedere ai dati di un altro tenant in memoria o su disco ed esfiltrarli sfruttando questo difetto.

Infine, un carico di lavoro non attendibile potrebbe accedere ad altri servizi Google Cloud o metadati del cluster.

In che modo GKE Sandbox attenua queste minacce

gVisor è una reimplementazione dello spazio utente dell'API kernel Linux che non richiede privilegi elevati. Insieme a un runtime del container come containerd , il kernel dello spazio utente reimplementa la maggior parte delle chiamate di sistema e le gestisce per conto del kernel host. L'accesso diretto al kernel dell'host è limitato. Consulta la guida all'architettura gVisor per informazioni dettagliate su come funziona. Dal punto di vista del container, gVisor è quasi trasparente e non richiede modifiche all'applicazione containerizzata.

Quando richiedi GKE Sandbox in un pod in cluster Autopilot, GKE esegue quel 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 prendere decisioni su come raggruppare i container in 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 su come decidere quali applicazioni applicare la sandbox, consulta la sezione 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 di server web
  • Applicazioni che elaborano dati o supporti esterni utilizzando le CPU
  • Carichi di lavoro di machine learning con CPU
  • Applicazioni che consumano molta CPU o memoria
  • Carichi di lavoro ad alta intensità di GPU

Ulteriori consigli per la sicurezza

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

  • Specifica i limiti delle risorse su tutti i container in esecuzione in una sandbox. In questo modo, è possibile proteggere dal rischio che un'applicazione difettosa o dannosa elimini il nodo di risorse e abbia un impatto negativo su altre applicazioni o processi di sistema in esecuzione sul nodo.

  • Se utilizzi Workload Identity Federation per GKE, blocca l'accesso ai metadati del cluster utilizzando il Criterio di rete per bloccare l'accesso a 169.254.169.254. Ciò protegge dal rischio che un'applicazione dannosa acceda a informazioni a dati potenzialmente privati come l'ID progetto, il nome del nodo e la zona. La federazione di Workload Identity per GKE è sempre abilitata nei cluster GKE Autopilot.

Limitazioni

GKE Sandbox funziona bene con molte applicazioni, ma non tutte. Questa sezione fornisce ulteriori informazioni sulle attuali limitazioni di GKE Sandbox.

GPU in GKE Sandbox

In GKE 1.29.2-gke.1108000 e versioni successive, GKE Sandbox supporta l'utilizzo di GPU NVIDIA.

GKE Sandbox non mitiga tutte le vulnerabilità dei driver NVIDIA, ma mantiene la protezione contro le vulnerabilità del kernel Linux. Per dettagli su come il progetto gVisor protegge i carichi di lavoro delle GPU, consulta la Guida al supporto delle GPU.

Le seguenti limitazioni si applicano ai carichi di lavoro delle GPU in 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-80gb, nvidia-l4 e nvidia-h100-80gb.

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 nel 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 tuo 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 di GKE precedenti alla 1.24.2-gke.300 non supportano i tipi di macchina e2-micro, e2-small ed e2-medium. GKE versione 1.24.2-gke.300 e successive supporta questi tipi di macchine.
  • I nodi devono utilizzare l'immagine del nodo Container-Optimized OS with containerd (cos_containerd).

Accesso ai metadati del cluster

Si applica ai cluster Autopilot e Standard

  • Ai nodi che eseguono pod con sandbox viene impedito l'accesso ai metadati del cluster a livello di sistema operativo sul nodo.
  • In GKE Standard, puoi eseguire pod normali su un nodo in cui è abilitata GKE Sandbox. ma per impostazione predefinita non possono accedere ai servizi Google Cloud o ai metadati dei cluster.
  • Utilizza Workload Identity Federation per GKE per concedere ai pod l'accesso ai servizi Google Cloud.

La funzionalità SMT potrebbe essere disattivata

Si applica ai cluster Autopilot e Standard

Le impostazioni SMT (multi-threading) simultanei vengono utilizzate per mitigare le vulnerabilità dei canali secondari che sfruttano lo stato principale dei thread che condividono lo stato principale, ad esempio le vulnerabilità del Microarchitectural Data Sampling (MDS).

Nelle versioni di GKE 1.25.5-gke.2500 o successive e 1.26.0-gke.2500 o successive, gVisor è configurato per utilizzare la Linux Core Scheduling per mitigare gli attacchi sul canale laterale. Le impostazioni SMT non sono state modificate rispetto a quelle predefinite. La pianificazione base viene utilizzata solo per i carichi di lavoro eseguiti con gVisor.

A partire dalla versione 1.24.2-gke.300 di GKE, la strategia SMT è configurata per tipo di macchina in base alla vulnerabilità della macchina a MDS, come segue:

  • Pod Autopilot in esecuzione sulla classe di computing Scale-Out: SMT disabilitata.

  • Tipi di macchine con processori Intel: SMT disabilitata per impostazione predefinita.

  • Tipi di macchina senza processori Intel: SMT abilitata 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, la funzionalità SMT è disabilitata su tutti i tipi di macchina.

Abilita SMT

Si applica ai cluster standard

Nei cluster GKE Standard, puoi abilitare SMT se è disabilitata sul tipo di macchina selezionato. Ti viene addebitata ogni vCPU, indipendentemente dal fatto che la funzionalità SMT sia attivata o disattivata. Per informazioni sui prezzi, consulta la pagina Prezzi di Compute Engine.

GKE versione 1.24.2-gke.300 e successive

Imposta il flag --threads-per-core durante la creazione di un pool di nodi di 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 Impostare il numero di thread per core.

Versioni di GKE precedenti alla 1.24.2-gke.300

  1. 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

  2. Eseguire 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

  3. 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

  4. 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 viene impedito l'apertura di socket non elaborati, per ridurre il potenziale 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 eseguito 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 confine della sandbox e devono essere protetti singolarmente. Un utente malintenzionato può tentare di sfruttare le vulnerabilità in questi servizi per uscire dalla sandbox. Devi considerare il rischio e l'impatto che questi servizi sono raggiungibili dal codice in esecuzione all'interno della sandbox e applicare le misure necessarie per proteggerli.

Ciò include le implementazioni di file system per volumi di container come i driver ext4 e CSI. I driver CSI vengono eseguiti al di fuori dell'isolamento 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 il numero minimo 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:

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 dei compromessi in termini di prestazioni. GKE Sandbox offre i vantaggi più tangibili per cluster multi-tenant di grandi dimensioni, dove 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 costo, ad esempio un numero elevato di operazioni di I/O ridotte, potrebbero richiedere più risorse di sistema quando vengono eseguite in una sandbox, quindi potresti dover 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 una delle seguenti condizioni, GKE Sandbox potrebbe non essere una soluzione adatta, 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