GKE Sandbox

Os contêineres que executam códigos desconhecidos ou não confiáveis em clusters do Google Kubernetes Engine (GKE) representam um risco de segurança em potencial para o kernel do host dos seus nós. É possível proteger o kernel do host contra essas ameaças isolando o código do kernel. Neste documento, descrevemos como o GKE Sandbox cria essa camada de isolamento usando tecnologias como o gVisor e microVMs.

Este documento é destinado a especialistas em segurança que querem reduzir a superfície de ataque nos nós do GKE e proteger os nós contra códigos não confiáveis. Você já deve estar familiarizado com o seguinte:

• Chamadas do sistema
• Arquitetura do nó do GKE
• Sandbox em sistemas de computador

Sobre o isolamento em sandbox no GKE

O ambiente de execução do contêiner instalado nos nós, como o containerd, oferece um grau de isolamento entre os processos do contêiner e o kernel em execução no nó. No entanto, o ambiente de execução do contêiner é frequentemente executado como um usuário privilegiado no nó e tem acesso à maioria das chamadas do sistema no kernel do host.

No Kubernetes e no GKE, o sandboxing isola os contêineres em execução para limitar o impacto potencial de exploits ou erros que afetam outros contêineres ou o ambiente de execução do contêiner. É possível executar contêineres em sandboxes para proteger o kernel da instância do Compute Engine subjacente contra códigos desconhecidos ou não confiáveis. O isolamento em sandbox também é uma boa medida de defesa em profundidade para proteger contêineres de alto valor contra o efeito de outras cargas de trabalho. É possível executar cargas de trabalho em sandboxes usando o GKE Sandbox.

Possíveis ameaças

Uma falha no ambiente de execução do contêiner ou no kernel do host pode permitir que um processo em execução em um contêiner "escape" do contêiner e afete o kernel do nó. Os clusters multitenant e aqueles em que os contêineres executam cargas de trabalho não confiáveis estão mais expostos a vulnerabilidades de segurança do que outros clusters. Os exemplos incluem:

• Organizações que permitem que os usuários façam upload e executem código, como provedores de SaaS e de hospedagem na Web.
• Agentes de IA que geram e executam código, geralmente sem supervisão.

As tecnologias de sandbox usadas pelo GKE Sandbox ajudam a mitigar o seguinte impacto potencial de fugas de contêiner:

• Código malicioso ou defeituoso que trava o kernel do host e derruba o nó.
• Locatários maliciosos que exfiltram os dados de outro locatário que estão na memória ou em um disco.
• Cargas de trabalho não confiáveis que acessam outros serviços do Cloud de Confiance by S3NS ou metadados do cluster.

Tecnologias de sandbox no GKE

O GKE Sandbox é compatível com as seguintes tecnologias de sandbox, cada uma usando uma abordagem diferente para isolar cargas de trabalho e funcionando bem para diferentes casos de uso:

• gVisor: uma reimplementação do espaço do usuário da API do kernel do Linux que não precisa de privilégios elevados. O kernel do espaço do usuário e o ambiente de execução do contêiner reimplementam a maioria das chamadas do sistema e as atendem em nome do kernel do host. O acesso direto ao kernel do host é limitado. Para mais informações sobre como o kernel convidado funciona, consulte o Guia de arquitetura do gVisor.

• MicroVMs: máquinas virtuais leves que executam um kernel e um sistema operacional Linux completos. Cada pod é executado em uma microVM própria, que oferece isolamento estrito de outros pods e do nó host. O GKE Sandbox usa o software de código aberto Kata Containers e o monitor de máquina virtual (VMM) Cloud Hypervisor para criar e gerenciar microVMs.

A tabela a seguir resume as principais diferenças entre o gVisor e as microVMs. Use essas informações para escolher a tecnologia de sandbox adequada ao seu caso de uso.

Para mais informações que podem ajudar você a decidir quais aplicativos executar em um tipo específico de sandbox, consulte Limitações.

Como funciona a solicitação de sandboxes

Para executar um aplicativo em um sandbox, faça o seguinte:

