GKE Sandbox

Questa pagina descrive in che modo GKE Sandbox protegge il kernel dell'host quando i container nel pod eseguono codice sconosciuto o non attendibile. Per un esempio, cluster multi-tenant come i provider SaaS (Software-as-a-Service) spesso eseguono codice sconosciuto inviate dai loro utenti. GKE Sandbox è anche un'utile difesa in profondità misura l'esecuzione di container di alto valore.

GKE Sandbox utilizza gVisor, un progetto open source. Questo argomento parla ampiamente di gVisor, ma puoi trovare maggiori dettagli leggendo l' documentazione ufficiale di gVisor.

Per istruzioni su come abilitare e utilizzare GKE Sandbox, consulta Configura GKE Sandbox.

Panoramica

GKE Sandbox fornisce un ulteriore livello di sicurezza per prevenire codice non attendibile influisca sul kernel dell'host sui nodi del cluster. Prima di discutere di come GKE Sandbox funziona, è utile comprendere la natura del potenziale e i rischi che aiuta a mitigare.

Un runtime container come containerd fornisce un certo grado di e l'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 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 più esposti alle vulnerabilità di sicurezza rispetto ad altri cluster. Ecco alcuni esempi: Provider SaaS, provider di web hosting o altre organizzazioni che consentano agli utenti di caricare ed eseguire il codice. Un difetto nel runtime del container o nell'host kernel potrebbe consentire a un processo in esecuzione all'interno di un container di "escape" il del container e influire sul kernel del nodo, portandolo potenzialmente in stato di inattività.

Esiste anche la possibilità che un tenant dannoso possa accedere a e esfiltrare i dati di un altro tenant in memoria o su disco, sfruttando tale difettoso.

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

In che modo GKE Sandbox attenua queste minacce

gVisor è una reimplementazione dello spazio utente dell'API del kernel Linux che non richiedono privilegi elevati. In combinazione con un runtime container come containerd , il kernel dello spazio utente reimplementa la maggior parte delle chiamate di sistema e li gestisce per conto del kernel dell'host. Accesso diretto al kernel dell'host è limitato. Consulta le Guida all'architettura di gVisor per informazioni dettagliate su come funziona. Dal punto del container vista, gVisor è quasi trasparente e non richiede alcuna modifica in un'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, su tutti i pod in esecuzione i nodi vengono eseguiti in sandbox.

Ogni sandbox utilizza il proprio kernel dello spazio utente. Tenendo conto di questo, puoi rendere su come raggruppare i container nei pod, in base al livello l'isolamento richiesto e le caratteristiche delle applicazioni.

GKE Sandbox è particolarmente adatto ai seguenti tipi di diverse applicazioni. Leggi la sezione Limitazioni per avere maggiori informazioni decidere quali applicazioni limitare tramite 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 queste raccomandazioni:

  • Specifica limiti delle risorse in tutti i container in esecuzione in una sandbox. Questo meccanismo protegge dal rischio di un'applicazione difettosa o dannosa che esaurisce il nodo di risorse dando un impatto negativo su altre applicazioni o altri processi di sistema in esecuzione sul nodo.

  • Se utilizzi Federazione delle identità per i carichi di lavoro per GKE, per bloccare l'accesso ai metadati del cluster Criterio di rete per bloccare accesso a 169.254.169.254. Questo meccanismo protegge dal rischio di attacchi un'applicazione che accede alle informazioni a dati potenzialmente privati come ID progetto, il nome del nodo e la zona. La federazione delle identità per i carichi di lavoro per GKE è sempre abilitata in GKE Autopilot.

Limitazioni

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

GPU in GKE Sandbox

In GKE versione 1.29.2-gke.1108000 e successive, GKE Sandbox supporta l'uso delle GPU NVIDIA.

GKE Sandbox non mitiga tutte le vulnerabilità dei driver NVIDIA, ma conserva la protezione dalle vulnerabilità del kernel Linux. Per maggiori dettagli su in che modo il progetto gVisor protegge i carichi di lavoro GPU, vedi Guida di assistenza per le GPU

