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 oppure necessitano di un isolamento aggiuntivo dal nodo. Questa pagina spiega come abilitare GKE Sandbox e monitorare i cluster quando GKE Sandbox è in esecuzione.

Questa pagina è destinata agli esperti di sicurezza che devono isolare i propri carichi di lavoro per una protezione aggiuntiva da codice sconosciuto o non attendibile. 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 panoramica generale di GKE Sandbox.

Abilita 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, vai a Utilizzo di GKE Sandbox.

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

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

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le località predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Abilita GKE Sandbox su un nuovo cluster Standard

Il pool di nodi predefinito, creato quando crei un nuovo cluster, non può utilizzare GKE Sandbox se è l'unicopool di nodil nel cluster, perché i workload di sistema gestiti da GKE devono essere eseguiti separatamente dai workload in sandbox non attendibili. Per abilitare GKE Sandbox durante la creazione del cluster, devi aggiungere almeno unpool di nodil aggiuntivo al cluster.

Console

Per visualizzare i tuoi cluster, visita il menu Google Kubernetes Engine nella consoleGoogle Cloud .

1. Nella console Google Cloud , vai alla pagina Crea un cluster Kubernetes.

   Vai a Crea un cluster Kubernetes

2. (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

3. Fai clic su Aggiungi pool di nodi.

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

5. 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 una serie e un tipo di macchina.

   3. (Facoltativo) Se utilizzi una versione di GKE supportata, seleziona un tipo di GPU o TPU. Deve corrispondere a uno dei seguenti tipi di GPU:

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

      o i seguenti tipi di TPU:

      • v4
      • v5e
      • v5p
      • v6e

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

7. Continua a configurare il cluster e i node pool in base alle esigenze.

8. Fai clic su Crea.

gcloud

GKE Sandbox non può essere abilitato per il pool di nodi predefinito e non è possibile creare node pool aggiuntivi contemporaneamente alla creazione di un nuovo cluster utilizzando il comando gcloud. Crea invece il cluster come faresti normalmente. Sebbene sia facoltativo, ti consigliamo di abilitare Logging e monitoraggio in modo che i messaggi di gVisor vengano registrati.

Successivamente, utilizza 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.

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=DRIVER_VERSION \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Sostituisci quanto segue:

• GPU_TYPE: un tipo di GPU supportato. Per i dettagli, vedi GKE Sandbox.

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

• DRIVER_VERSION: la versione del driver NVIDIA da installare. Può corrispondere a uno dei seguenti:

  • default: installa la versione del driver predefinita per la tua versione di GKE.
  • latest: installa l'ultima versione del driver disponibile per la tua versione di GKE. Disponibile solo per i nodi che utilizzano Container-Optimized OS.

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

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --num-nodes=NUM_NODES \
  --tpu-topology=TPU_TOPOLOGY \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

• MACHINE_TYPE: un tipo di TPU supportato. Per i dettagli, vedi GKE Sandbox.

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 abilitato:

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 node pool come selezionato.

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 una serie e un tipo di macchina.

   3. (Facoltativo) Se utilizzi una versione di GKE supportata, seleziona un tipo di GPU o TPU. Deve corrispondere a uno dei seguenti tipi di GPU:

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

      o i seguenti tipi di TPU:

      • v4
      • v5e
      • v5p
      • v6e

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

7. Fai clic su Crea.

gcloud

Per creare un nuovo pool di nodi con GKE Sandbox abilitato, utilizza un comando come il 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.

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=DRIVER_VERSION \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Sostituisci quanto segue:

• GPU_TYPE: un tipo di GPU supportato. Per i dettagli, vedi GKE Sandbox.

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

• DRIVER_VERSION: la versione del driver NVIDIA da installare. Può corrispondere a uno dei seguenti:

  • default: installa la versione del driver predefinita per la tua versione di GKE.
  • latest: installa l'ultima versione del driver disponibile per la tua versione di GKE. Disponibile solo per i nodi che utilizzano Container-Optimized OS.

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

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --num-nodes=NUM_NODES \
  --tpu-topology=TPU_TOPOLOGY \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

• MACHINE_TYPE: un tipo di TPU supportato. Per i dettagli, vedi GKE Sandbox.

(Facoltativo) Abilita monitoraggio e logging

È facoltativo, ma ti consigliamo di abilitare Cloud Logging e Cloud Monitoring sul cluster, in modo che i messaggi 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. Nella sezione 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 attivare queste funzionalità.

Utilizzare GKE Sandbox in Autopilot e Standard

Nei cluster Autopilot e nei cluster Standard con GKE Sandbox abilitato, richiedi un ambiente in sandbox per un pod specificando la RuntimeClass gvisor nella specifica del pod.

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

Esegui un'applicazione in un sandbox

Per eseguire un deployment su un nodo con GKE Sandbox abilitato, 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 pod viene eseguito il deployment su un nodo con GKE Sandbox abilitato. Per verificare il deployment, trova il nodo in cui è stato 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

Nell'output, trova il nome del pod e controlla il valore di RuntimeClass:

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

L'output è gvisor.

In alternativa, puoi elencare 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 di verifica dell'esecuzione del pod in una sandbox è affidabile perché non si basa su alcun dato all'interno della sandbox stessa. Qualsiasi elemento segnalato dall'interno della sandbox non è attendibile, perché potrebbe essere difettoso o dannoso.

Esegui un pod con acceleratori su GKE Sandbox

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

• Esempio di manifest 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/gke-gpu-driver-version: "latest"
      cloud.google.com/gke-accelerator: nvidia-tesla-t4
    containers:
    - name: my-gpu-container
      image: nvidia/samples:vectoradd-cuda10.2
      resources:
        limits:
          nvidia.com/gpu: 1
  

• Esempio di manifest per i pod TPU in modalità Standard o Autopilot:

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-tpu-pod
  spec:
    runtimeClassName: gvisor
    nodeSelector:
      cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
      cloud.google.com/gke-tpu-topology: 1x1
    containers:
    - name: my-tpu-container
      image: python:3.10
      command:
        - bash
        - -c
        - |
          pip install 'jax[tpu]' -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
          python -c 'import jax; print("TPU cores:", jax.device_count())'
      resources:
        limits:
          google.com/tpu: 1
        requests:
          google.com/tpu: 1
  

Puoi eseguire qualsiasi pod acceleratore in modalità Autopilot o Standard che soddisfi i requisiti di versione e tipo di acceleratore su GKE Sandbox aggiungendo il campo runtimeClassName: gvisor al manifest. Per eseguire i pod GPU in GKE, consulta quanto segue:

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

Per eseguire i pod TPU in GKE, consulta quanto segue:

• Esegui il deployment dei carichi di lavoro TPU in Autopilot
• Esegui TPU nei node pool GKE Standard

Esegui un pod normale insieme ai pod in sandbox

I passaggi descritti 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 su questi nodi senza utilizzare una sandbox utilizzando taint e tolleranze dei nodi. Questi pod vengono chiamati "pod regolari" per distinguerli dai pod in sandbox.

Ai pod regolari, proprio come ai pod in sandbox, viene impedito di accedere ad altri servizi o ai metadati del cluster.Google Cloud Questa prevenzione fa parte della configurazione del nodo. Se i tuoi pod regolari o in sandbox richiedono l'accesso ai serviziGoogle Cloud , utilizza la federazione delle identità per i carichi di lavoro per GKE.

L'esecuzione di codice non attendibile sugli stessi nodi dei servizi di sistema critici comporta un potenziale rischio, anche se il codice non attendibile viene eseguito in una sandbox. Considera questi rischi quando progetti le tue applicazioni.

GKE Sandbox aggiunge la seguente etichetta e incompatibilità ai nodi che possono eseguire pod in modalità sandbox:

labels:
  sandbox.gke.io/runtime: gvisor

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

Oltre a qualsiasi impostazione di affinità nodo e tolleranza nel manifest del pod, GKE Sandbox applica la seguente affinità nodo e tolleranza 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 abilitato, applica manualmente l'affinità e la tolleranza dei nodi descritte in precedenza nel manifest del pod.

• Se il tuo pod può essere eseguito su nodi con GKE Sandbox abilitato, aggiungi la tolleranza.
• Se il tuo pod deve essere eseguito su nodi con GKE Sandbox abilitato, 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 pod normale su un nodo con pod in sandbox, rimuovendo runtimeClass e aggiungendo sia la taint che 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 ldeployment non sia in esecuzione in una sandbox:

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

L'output è simile al seguente:

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

Il deployment httpd creato in precedenza viene eseguito in una sandbox perché la relativa runtimeClass è gvisor. Il deployment httpd-no-sandbox non ha un valore per runtimeClass, quindi non viene eseguito in una sandbox.

Successivamente, verifica che il deployment non in 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 abilitato.

Nota: se il pod normale non è pianificabile, verifica che il taint e la tolleranza siano impostati correttamente nel manifest del pod.

Verificare la protezione dei metadati

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

1. Crea un deployment in sandbox dal seguente manifest, utilizzando kubectl apply -f. Utilizza l'immagine fedora, che include il comando curl. Il pod esegue il comando /bin/sleep per assicurarsi 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 utilizza 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, tenta di 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 scade perché i pacchetti vengono eliminati in modo silenzioso.

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 nuovamente il deployment del pod utilizzando kubectl apply -f FILENAME. Il pod in modalità sandbox viene terminato e ricreato su un nodo senza GKE Sandbox.

6. Ottieni il nome del nuovo pod, connettiti utilizzando kubectl exec ed esegui di nuovo il comando curl. Questa volta vengono restituiti i risultati. L'output di questo 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
   

Disabilita GKE Sandbox

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

Passaggi successivi

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