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 di Software as a Service (SaaS), spesso eseguono codice sconosciuto inviato dai loro utenti. GKE Sandbox è anche un'utile misura di difesa in profondità per l'esecuzione di container di alto valore.

Questa pagina è dedicata agli esperti di sicurezza che vogliono scoprire i vantaggi di GKE Sandbox. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE Enterprise.

Prima di leggere questa pagina, assicurati di conoscere la documentazione ufficiale di gVisor, il progetto open source utilizzato da GKE Sandbox.

Per istruzioni su come attivare 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 di come funziona 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 privilegiato 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 a vulnerabilità di sicurezza rispetto ad altri cluster. Alcuni esempi includono fornitori di SaaS, fornitori di hosting web 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 acceda ed esfiltri i dati di un altro tenant in memoria o su disco sfruttando un difetto di questo tipo.

Infine, un workload non attendibile potrebbe potenzialmente accedere ad altri servizi o ai metadati del cluster. Google Cloud

In che modo GKE Sandbox mitiga le potenziali minacce

gVisor è una reimplementazione userspace dell'API del kernel Linux che non richiede privilegi elevati. In combinazione con un runtime del container come containerd , il kernel userspace implementa nuovamente la maggior parte delle chiamate di sistema e le gestisce per conto del kernel host. L'accesso diretto al kernel 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 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 aspetto, puoi decidere come raggruppare i container in pod in base al livello di isolamento richiesto e alle caratteristiche delle tue applicazioni.

GKE Sandbox è particolarmente adatto ai seguenti tipi di applicazioni. Per ulteriori informazioni che ti aiutino a decidere quali applicazioni inserire nella sandbox, consulta la sezione Limitazioni.

  • Applicazioni di terze parti o non attendibili che utilizzano runtime come Rust, Java, Python, PHP, Node.js o Golang
  • Frontend, cache o proxy del server web
  • Applicazioni che elaborano dati o contenuti multimediali esterni utilizzando le CPU
  • Carichi di lavoro di machine learning che utilizzano CPU
  • Applicazioni che utilizzano molta CPU o memoria

I servizi o i workload di 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 il tuo livello di sicurezza per i carichi di lavoro che utilizzano in modo intensivo GPU e TPU senza apportare modifiche significative al codice. I casi d'uso chiave in cui GKE Sandbox si adatta bene sono comuni ai workload AI/ML:

  • Workload che richiedono un uso intensivo di GPU e TPU.
  • Servizi che accettano ed eseguono codice utente non attendibile.
  • Servizi che elaborano input utente arbitrari.
  • Workload che elaborano grandi set di dati e modelli di terze parti.
  • Applicazioni che utilizzano librerie di terze parti.

Scopri di più sulla progettazione e sulla sicurezza dell'accesso agli acceleratori nelle guide a GPU e TPU di gVisor.

Altri consigli 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 ambiente sandbox. In questo modo si evita il 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 viene protetto dal rischio che un'applicazione malicious acceda a informazioni potenzialmente private come ID progetto, nome del nodo e zona. Workload Identity Federation for 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 limitazioni attuali 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.

I carichi di lavoro con accelerazione hardware in GKE Sandbox sono disponibili a livello generale nelle seguenti versioni:

  • 1.29.15-gke.1134000
  • 1.30.11-gke.1093000
  • 1.31.7-gke.1149000
  • 1.32.2-gke.1182003 e versioni successive

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

Si applicano le seguenti limitazioni ai carichi di lavoro GPU in 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.
  • gVisor supporta solo alcune versioni dei driver NVIDIA. GKE Sandbox garantisce che sia il latest sia il driver default per ogni GPU supportata per ogni versione di GKE siano compatibili. Non è garantito il funzionamento di altri driver.
  • 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 in GitHub Issues di gVisor.

Puoi utilizzare GKE Sandbox con i carichi di lavoro GPU senza costi aggiuntivi.

TPU in GKE Sandbox

In GKE 1.31.3-gke.1111001 e versioni successive, GKE Sandbox supporta l'utilizzo delle 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 TPU.

Sono supportate le seguenti versioni hardware di 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 nei pool di nodi 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 che utilizzano 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 è disattivato. Questo pool di nodi deve contenere almeno un nodo, anche se tutti i tuoi workload 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. 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 in sandbox non possono accedere ai metadati del cluster a livello di sistema operativo sul nodo.
  • In GKE Standard, puoi eseguire pod regolari su un nodo con GKE Sandbox abilitato. Tuttavia, per impostazione predefinita questi pod regolari non possono accedere Google Cloud ai servizi o ai metadati del cluster.
  • Utilizza Workload Identity Federation for 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 lo stato del core di condivisione dei thread, ad esempio le vulnerabilità di Microarchitectural Data Sampling (MDS).

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

A partire dalla versione 1.24.2-gke.300 di GKE, SMT viene configurato in base al tipo di macchina in base alla vulnerabilità della macchina a MDS, come segue:

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

  • Tipi di macchine con processori Intel: SMT disattivato 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 è disattivato su tutti i tipi di macchine.

Abilita SMT

Si applica ai cluster Standard

Nei cluster GKE Standard, puoi attivare SMT se è disattivato nel tipo di macchina selezionato. Ti viene addebitato il costo di ogni vCPU, indipendentemente dal fatto che tu attivi SMT o lo mantenga disattivato. Per informazioni sui prezzi, consulta la pagina Prezzi di Compute Engine.

GKE 1.24.2-gke.300 e versioni successive

Imposta il flag --threads-per-core quando crei unpool di nodil 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 tuo 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 sul pool di nodi. Il 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. Verifica 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. Controlla che SMT has been enabled compaia 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 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 della loro operazione principale. Per abilitare i socket non elaborati, devi aggiungere esplicitamente la funzionalità NET_RAW al contesto di sicurezza del contenitore:

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 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 workload

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 grandi cluster multi-tenant 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 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 nodi aggiuntivi 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 una soluzione adatta 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