1. Ative uma tecnologia de sandbox em nós usando ComputeClasses para criar automaticamente os nós ou criando manualmente pools de nós.
2. Solicite um sandbox para pods usando a RuntimeClass correspondente para esse tipo de sandbox, como gvisor ou microvm. Para mais informações, consulte Como aumentar a proteção do isolamento da carga de trabalho com o GKE Sandbox.

O GKE programa os pods em nós que usam a tecnologia de sandbox solicitada, que lida com a execução do aplicativo no sandbox. Você pode executar pods que não solicitam sandboxes em nós com o GKE Sandbox ativado usando seletores e tolerâncias de nó, o que é útil para cargas de trabalho confiáveis, como ferramentas de monitoramento que você quer executar em todos os nós.

Outras recomendações de segurança

Ao usar o GKE Sandbox, aconselhamos que você também siga estas recomendações:

• Especifique limites de recursos em todos os contêineres em execução em um sandbox. Isso evita o risco de um aplicativo defeituoso ou malicioso privar o nó de recursos e afetar negativamente outros aplicativos ou processos do sistema em execução no nó.

• Se você estiver usando a federação de identidade da carga de trabalho do GKE, bloqueie o acesso aos metadados do cluster usando a política de rede para bloquear o acesso a 169.254.169.254. Isso protege o risco de um aplicativo mal-intencionado acessar informações a dados potencialmente privados, como ID do projeto, nome do nó e zona. A federação de identidade da carga de trabalho do GKE está sempre ativada nos clusters do Autopilotdo GKE.

Limitações

O GKE Sandbox funciona bem com muitos aplicativos, mas não todos. Você verá nesta seção mais informações sobre as limitações atuais do GKE Sandbox.

GPUs no GKE Sandbox

É possível executar cargas de trabalho de GPU em sandboxes usando o gVisor. O gVisor não mitiga todas as vulnerabilidades de drivers NVIDIA, mas mantém a proteção contra vulnerabilidades do kernel do Linux. Não use o compartilhamento de tempo de GPU em pods em sandbox, porque a GPU não fica totalmente isolada entre os pods. Para mais informações sobre como o gVisor protege as cargas de trabalho da GPU, consulte o Guia de suporte a GPUs.

As limitações a seguir se aplicam às cargas de trabalho de GPU no GKE Sandbox:

• As microVMs não são compatíveis com GPUs.
• Para o gVisor, as seguintes limitações se aplicam:
  • Há suporte apenas para cargas de trabalho CUDA.
  • Somente um subconjunto dos modelos de GPU disponíveis é compatível. Para mais informações, consulte Suporte a modelos de GPU.
  • Apenas as versões latest e default do driver NVIDIA são compatíveis com cada versão do GKE. Outras versões podem não funcionar.
  • Nem todos os recursos de GPU, como RDMA ou IMEX, são compatíveis. Dependendo das necessidades do cliente, o gVisor pode oferecer suporte a recursos específicos caso a caso. Para solicitar suporte para um recurso específico, abra um caso de suporte ou abra uma solicitação de recurso do gVisor.

Suporte a modelos de GPU

A tabela a seguir descreve o suporte para diferentes modelos de GPU no GKE Sandbox:

TPUs no GKE Sandbox

Na versão 1.31.3-gke.1111001 e mais recentes do GKE, é possível executar cargas de trabalho de TPU em sandboxes usando o gVisor. O gVisor não mitiga todas as vulnerabilidades de drivers de TPU, mas mantém a proteção contra vulnerabilidades do kernel do Linux. Para mais informações sobre como o projeto gVisor protege as cargas de trabalho da TPU, consulte o Guia de suporte a TPUs.

As limitações a seguir se aplicam às cargas de trabalho de TPU no GKE Sandbox:

• As microVMs não são compatíveis com TPUs.

• O gVisor é compatível com as seguintes versões de TPU:

  • V4pod
  • V4lite
  • V5litepod
  • V5pod
  • V6e

Configuração de nós

As limitações a seguir se aplicam aos nós que usam o GKE Sandbox:

• O gVisor e as microVMs são compatíveis apenas com nós do Linux. Os nós do Windows Server não são compatíveis.
• O gVisor é compatível apenas com a imagem de nó do Container-Optimized OS. As microVMs são compatíveis com as imagens de nó do Container-Optimized OS e do Ubuntu.
• As microVMs exigem que a virtualização aninhada esteja ativada nos nós. Todos os requisitos e limitações da virtualização aninhada se aplicam.
• Em clusters Standard, não é possível ativar o GKE Sandbox no pool de nós padrão. O cluster precisa ter sempre pelo menos um pool de nós que não use o GKE Sandbox. Esse pool de nós precisa conter pelo menos um nó, mesmo que todas as suas cargas de trabalho estejam no sandbox. Essa limitação existe para separar os serviços do sistema de cargas de trabalho não confiáveis.

Acesso aos metadados do cluster

Se os nós usarem o tipo de sandbox gVisor, os pods nos nós não poderão acessar metadados do cluster no nível do SO do nó. Os pods também não podem acessar os serviços do Cloud de Confiance, a menos que você use a Federação de Identidade da Carga de Trabalho para GKE para conceder papéis às identidades dos pods.

Essa limitação não se aplica ao tipo de sandbox de microVM. Para evitar o acesso aos metadados do cluster por pods em microVMs, use uma NetworkPolicy que negue o tráfego de saída para 169.254.169.252/32 na porta 988 ou, em clusters que usam o GKE Dataplane V2, para 169.254.169.254/32 na porta 80.

A SMT pode estar desativada

As configurações de multissegmentação simultânea (SMT, na sigla em inglês), também conhecidas como Hyper-Threading em CPUs Intel, são usadas para reduzir as vulnerabilidades de canais laterais que aproveitam as linhas de execução que compartilham o estado principal, como vulnerabilidades de amostragem de dados microarquitetônica (MDS).

Para reduzir ataques de canal lateral, o gVisor usa a Programação principal do Linux. As configurações de SMT não são alteradas em relação aos valores padrão. A programação principal do Linux se aplica apenas aos pods executados em sandboxes do gVisor.

A configuração padrão de SMT ou Hyper-Threading para um tipo de máquina depende da vulnerabilidade da máquina ao MDS, da seguinte maneira:

• Pods do Autopilot que usam a Scale-Out ComputeClass: a SMT está sempre desativada.
• Tipos de máquina que usam processadores Intel: o Hyper-Threading está desativado por padrão.
• Tipos de máquina que usam processadores AMD: o SMT é ativado por padrão.
• Tipos de máquina que usam apenas uma linha de execução por núcleo, como processadores Arm: sem suporte a SMT. Todas as vCPUs solicitadas estão visíveis.

Ativar SMT

Nos pools de nós do GKE Standard, é possível ativar a SMT se ela estiver desativada por padrão para o tipo de máquina selecionado. Você vai receber uma cobrança por cada vCPU, independentemente de ativar ou desativar a SMT. Para mais informações, consulte os preços ao mudar o número de linhas de execução por núcleo. Para mudar a configuração da SMT, faça o seguinte:

• Defina a flag --threads-per-core ao criar um pool de nós do GKE Sandbox que usa o gVisor:

  gcloud container node-pools create smt-enabled \
      --cluster=CLUSTER_NAME \
      --location=LOCATION \
      --machine-type=MACHINE_TYPE \
      --threads-per-core=2 \
      --sandbox=type=gvisor
  

  • CLUSTER_NAME: o nome de um cluster em que você quer criar o novo pool de nós.
  • LOCATION: a região ou zona do Compute Engine do cluster.
  • MACHINE_TYPE: o tipo de máquina.

