Protezione dell'isolamento del carico di lavoro con GKE Sandbox

Autopilot Standard

---

Questa pagina descrive come utilizzare GKE Sandbox per proteggere il kernel host sui nodi quando i container nel pod eseguono codice sconosciuto o non attendibile o necessitano di un ulteriore isolamento dal nodo.

Disponibilità di GKE Sandbox

GKE Sandbox è pronto per l'uso nei cluster Autopilot che eseguono GKE versione 1.27.4-gke.800 e successive. Per iniziare a eseguire il deployment dei carichi di lavoro Autopilot in una sandbox, passa a Utilizzo di GKE Sandbox.

Per utilizzare GKE Sandbox in cluster GKE Standard nuovi o esistenti, devi abilitare manualmente GKE Sandbox sul cluster.

I carichi di lavoro GPU sono disponibili in Anteprima in GKE Sandbox nella versione 1.29.2-gke.11080000 e successive.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installa e quindi initialize gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti località predefinite, puoi evitare errori in gcloud CLI, come quelli che seguono: One of [--zone, --region] must be supplied: Please specify location.

Abilita GKE Sandbox su un nuovo cluster Standard

Il pool di nodi predefinito, che viene creato quando crei un nuovo cluster, non può utilizzare GKE Sandbox se è l'unico pool di nodi nel cluster, perché i carichi di lavoro di sistema gestiti da GKE devono essere eseguiti separatamente da quelli non attendibili nella sandbox. Per abilitare GKE Sandbox durante la creazione del cluster, devi aggiungere almeno un pool di nodi aggiuntivo al cluster.

Console

Per visualizzare i cluster, vai al menu Google Kubernetes Engine nella console Google Cloud.

1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

   Vai a Google Kubernetes Engine

2. Fai clic su Crea.

3. Facoltativo, ma consigliato: nel menu di navigazione, in Cluster, fai clic su Funzionalità e seleziona le seguenti caselle di controllo in modo che i messaggi di gVisor vengano registrati:

   • Cloud Logging
   • Cloud Monitoring
   • Managed Service per Prometheus

4. Fai clic su Aggiungi pool di nodi.

5. Dal menu di navigazione, in Pool di nodi, espandi il nuovo pool di nodi e fai clic su Nodi.

6. Configura le seguenti impostazioni per il pool di nodi:

   1. Nell'elenco a discesa Tipo di immagine, seleziona Container-Optimized OS con Containerd (cos_containerd). Questo è l'unico tipo di immagine supportato per GKE Sandbox.
   2. In Configurazione macchina, seleziona un Serie e un Tipo di macchina.

   3. Facoltativamente, se esegui una versione GKE supportata, seleziona un tipo di GPU. Deve essere uno dei seguenti tipi:

      • nvidia-tesla-t4
      • nvidia-tesla-a100
      • nvidia-a100-80gb
      • nvidia-l4
      • nvidia-h100-80gb

      Le GPU in GKE Sandbox sono disponibili in anteprima.

   4. Se utilizzi GPU su GKE Sandbox (anteprima), seleziona o installa la variante del driver latest.

7. Dal menu di navigazione, sotto il nome del pool di nodi che stai configurando, fai clic su Sicurezza e seleziona la casella di controllo Attiva sandbox con gVisor.

8. Continua a configurare il cluster e i pool di nodi in base alle esigenze.

9. Fai clic su Crea.

gcloud

Non è possibile abilitare GKE Sandbox per il pool di nodi predefinito e non è possibile creare pool di nodi aggiuntivi nello stesso momento in cui crei un nuovo cluster con il comando gcloud. Crea invece il cluster come faresti normalmente. Sebbene facoltativo, ti consigliamo di abilitare Logging e Monitoring in modo che i messaggi di gVisor vengano registrati.

Quindi, usa il comando gcloud container node-pools create e imposta il flag -- sandbox su type=gvisor. Il tipo di immagine del nodo deve essere cos_containerd per GKE Sandbox.

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Sostituisci le seguenti variabili:

• NODE_POOL_NAME: il nome del nuovo pool di nodi.
• CLUSTER_NAME: il nome del tuo cluster.
• NODE_VERSION: la versione da utilizzare per il pool di nodi.
• MACHINE_TYPE: il tipo di macchina da utilizzare per i nodi.

Anteprima - GPUs in GKE Sandbox

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Per creare un pool di nodi GPU con GKE Sandbox, esegui questo comando:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --accelerator=type=GPU_TYPE,gpu-driver-version=latest \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Sostituisci quanto segue:

• GPU_TYPE: un tipo di GPU supportato. Per maggiori dettagli, consulta GKE Sandbox.

• MACHINE_TYPE: una macchina corrispondente al tipo di GPU richiesto. Per maggiori dettagli, consulta Requisiti GPU di Google Kubernetes Engine.

Abilita GKE Sandbox su un cluster Standard esistente

Puoi abilitare GKE Sandbox su un cluster Standard esistente aggiungendo un nuovo pool di nodi e abilitando la funzionalità per quel pool di nodi.

Console

Per creare un nuovo pool di nodi con GKE Sandbox abilitata:

1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

   Vai a Google Kubernetes Engine

2. Fai clic sul nome del cluster da modificare.

3. Fai clic su Aggiungi pool di nodi.

4. Configura la pagina Dettagli del pool di nodi selezionata.

5. Nel menu di navigazione, fai clic su Nodi e configura le seguenti impostazioni:

   1. Nell'elenco a discesa Tipo di immagine, seleziona Container-Optimized OS con Containerd (cos_containerd). Questo è l'unico tipo di immagine supportato per GKE Sandbox.
   2. In Configurazione macchina, seleziona un Serie e un Tipo di macchina.

   3. Facoltativamente, se esegui una versione GKE supportata, seleziona un tipo di GPU. Deve essere uno dei seguenti tipi:

      • nvidia-tesla-t4
      • nvidia-tesla-a100
      • nvidia-a100-80gb
      • nvidia-l4
      • nvidia-h100-80gb

      Le GPU in GKE Sandbox sono disponibili in anteprima.

   4. Se utilizzi GPU su GKE Sandbox (anteprima), seleziona o installa la variante del driver latest.

6. Dal menu di navigazione, fai clic su Sicurezza e seleziona la casella di controllo Abilita sandbox con gVisor.

7. Fai clic su Crea.

gcloud

Per creare un nuovo pool di nodi con GKE Sandbox abilitata, utilizza un comando simile al seguente:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Il tipo di immagine del nodo deve essere cos_containerd per GKE Sandbox.

Anteprima - GPUs in GKE Sandbox

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Per creare un pool di nodi GPU con GKE Sandbox, esegui questo comando:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --accelerator=type=GPU_TYPE,gpu-driver-version=latest \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Sostituisci quanto segue:

• GPU_TYPE: un tipo di GPU supportato. Per maggiori dettagli, consulta GKE Sandbox.

• MACHINE_TYPE: una macchina corrispondente al tipo di GPU richiesto. Per maggiori dettagli, consulta Requisiti GPU di Google Kubernetes Engine.

(Facoltativo) Abilita monitoraggio e logging

È facoltativo, ma ti consigliamo di abilitare Cloud Logging e Cloud Monitoring nel cluster, in modo che i messaggi di gVisor vengano registrati. Questi servizi sono abilitati per impostazione predefinita per i nuovi cluster.

Puoi utilizzare la console Google Cloud per abilitare queste funzionalità su un cluster esistente.

1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

   Vai a Google Kubernetes Engine

2. Fai clic sul nome del cluster da modificare.

3. In Funzionalità, nel campo Cloud Logging, fai clic su Modifica Cloud Logging.

4. Seleziona la casella di controllo Abilita Cloud Logging.

5. Fai clic su Salva modifiche.

6. Ripeti gli stessi passaggi per i campi Cloud Monitoring e Managed Service per Prometheus per abilitare queste funzionalità.

Usa GKE Sandbox in Autopilot e Standard

Nei cluster Autopilot e in quelli Standard con GKE Sandbox abilitata, richiedi un ambiente con sandbox per un pod specificando il RuntimeClass gvisor nella specifica del pod.

Per i cluster Autopilot, assicurati di eseguire GKE versione 1.27.4-gke.800 o successiva.

Esecuzione di un'applicazione in una sandbox

Per eseguire un deployment su un nodo con GKE Sandbox abilitata, imposta il relativo spec.template.spec.runtimeClassName su gvisor, come mostrato nell'esempio seguente:

# httpd.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      runtimeClassName: gvisor
      containers:
      - name: httpd
        image: httpd

Crea il deployment:

kubectl apply -f httpd.yaml

Il deployment del pod viene eseguito su un nodo con GKE Sandbox abilitata. Per verificare il deployment, trova il nodo in cui viene eseguito il deployment del pod:

kubectl get pods

L'output è simile al seguente:

NAME                    READY   STATUS    RESTARTS   AGE
httpd-db5899bc9-dk7lk   1/1     Running   0          24s

Dall'output, trova il nome del pod nell'output, quindi controlla il valore per RuntimeClass:

kubectl get pods POD_NAME -o jsonpath='{.spec.runtimeClassName}'

L'output è gvisor.

In alternativa, puoi elencare il RuntimeClass di ogni pod e cercare i pod in cui è impostato su gvisor:

kubectl get pods -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'

L'output è il seguente:

POD_NAME: gvisor

Questo metodo per verificare che il pod sia in esecuzione in una sandbox è affidabile perché non si basa su dati all'interno della sandbox stessa. Qualsiasi informazione segnalata all'interno della sandbox è inaffidabile, perché potrebbe essere difettosa o dannosa.

Esecuzione di un pod con GPU su GKE Sandbox

Anteprima - GPUs in GKE Sandbox

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Per eseguire un carico di lavoro GPU su GKE Sandbox, aggiungi il campo runtimeClassName: gvisor al manifest come negli esempi seguenti:

• Manifest di esempio per i pod GPU in modalità Standard:

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-gpu-pod
  spec:
    runtimeClassName: gvisor
    containers:
    - name: my-gpu-container
      image: nvidia/samples:vectoradd-cuda10.2
      resources:
        limits:
        nvidia.com/gpu: 1
  

• Manifest di esempio per i pod GPU in modalità Autopilot:

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-gpu-pod
  spec:
    runtimeClassName: gvisor
    nodeSelector:
      cloud.google.com/compute-class: "Accelerator"
      cloud.google.com/gke-accelerator: nvidia-tesla-t4
    - name: my-gpu-container
      image: nvidia/samples:vectoradd-cuda10.2
      resources:
        limits:
          nvidia.com/gpu: 1
  

Puoi eseguire qualsiasi pod GPU in modalità Autopilot o Standard che soddisfa i requisiti di versione e tipo di GPU su GKE Sandbox aggiungendo il campo runtimeClassName: gvisor al manifest. Per istruzioni sull'esecuzione dei pod GPU in GKE, consulta le seguenti risorse:

• Esegui il deployment dei carichi di lavoro GPU in Autopilot
• Esegui GPU in pool di nodi GKE Standard

Esecuzione di un pod normale e di pod con sandbox

I passaggi in questa sezione si applicano ai carichi di lavoro in modalità Standard. Non è necessario eseguire pod regolari insieme ai pod sandbox in modalità Autopilot, perché il modello di prezzi di Autopilot elimina la necessità di ottimizzare manualmente il numero di pod pianificati sui nodi.

Dopo aver abilitato GKE Sandbox su un pool di nodi, puoi eseguire applicazioni attendibili sui nodi senza utilizzare una sandbox, utilizzando le incompatibilità e le tolleranze dei nodi. Questi pod sono chiamati "pod normali" per distinguerli dai pod con sandbox.

I pod normali, proprio come i pod con sandbox, non possono accedere ad altri servizi Google Cloud o ai metadati del cluster. Questa prevenzione fa parte della configurazione del nodo. Se i normali pod o pod con sandbox richiedono l'accesso ai servizi Google Cloud, utilizza Workload Identity Federation for GKE.

L'esecuzione di codice non attendibile sugli stessi nodi di servizi di sistema critici comporta un potenziale rischio, anche se il codice non attendibile è in esecuzione in una sandbox. Prendi in considerazione questi rischi durante la progettazione delle tue applicazioni.

GKE Sandbox aggiunge le seguenti etichetta e incompatibilità ai nodi che possono eseguire pod con sandbox:

labels:
  sandbox.gke.io/runtime: gvisor

taints:
- effect: NoSchedule
  key: sandbox.gke.io/runtime
  value: gvisor

Oltre a qualsiasi impostazione di affinità e tolleranza dei nodi nel manifest dei pod, GKE Sandbox applica la seguente affinità e tolleranza dei nodi a tutti i pod con RuntimeClass impostato su gvisor:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: sandbox.gke.io/runtime
          operator: In
          values:
          - gvisor

tolerations:
  - effect: NoSchedule
    key: sandbox.gke.io/runtime
    operator: Equal
    value: gvisor

Per pianificare un pod normale su un nodo con GKE Sandbox abilitata, applica manualmente l'affinità e la tolleranza del nodo descritte in precedenza nel manifest del pod.