Le seguenti limitazioni si applicano ai carichi di lavoro GPU all'interno di GKE Sandbox:

  • Solo la versione del driver NVIDIA latest su una determinata versione di GKE è supportato. I cluster Autopilot installano automaticamente il 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 sul pool di nodi predefinito per separare il sistema di servizi in esecuzione nel pool di nodi predefinito da 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 sandbox.
  • Le versioni GKE precedenti alla 1.24.2-gke.300 non supportano Tipi di macchine e2-micro, e2-small ed e2-medium. Versione GKE La versione 1.24.2-gke.300 e successive supporta questi tipi di macchina.
  • 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 il 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à dei carichi di lavoro per GKE per 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 limitare il numero di le vulnerabilità che sfruttano i thread che condividono lo stato principale, come Vulnerabilità del Microarchitectural Data Sampling (MDS).

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

A partire da GKE versione 1.24.2-gke.300, SMT è configurato di tipo di macchina in base alla vulnerabilità della macchina nei confronti di MDS, come segue:

  • Autopilot in esecuzione Classe di computing Scale-Out: SMT disattivato.

  • Tipi di macchina con processori Intel: SMT disattivato 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 richieste vCPU 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 addebitate ogni vCPU, indipendentemente dal fatto che SMT sia attivato o meno. Per i prezzi informazioni, fai riferimento Prezzi di Compute Engine.

GKE 1.24.2-gke.300 e versioni successive

Imposta il flag --threads-per-core quando creando 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 ulteriori informazioni su --threads-per-core, consulta Imposta 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. Esegui il deployment del DaemonSet nel pool di nodi. Il DaemonSet viene eseguito solo su 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 non è consentito aprire 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 attivare socket non elaborati, devi aggiungere esplicitamente la funzionalità NET_RAW contesto di sicurezza del container:

spec:
  containers:
  - name: my-container
    securityContext:
      capabilities:
        add: ["NET_RAW"]

Se usi GKE Autopilot, Google Cloud ti impedisce aggiungendo l'autorizzazione NET_RAW ai container per motivi di sicurezza implicazioni 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 indirizzi esterni come server di database, API, altri container e CSI driver. Questi servizi sono in esecuzione al di fuori dei confini della sandbox e devono essere protetti singolarmente. Un utente malintenzionato può tentare di sfruttare le vulnerabilità in questi per uscire dalla sandbox. Devi considerare il rischio e l’impatto essere raggiungibili dal codice in esecuzione all'interno della sandbox e si applicano le misure necessarie per proteggerli.

Ciò include implementazioni di file system per volumi di container come ext4 e Driver CSI. I driver CSI vengono eseguiti al di fuori dell'isolamento sandbox e potrebbero l'accesso privilegiato all'host e ai servizi. Un exploit in questi fattori può influenzano il kernel dell'host e compromettono l'intero nodo. Ti consigliamo di eseguire il driver CSI all'interno di un container con la quantità minima di autorizzazioni richiesta, per ridurre l'esposizione in caso di exploit. GKE Sandbox supporta l'utilizzo Driver CSI per il disco permanente di Compute Engine.

Funzionalità incompatibili

Non puoi utilizzare GKE Sandbox con le seguenti funzionalità di Kubernetes:

Caratteristiche del carico di lavoro

Si applica ai cluster Autopilot e Standard

Imposizione di un livello aggiuntivo di indiretta per l'accesso al kernel del nodo comporta dei compromessi in termini di prestazioni. GKE Sandbox offre la soluzione e offre vantaggi specifici sui cluster multi-tenant di grandi dimensioni in cui l'isolamento è importante. Mantieni il valore le linee guida seguenti quando testi i tuoi carichi di lavoro con GKE Sandbox.

Chiamate di sistema

Si applica ai cluster Autopilot e Standard

Carichi di lavoro che generano un volume elevato di chiamate di sistema a basso overhead, come di operazioni di I/O di piccole dimensioni, potrebbero richiedere più risorse di sistema in esecuzione in una sandbox, quindi potresti dover utilizzare nodi più potenti o aggiungere nodi aggiuntivi 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 è 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