• Use um DaemonSet para ativar o SMT em um pool de nós atual:

  1. Adicione o rótulo de nó cloud.google.com/gke-smt-disabled=false a um pool de nós atual que usa gVisor:

     gcloud container node-pools update NODE_POOL_NAME \
         --cluster=CLUSTER_NAME \
         --location=LOCATION \
         --node-labels=cloud.google.com/gke-smt-disabled=false
     

     Substitua:

     • NODE_POOL_NAME: o nome do pool de nós atual.
     • CLUSTER_NAME: o nome de um cluster em que você quer criar o novo pool de nós.
     • LOCATION: a região ou zona do Compute Engine do cluster.

  2. Implante o DaemonSet. O DaemonSet é executado apenas em nós com o rótulo 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. Verifique se os pods do DaemonSet estão no estado de execução.

     kubectl get pods --selector=name=enable-smt -n kube-system
     

     O resultado será o seguinte:

     NAME               READY     STATUS    RESTARTS   AGE
     enable-smt-2xnnc   1/1       Running   0          6m
     

  4. Verifique se SMT has been enabled aparece nos registros dos pods:

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

Recursos

Aplica-se a clusters Standard

Por padrão, o contêiner é impedido de abrir soquetes brutos para reduzir o potencial de ataques mal-intencionados. Algumas ferramentas relacionadas à rede, como ping e tcpdump, criam sockets brutos como parte da operação principal. Para ativar soquetes brutos, adicione explicitamente o recurso NET_RAW ao contexto de segurança do contêiner:

spec:
  containers:
  - name: my-container
    securityContext:
      capabilities:
        add: ["NET_RAW"]

Se você usa o Autopilot do GKE, Cloud de Confiance impede que você adicione a permissão NET_RAW aos contêineres devido às implicações de segurança desse recurso.

Dependências externas

Aplicável ao Autopilot e aos clusters Standard

Códigos não confiáveis em execução no sandbox podem conseguir acessar serviços externos, como servidores de banco de dados, APIs, outros contêineres e drivers CSI (em inglês). Esses serviços são executados fora do limite do sandbox e precisam ser protegidos separadamente. Um invasor pode tentar explorar as vulnerabilidades nesses serviços para escapar do sandbox. Você precisa considerar o risco e o impacto causados pelo acesso do código executado no sandbox e tomar as medidas necessárias para protegê-los.

Isso inclui implementações do sistema de arquivos de volumes de contêiner, como drivers CSI e ext4. Os drivers CSI são executados fora do isolamento do sandbox e podem ter acesso privilegiado ao host e aos serviços. Uma violação desses drivers afeta o kernel do host e compromete o nó inteiro. É recomendável que você execute o driver CSI em um contêiner com a menor quantidade de permissões necessárias, para reduzir a exposição em caso de exploração. O GKE Sandbox suporta o uso do driver CSI de disco permanente do Compute Engine.

Recursos incompatíveis

As seguintes limitações de recursos se aplicam ao GKE Sandbox:

• As limitações a seguir se aplicam aos sandboxes do gVisor e da microVM:

  • O Cloud Service Mesh não é compatível com sandboxes em clusters do Autopilot.
  • Módulos de segurança do kernel do Linux, como seccomp, AppArmor, SELinux, a flag "No New Privileges", a propagação de montagem bidirecional e o contexto de segurança do pod procMount não são compatíveis com pods em sandbox.
  • Não há suporte para métricas de uso da memória no nível do contêiner. No entanto, o uso da memória do pod é compatível.

• As limitações a seguir se aplicam apenas aos sandboxes do gVisor:

  • Contêineres que usam o modo privilegiado não são compatíveis.
  • Não há suporte para volumes de blocos brutos.
  • O encaminhamento de portas, como o uso de kubectl port-forward, não é compatível.
  • O armazenamento de hostpath não é compatível.
  • Não é possível definir parâmetros de kernel sysctl.
  • Os limites de CPU e memória são aplicados somente para pods que têm as classes de QoS Guaranteed ou Burstable e somente quando esses limites são especificados para todos os contêineres no pod.

• As limitações a seguir se aplicam apenas a sandboxes de microVMs:

  • Os pods que usam a configuração hostNetwork: true não são compatíveis. Os pods executados em um sandbox de microVM e que usam a configuração hostNetwork: true não podem acessar recursos fora do pod.
  • Qualquer ferramenta de diagnóstico que dependa do rastreamento no nível do soquete só pode acessar as interfaces de rede anexadas à microVM.

A seguir

• Configure o GKE Sandbox.
• Leia a visão geral de segurança.
• Saiba mais sobre o ciclo de vida dos pods.