• Se il tuo pod può essere eseguito su nodi con GKE Sandbox abilitata, aggiungi la tolleranza.
• Se il tuo pod deve essere eseguito su nodi con GKE Sandbox abilitata, aggiungi sia l'affinità dei nodi sia la tolleranza.

Ad esempio, il seguente manifest modifica il manifest utilizzato in Esecuzione di un'applicazione in una sandbox in modo che venga eseguita come un normale pod su un nodo con pod con sandbox, rimuovendo il runtimeClass e aggiungendo sia l'incompatibilità e la tolleranza descritte in precedenza.

# httpd-no-sandbox.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-no-sandbox
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: httpd
        image: httpd
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: sandbox.gke.io/runtime
                operator: In
                values:
                - gvisor
      tolerations:
        - effect: NoSchedule
          key: sandbox.gke.io/runtime
          operator: Equal
          value: gvisor

Innanzitutto, verifica che il deployment non sia in esecuzione in una sandbox:

kubectl get pods -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'

L'output è simile a questo:

httpd-db5899bc9-dk7lk: gvisor
httpd-no-sandbox-5bf87996c6-cfmmd:

Il deployment httpd creato in precedenza è in esecuzione in una sandbox, perché il suo runtimeClass è gvisor. Il deployment httpd-no-sandbox non ha alcun valore per runtimeClass, quindi non è in esecuzione in una sandbox.

Quindi, verifica che il deployment senza sandbox sia in esecuzione su un nodo con GKE Sandbox eseguendo questo comando:

kubectl get pod -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.nodeName}\n{end}'

Il nome del pool di nodi è incorporato nel valore di nodeName. Verifica che il pod sia in esecuzione su un nodo in un pool di nodi con GKE Sandbox abilitata.

Nota: se il pod normale non è pianificabile, verifica che l'incompatibilità e la tolleranza siano impostate correttamente nel manifest del pod.

Verifica della protezione dei metadati in corso...

Per convalidare l'asserzione che i metadati sono protetti dai nodi che possono eseguire pod con sandbox, puoi eseguire un test:

1. Crea un deployment con sandbox dal manifest seguente utilizzando kubectl apply -f. Utilizza l'immagine fedora, che include il comando curl. Il pod esegue il comando /bin/sleep per garantire che il deployment venga eseguito per 10.000 secondi.

   # sandbox-metadata-test.yaml
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: fedora
     labels:
       app: fedora
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: fedora
     template:
       metadata:
         labels:
           app: fedora
       spec:
         runtimeClassName: gvisor
         containers:
         - name: fedora
           image: fedora
           command: ["/bin/sleep","10000"]
   

2. Ottieni il nome del pod utilizzando kubectl get pods, quindi usa kubectl exec per connetterti al pod in modo interattivo.

   kubectl exec -it POD_NAME /bin/sh
   

   Hai eseguito la connessione a un container in esecuzione nel pod, in una sessione /bin/sh.

3. All'interno della sessione interattiva, prova ad accedere a un URL che restituisce i metadati del cluster:

   curl -s "http://169.254.169.254/computeMetadata/v1/instance/attributes/kube-env" -H "Metadata-Flavor: Google"
   

   Il comando si blocca e alla fine si verifica il timeout perché i pacchetti vengono eliminati automaticamente.

4. Premi Ctrl+C per terminare il comando curl e digita exit per disconnetterti dal pod.

5. Rimuovi la riga RuntimeClass dal manifest YAML ed esegui di nuovo il deployment del pod utilizzando kubectl apply -f FILENAME. Il pod con sandbox viene terminato e ricreato su un nodo senza GKE Sandbox.

6. Ottieni il nuovo nome del pod, connettiti utilizzando kubectl exec ed esegui di nuovo il comando curl. Questa volta vengono restituiti i risultati. L'output di esempio è troncato.

   ALLOCATE_NODE_CIDRS: "true"
   API_SERVER_TEST_LOG_LEVEL: --v=3
   AUTOSCALER_ENV_VARS: kube_reserved=cpu=60m,memory=960Mi,ephemeral-storage=41Gi;...
   ...
   

   Digita exit per disconnetterti dal pod.

7. Rimuovi il deployment:

   kubectl delete deployment fedora
   

Disabilitazione di GKE Sandbox

Non puoi disabilitare GKE Sandbox nei cluster GKE Autopilot o nei pool di nodi GKE Standard. Se vuoi interrompere l'utilizzo di GKE Sandbox, elimina il pool di nodi.

Passaggi successivi

• Scopri di più sulla gestione dei pool di nodi.
• Leggi la panoramica sulla sicurezza.