GKE Sandbox

Questa pagina descrive come GKE Sandbox protegge il kernel host sui nostri quando i container nel pod eseguono codice sconosciuto o non attendibile. Ad esempio, cluster multi-tenant come provider SaaS (Software as a Service) spesso eseguono codice sconosciuto inviato dai loro utenti.

GKE Sandbox utilizza gVisor, un progetto open source. Questo argomento tratta approfonditamente gVisor, ma puoi scoprire ulteriori dettagli leggendo la documentazione ufficiale di gVisor.

Per informazioni dettagliate su come abilitare la sandbox di GKE, consulta Configurare la sandbox di GKE.

Panoramica

GKE Sandbox fornisce un ulteriore livello di sicurezza per impedire che codice non attendibile influisca sul kernel host sui nodi del cluster. Prima di discutere del funzionamento di 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 spesso viene eseguito come utente con privilegi sul nodo e ha accesso alla maggior parte delle chiamate di sistema nel kernel host.

Potenziali minacce

I cluster multi-tenant e i cluster i cui container eseguono carichi di lavoro non attendibili sono più esposti alle vulnerabilità di sicurezza rispetto ad altri cluster. Alcuni esempi includono provider SaaS, provider host web o altre organizzazioni che consentono ai loro utenti di caricare ed eseguire codice. Un difetto nel runtime del container o nel kernel dell'host potrebbe consentire il processo in esecuzione all'interno del container per "escape" e il container; inoltre, può influire sul kernel del nodo, causando potenzialmente la discesa del nodo.

Il potenziale esiste anche per consentire a un tenant dannoso di accedere ai dati di un altro tenant ed esfiltrarli in memoria o su disco, sfruttando tale difetto.

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

In che modo GKE Sandbox riduce le minacce

gVisor è una reimplementazione dello spazio utente dell'API del 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 esegue 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 alcuna modifica all'applicazione containerizzata.

Quando abiliti Sandbox GKE su un pool di nodi, viene creata una sandbox per ogni pod in esecuzione su un nodo nel pool. Inoltre, ai nodi che eseguono pod sandbox viene impedito l'accesso ad altri servizi Google Cloud o ai metadati del cluster.

Ogni sandbox utilizza il proprio kernel dello spazio utente. Tenendo conto di ciò, 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 è una soluzione particolarmente adatta per i seguenti tipi di applicazioni. Consulta le Limitazioni per ulteriori informazioni su come decidere quali applicazioni applicare alla sandbox.

  • Applicazioni non attendibili o di terze parti che utilizzano runtime quali Rust, Java, Python, PHP, Node.js o Golang
  • Frontend, cache o proxy di server web
  • Applicazioni che elaborano dati o supporti esterni utilizzando le CPU
  • Carichi di lavoro di machine learning che utilizzano CPU
  • Applicazioni che richiedono un elevato utilizzo della memoria o della CPU

Ulteriori consigli per la sicurezza

Se usi GKE Sandbox, ti consigliamo di seguire anche questi consigli:

  • Specifica i limiti delle risorse per tutti i container in esecuzione in una sandbox. Questo ti protegge dal rischio che un'applicazione difettosa o dannosa blocchi il nodo delle risorse e abbia un impatto negativo su altre applicazioni o processi di sistema in esecuzione sul nodo.

  • Se utilizzi Workload Identity, blocca l'accesso ai metadati del cluster tramite criteri di rete per bloccare l'accesso a 169.254.169.254. Protegge il rischio che un'applicazione dannosa possa accedere alle informazioni su dati potenzialmente privati come ID progetto, nome nodo e zona.

Limitazioni

GKE Sandbox è adatto a molte applicazioni, ma non a tutte. Questa sezione fornisce ulteriori informazioni sulle limitazioni attuali di GKE Sandbox.

Configurazione del pool di nodi

  • Non puoi utilizzare GKE Sandbox sui pool di nodi Windows Server.
  • Non puoi abilitare GKE Sandbox sul pool di nodi predefinito.
  • 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 tuoi carichi di lavoro sono sandbox.
  • I pool di nodi non possono utilizzare tipi di macchine e2-micro, e2-small e e2-medium.
  • I nodi devono utilizzare l'immagine del nodo Container-Optimized OS with containerd (cos_containerd).

