Reforce o isolamento de cargas de trabalho com o GKE Sandbox

Esta página descreve como usar o GKE Sandbox para proteger o kernel anfitrião nos seus nós quando os contentores no pod executam código desconhecido ou não fidedigno, ou precisam de isolamento adicional do nó. Esta página explica como pode ativar o GKE Sandbox e monitorizar os seus clusters quando o GKE Sandbox está em execução.

Esta página destina-se a especialistas em segurança que têm de isolar as respetivas cargas de trabalho para proteção adicional contra código desconhecido ou não fidedigno. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Trusted Cloud by S3NS

Antes de ler esta página, certifique-se de que conhece a vista geral do GKE Sandbox.

Ative o GKE Sandbox

O GKE Sandbox está pronto a ser usado em clusters do Autopilot com a versão 1.27.4-gke.800 e posterior do GKE. Para começar a implementar cargas de trabalho do Autopilot numa sandbox, avance para a secção Trabalhar com a sandbox do GKE.

Para usar o GKE Sandbox em clusters GKE Standard novos ou existentes, tem de ativar manualmente o GKE Sandbox no cluster.

Para mais informações sobre os lançamentos de versões da GPU, consulte o artigo Apoio técnico para modelos de GPU para ver detalhes sobre os lançamentos de versões da GPU.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

Ative o GKE Sandbox num novo cluster padrão

O conjunto de nós predefinido, que é criado quando cria um novo cluster, não pode usar o GKE Sandbox se for o único conjunto de nós no cluster, porque as cargas de trabalho do sistema geridas pelo GKE têm de ser executadas separadamente das cargas de trabalho em sandbox não fidedignas. Para ativar o GKE Sandbox durante a criação do cluster, tem de adicionar, pelo menos, um conjunto de nós adicional ao cluster.

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

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

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

Ative o GKE Sandbox num cluster Standard existente

Pode ativar o GKE Sandbox num cluster padrão existente adicionando um novo conjunto de nós e ativando a funcionalidade para esse conjunto de nós.

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

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

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

Opcional: ative a monitorização e o registo

É opcional, mas recomendamos que ative o Cloud Logging e o Cloud Monitoring no cluster para que as mensagens do gVisor sejam registadas. Estes serviços estão ativados por predefinição para novos clusters.

Pode usar a consola Trusted Cloud para ativar estas funcionalidades num cluster existente.

1. Aceda à página do Google Kubernetes Engine na Trusted Cloud consola.

   Aceda ao Google Kubernetes Engine

2. Clique no nome do cluster que quer modificar.

3. Em Funcionalidades, no campo Cloud Logging clique em edit Editar Cloud Logging.

4. Selecione a caixa de verificação Ativar o Cloud Logging.

5. Clique em Guardar alterações.

6. Repita os mesmos passos para os campos Cloud Monitoring e Managed Service for Prometheus para ativar essas funcionalidades.

Use o GKE Sandbox no Autopilot e no Standard

Nos clusters do Autopilot e nos clusters Standard com o GKE Sandbox ativado, pede um ambiente em sandbox para um pod especificando a gvisor RuntimeClass na especificação do pod.

Para clusters do Autopilot, certifique-se de que está a usar a versão 1.27.4-gke.800 ou posterior do GKE.

Execute uma aplicação numa sandbox

Para executar uma implementação num nó com o GKE Sandbox ativado, defina o respetivo spec.template.spec.runtimeClassName como gvisor, conforme mostrado no seguinte exemplo:

# 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

Crie a implementação:

kubectl apply -f httpd.yaml

O pod é implementado num nó com o GKE Sandbox ativado. Para validar a implementação, encontre o nó onde o pod está implementado:

kubectl get pods

O resultado é semelhante ao seguinte:

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

Na saída, procure o nome do Pod e, em seguida, verifique o valor de RuntimeClass:

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

O resultado é gvisor.

Em alternativa, pode listar a RuntimeClass de cada Pod e procurar os Pods onde está definida como gvisor:

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

O resultado é o seguinte:

POD_NAME: gvisor

Este método de verificação de que o Pod está a ser executado numa sandbox é fidedigno porque não depende de dados na própria sandbox. Tudo o que for comunicado a partir da sandbox não é fidedigno, uma vez que pode estar defeituoso ou ser malicioso.

Execute um pod com aceleradores no GKE Sandbox

Para executar uma carga de trabalho de GPU ou TPU no GKE Sandbox, adicione o campo runtimeClassName: gvisor ao manifesto, como nos seguintes exemplos:

• Exemplo de manifesto para agrupamentos de GPU no modo padrão:

  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
  

• Exemplo de manifesto para pods de GPU no modo 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
  

• Exemplo de manifesto para agrupamentos de TPUs no modo padrão ou automático:

  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: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
      command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())'
      resources:
        limits:
          google.com/tpu: 1
        requests:
          google.com/tpu: 1
  

Pode executar quaisquer pods de acelerador do modo Autopilot ou Standard que cumpram os requisitos de versão e tipo de acelerador no GKE Sandbox adicionando o campo runtimeClassName: gvisor ao manifesto. Para executar pods de GPU no GKE, consulte o seguinte:

• Implemente cargas de trabalho de GPU no Autopilot
• Execute GPUs em pools de nós padrão do GKE

Para executar TPU Pods no GKE, consulte o seguinte:

