GKE Sandbox

Questa pagina descrive in che modo GKE Sandbox protegge il kernel host sui tuoi 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.

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 Configurare 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 del contenitore come containerd fornisce un certo grado di isolamento tra i processi del contenitore e il kernel in esecuzione sul nodo. Tuttavia, il runtime del contenitore viene spesso eseguito come utente privilegiato sul nodo e 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ù esposto alle vulnerabilità di sicurezza rispetto ad altri cluster. Alcuni esempi sono fornitori di SaaS, fornitori di servizi di hosting web o altre organizzazioni che consentono ai propri utenti di caricare ed eseguire 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 interessano il kernel del nodo, portandolo potenzialmente in stato di inattività.

Esiste anche la possibilità che un tenant malintenzionato acceda ai dati di un altro tenant in memoria o su disco e li esfiltri sfruttando questo difetto.

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 mitiga 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. L'accesso diretto al kernel dell'host è limitato. Consulta le Guida all'architettura di gVisor per informazioni dettagliate su come funziona. Dal punto di vista del contenitore, gVisor è quasi trasparente e non richiede modifiche all'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 nello 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 per i seguenti tipi di applicazioni. Per ulteriori informazioni su come decidere quali applicazioni inserire nella 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 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. In questo modo si evita il rischio che un'applicazione difettosa o dannosa prosciughi le risorse del nodo 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 Network Policy per bloccare l'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 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

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 conserva 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 all'assistenza 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 i 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 attivare 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 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 in 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 regolari 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 del multi-threading simultaneo (SMT) vengono utilizzate per mitigare le vulnerabilità dei canali laterali che sfruttano i thread che condividono lo stato del core, ad esempio le vulnerabilità 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 ai valori predefiniti. La pianificazione Nucleo 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 agli attacchi MDS, come segue:

  • Pod Autopilot in esecuzione sulla Scale-Out classe di calcolo: SMT disabilitato.

  • Tipi di macchina 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 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 attivare 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 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 tuo cluster con l'etichetta nodocloud.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 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. Controlla che SMT has been enabled venga visualizzato 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 vengono eseguiti al di fuori del confine della sandbox e devono essere protetti singolarmente. Un aggressore può tentare di sfruttare le vulnerabilità in questi per uscire dalla sandbox. Devi valutare il rischio e l'impatto dell'eventuale raggiungibilità di questi servizi da parte del 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 contenitori, come i driver ext4 e 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 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 il vantaggio più tangibile per i 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 gran numero di piccole operazioni di I/O, possono richiedere più risorse di sistema quando vengono eseguiti in una sandbox, pertanto 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 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