Accesso ai metadati del cluster

  • I nodi che eseguono pod con sandbox non possono accedere ai metadati del cluster a livello del sistema operativo sul nodo.
  • Puoi eseguire pod regolari su un nodo con GKE Sandbox abilitato. Tuttavia, per impostazione predefinita, i normali pod non possono accedere ai servizi Google Cloud o ai metadati del cluster.
  • Utilizza Workload Identity per concedere ai pod l'accesso ai servizi Google Cloud.

Hyper-Threading non attivo

Nei nodi gVisor, la funzionalità Hyper-Threading è disabilitata per impostazione predefinita su tutte le architetture per ridurre le vulnerabilità dei canali laterali che sfruttano lo stato dei core condivisi tra gli hyper-thread, come ad esempio le vulnerabilità di microarchitettura del campionamento dei dati (STEM). Per abilitare la funzionalità Hyper-Threading per un pool di nodi, procedi nel seguente modo:

  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

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster esistente.
    • MACHINE_TYPE: il tipo di macchina.

  2. Esegui il deployment del DaemonSet nel pool di nodi. L'oggetto DaemonSet verrà eseguito solo sui nodi con l'etichetta cloud.google.com/gke-smt-disabled=false. Verrà abilitato Hyper-Threading e quindi riavviato il nodo.

    kubectl create -f \
    https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yaml

  3. Dopo il riavvio del nodo, assicurati che i pod 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 venga visualizzato nei log dei pod.

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

Competenze

Per impostazione predefinita, il container non riesce ad aprire socket non elaborati, per ridurre il potenziale per attacchi dannosi. Alcuni strumenti relativi alla rete, come ping e tcpdump, creano socket non elaborati come parte della loro funzionalità principale. 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"]

Dipendenze esterne

Potrebbe essere consentito il codice non attendibile in esecuzione all'interno della sandbox per raggiungere servizi esterni quali server di database, API, altri container e driver CSI. Questi servizi vengono eseguiti al di fuori del confine della sandbox e devono essere protetti individualmente. Un utente malintenzionato può tentare di sfruttare le vulnerabilità in questi servizi per uscire dalla sandbox. Devi considerare il rischio e l'impatto di questi servizi affinché siano 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 i driver ext4 e CSI. I driver CSI vengono eseguiti all'esterno dell'isolamento sandbox e possono 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 minor numero di autorizzazioni necessarie, per ridurre l'esposizione in caso di exploit. GKE Sandbox supporta l'utilizzo del driver CSI per il disco permanente di Compute Engine.

Funzionalità incompatibili

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

  • Acceleratori come GPU o TPU
  • Monitoraggio delle statistiche a livello di pod o container
  • Archiviazione hostpath
  • I limiti di CPU e memoria vengono applicati solo ai pod garantiti e ai pod di burstable e solo quando i limiti di CPU e memoria sono specificati per tutti i container in esecuzione nel pod.

  • Pod che utilizzano PodSecurityPolicies che specificano gli spazi dei nomi host, come hostNetwork, hostPID, hostIPC

  • Pod che utilizzano le impostazioni di PodSecurityPolicy come la modalità con privilegi

  • VolumeVolume

  • Portforward

  • Moduli di sicurezza per kernel Linux come Seccomp, Apparmor o Selinux, Sysctl, NoNewPrivileges, Bidirectional MountPropagation o ProcMount.

  • Traffic Director

  • Istio è supportato solo sui cluster che eseguono GKE versione 1.18.6-gke.4801 e successive.

  • FSGroup è supportato in GKE versione 1.22 e successive.

Caratteristiche del carico di lavoro

L'imposizione di un ulteriore livello di indirezione per l'accesso al kernel del nodo presenta dei compromessi in termini di prestazioni. GKE Sandbox offre il vantaggio più tangibile per i cluster multi-tenant di grandi dimensioni, dove l'isolamento è importante. Durante il test dei carichi di lavoro con GKE Sandbox, tieni presente le seguenti linee guida.

Chiamate di sistema

I carichi di lavoro che generano un volume elevato di chiamate di sistema a basso sovraccarico, come un numero elevato di operazioni I/O di piccole dimensioni, potrebbero richiedere più risorse di sistema quando sono in esecuzione in una sandbox, quindi potrebbe essere necessario utilizzare nodi più potenti o aggiungere nodi aggiuntivi al cluster.

Accesso diretto a hardware o virtualizzazione

Se il tuo carico di lavoro richiede uno dei seguenti elementi, GKE Sandbox potrebbe non essere ideale 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