• Implemente cargas de trabalho de TPUs no Autopilot
• Execute TPUs em pools de nós padrão do GKE

Os tipos de GPUs suportados para o Autopilot são os seguintes:

• nvidia-gb200: NVIDIA GB200 NVL72 (pré-visualização)
• nvidia-b200: NVIDIA B200 (180 GB) (pré-visualização)
• nvidia-h200-141gb: NVIDIA H200 (141 GB) (pré-visualização)
• nvidia-h100-mega-80gb: NVIDIA H100 Mega (80GB)
• nvidia-h100-80gb: NVIDIA H100 (80GB)
• nvidia-a100-80gb: NVIDIA A100 (80GB)
• nvidia-tesla-a100: NVIDIA A100 (40GB)
• nvidia-l4: NVIDIA L4
• nvidia-tesla-t4: NVIDIA T4

Execute um pod normal juntamente com pods em sandbox

Os passos nesta secção aplicam-se a cargas de trabalho do modo padrão. Não precisa de executar pods normais juntamente com pods de sandbox no modo Autopilot, porque o modelo de preços do Autopilot elimina a necessidade de otimizar manualmente o número de pods agendados nos nós.

Depois de ativar o GKE Sandbox num conjunto de nós, pode executar aplicações fidedignas nesses nós sem usar um sandbox através de restrições e tolerâncias de nós. Estes pods são denominados "pods normais" para os distinguir dos pods em sandbox.

Os pods normais, tal como os pods em sandbox, são impedidos de aceder a outros Trusted Cloud serviços ou metadados do cluster. Esta prevenção faz parte da configuração do nó. Se os seus pods normais ou pods em sandbox precisarem de acesso a Trusted Cloud serviços, use a Federação do Workload Identity para o GKE.

O GKE Sandbox adiciona a seguinte etiqueta e taint aos nós que podem executar pods em sandbox:

labels:
  sandbox.gke.io/runtime: gvisor

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

Além de quaisquer definições de tolerância e afinidade de nós no manifesto do pod, o GKE Sandbox aplica a seguinte tolerância e afinidade de nós a todos os pods com RuntimeClass definido como 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

Para agendar um Pod normal num nó com o GKE Sandbox ativado, aplique manualmente a afinidade de nós e a tolerância descritas anteriormente no manifesto do Pod.

• Se o seu pod puder ser executado em nós com o GKE Sandbox ativado, adicione a tolerância.
• Se o seu pod tiver de ser executado em nós com o GKE Sandbox ativado, adicione a afinidade de nós e a tolerância.

Por exemplo, o seguinte manifesto modifica o manifesto usado em Executar uma aplicação numa sandbox para que seja executado como um Pod normal num nó com Pods em sandbox, removendo o runtimeClass e adicionando a contaminação e a tolerância descritas anteriormente.

# 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

Primeiro, verifique se a implementação não está a ser executada num sandbox:

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

O resultado é semelhante ao seguinte:

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

A implementação httpd criada anteriormente está a ser executada num ambiente de testes, porque a respetiva runtimeClass é gvisor. A implementação httpd-no-sandbox não tem valor para runtimeClass, pelo que não está a ser executada numa sandbox.

Em seguida, valide se a implementação não em sandbox está a ser executada num nó com o GKE Sandbox executando o seguinte comando:

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

O nome do conjunto de nós está incorporado no valor de nodeName. Verifique se o pod está a ser executado num nó num conjunto de nós com a GKE Sandbox ativada.

Valide a proteção de metadados

Para validar a afirmação de que os metadados estão protegidos contra nós que podem executar pods em sandbox, pode executar um teste:

1. Crie uma implementação em sandbox a partir do seguinte manifesto, usando o comando kubectl apply -f. Usa a imagem fedora, que inclui o comando curl. O pod executa o comando /bin/sleep para garantir que a implementação é executada durante 10 000 segundos.

   # 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. Obtenha o nome do Pod através de kubectl get pods e, em seguida, use kubectl exec para se ligar ao Pod de forma interativa.

   kubectl exec -it POD_NAME /bin/sh
   

   Tem ligação a um contentor em execução no pod, numa sessão do /bin/sh.

3. Na sessão interativa, tente aceder a um URL que devolva metadados do cluster:

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

   O comando fica bloqueado e, eventualmente, expira porque os pacotes são ignorados silenciosamente.

4. Prima Ctrl+C para terminar o comando curl e escreva exit para se desligar do Pod.

5. Remova a linha RuntimeClass do manifesto YAML e volte a implementar o pod usando kubectl apply -f FILENAME. O pod em sandbox é terminado e recriado num nó sem o GKE Sandbox.

6. Obtenha o novo nome do pod, ligue-se ao mesmo através de kubectl exec e execute novamente o comando curl. Desta vez, são devolvidos resultados. O resultado deste exemplo foi truncado.

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

   Digite exit para desassociar do Pod.

7. Remova a implementação:

   kubectl delete deployment fedora
   

Desative o GKE Sandbox

Não pode desativar o GKE Sandbox em clusters do GKE Autopilot nem em pools de nós do GKE Standard. Se quiser parar de usar o GKE Sandbox, elimine o conjunto de nós.

O que se segue?

• Saiba mais sobre a gestão de conjuntos de nós.
• Leia a descrição geral de segurança.