GKE Sandbox

Nesta página, você verá como o GKE Sandbox protege o kernel do host nos nós quando contêineres no pod executam códigos desconhecidos ou não confiáveis. Por exemplo, clusters multilocatários, como provedores de software como serviço (SaaS), geralmente executam código desconhecido enviado por usuários. O GKE Sandbox também é uma medida de defesa em profundidade útil para executar contêineres de alto valor.

O GKE Sandbox usa o gVisor, um projeto de código aberto. Neste tópico, o gVisor é abordado mais amplamente, mas é possível saber mais detalhes na documentação oficial do gVisor (em inglês).

Para instruções sobre como ativar e usar o GKE Sandbox, consulte Configurar o GKE Sandbox.

Informações gerais

O GKE Sandbox fornece uma camada extra de segurança para evitar que um código não confiável afete o kernel do host nos nós do cluster. Antes de discutir como o GKE Sandbox funciona, é bom entender a natureza dos riscos potenciais que ele ajuda a mitigar.

Um ambiente de execução do contêiner, como containerd, fornece algum 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.

Ameaças em potencial

Clusters de multilocação e clusters que têm contêineres que executam cargas de trabalho não confiáveis estão mais expostos a vulnerabilidades de segurança do que outros clusters. Os exemplos incluem provedores de SaaS, provedores de hospedagem na Web ou outras organizações que permitem que os usuários deles façam upload e executem códigos. Com uma falha no ambiente de execução do contêiner ou no kernel do host, é possível que um processo executado em um contêiner "escape" do contêiner e afete o kernel do nó, possivelmente derrubando o nó.

Também existe a possibilidade de um locatário mal-intencionado ter acesso e extrair dados de outro locatário na memória ou no disco, explorando esse tipo de falha.

Por fim, uma carga de trabalho não confiável pode acessar outros metadados de cluster ou serviços do Google Cloud.

Como o GKE Sandbox mitiga essas ameaças

O gVisor é uma reimplementação do espaço do usuário da API do kernel do Linux que não precisa de privilégios elevados. Em conjunto com um ambiente de execução do contêiner, como containerd, o kernel do espaço do usuário reimplementa a maioria das chamadas do sistema e as atende em nome do kernel do host. O acesso direto ao kernel do host é limitado. Consulte o Guia de arquitetura do gVisor (em inglês) para informações detalhadas sobre como isso funciona. Do ponto de vista do contêiner, o gVisor é quase transparente e não requer alterações no aplicativo em contêiner.

Quando você solicita o GKE Sandbox em um pod em clusters do Autopilot, o GKE executa esse pod em um sandbox. No GKE Standard, se você ativar o GKE Sandbox em nós, todos os pods executados nesses nós serão executados em sandboxes.

Cada sandbox usa seu próprio kernel de espaço do usuário. Com isso em mente, é possível tomar decisões sobre como agrupar seus contêineres nos pods, com base no nível de isolamento necessário e nas características dos aplicativos.

O GKE Sandbox é ideal para os seguintes tipos de aplicativos. Consulte a parte de limitações para mais informações. Elas ajudarão você a decidir quais aplicativos serão colocados no sandbox.

  • Aplicativos não confiáveis ou de terceiros que usam ambientes de execução como Rust, Java, Python, PHP, Node.js ou Golang.
  • Proxies, caches ou front-ends do servidor Web.
  • Aplicativos que processam mídia ou dados externos com CPUs.
  • Cargas de trabalho de machine learning que usam CPUs.
  • Aplicativos que consomem muita memória ou CPU.
  • Cargas de trabalho com uso intensivo de GPU

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

Na versão 1.29.2-gke.1108000 e mais recentes do GKE, o GKE Sandbox oferece suporte ao uso de GPUs NVIDIA.

O GKE Sandbox não mitiga todas as vulnerabilidades de drivers NVIDIA, mas mantém a proteção contra vulnerabilidades do kernel do Linux. Para detalhes sobre como o projeto 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:

  • Apenas a versão do driver latest da NVIDIA em uma determinada versão do GKE é aceita. Os clusters do Autopilot instalam automaticamente versões de driver da NVIDIA compatíveis com o GKE Sandbox.
  • Há suporte apenas para cargas de trabalho CUDA.
  • Os seguintes modelos de GPU são compatíveis: nvidia-tesla-t4, nvidia-tesla-a100, nvidia-a100-80gb, nvidia-l4 e nvidia-h100-80gb.

É possível usar o GKE Sandbox com cargas de trabalho de GPU sem custo adicional.

Configuração do pool de nós

Aplica-se a clusters Standard

  • Não é possível usar o GKE Sandbox em pools de nós do Windows Server.
  • Não é possível ativar o GKE Sandbox no pool de nós padrão para separar os serviços do sistema em execução no pool de nós padrão de cargas de trabalho não confiáveis usando o GKE Sandbox.
  • Ao usar o GKE Sandbox, seu cluster precisa ter pelo menos dois pools de nós. É sempre necessário ter pelo menos um pool de nós em que o GKE Sandbox esteja desativado. Esse pool precisa conter pelo menos um nó, mesmo que todas as suas cargas de trabalho estejam no sandbox.
  • As versões do GKE anteriores à 1.24.2-gke.300 não são compatíveis com os tipos de máquina e2-micro, e2-small e e2-medium. O GKE versão 1.24.2-gke.300 e mais recente é compatível com esses tipos de máquina.
  • Os nós precisam usar a imagem do nó Container-Optimized OS com containerd (cos_containerd).

Acesso aos metadados do cluster

Aplicável ao Autopilot e aos clusters Standard

  • Os nós que executam os Pods no sandbox são impedidos de acessar os metadados do cluster no nível do sistema operacional no nó.
  • No GKE Standard, é possível executar pods regulares em um nó com o GKE Sandbox ativado. No entanto, por padrão, esses pods regulares não podem acessar os metadados de cluster ou serviços do Google Cloud.
  • Use a federação de identidade da carga de trabalho do GKE para conceder aos pods acesso aos serviços do Google Cloud.

A SMT pode estar desativada

Aplicável ao Autopilot e aos clusters Standard

As configurações de multithreading simultâneas (SMT) 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).

Nas versões 1.25.5-gke.2500 ou posterior e 1.26.0-gke.2500 ou mais recentes do GKE, o gVisor é configurado para usar a Programação principal do Linux para reduzir ataques de canal lateral. As configurações de SMT não são alteradas por padrão. A programação principal é usada apenas para cargas de trabalho em execução com o gVisor.

A partir da versão 1.24.2-gke.300 do GKE, o SMT é configurado por tipo de máquina com base na vulnerabilidade da máquina ao MDS, da seguinte maneira:

Antes da versão 1.24.2-gke.300, o SMT estava desativado em todos os tipos de máquina.

Ativar SMT

Aplica-se a clusters Standard

Nos clusters padrão do GKE, é possível ativar a SMT se ela estiver desativada no tipo de máquina selecionado. Haverá cobrança por cada vCPU, independentemente de ativar a SMT ou mantê-la desativada. Para mais informações, consulte os preços do Compute Engine.

GKE versão 1.24.2-gke.300 e posterior

Defina a sinalização --threads-per-core ao criar um pool de nós do GKE Sandbox:

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

Para ver mais informações sobre --threads-per-core, consulte Definir o número de linhas de execução por núcleo.

Versões do GKE antes da versão 1.24.2-gke.300

  1. Crie um novo pool de nós no cluster com o rótulo do nó 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

  2. Implante o DaemonSet no pool de nós. O DaemonSet será executado somente 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á assim:

    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 soquetes brutos como parte da funcionalidade principal delas. 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, o Google Cloud 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

Não é possível usar o GKE Sandbox com os seguintes recursos do Kubernetes:

Características da carga de trabalho

Aplicável ao Autopilot e aos clusters Standard

Impor uma camada extra de indireção para acessar o kernel do nó tem vantagens e desvantagens de desempenho. O GKE Sandbox oferece benefícios mais evidentes em clusters de multilocatários grandes em que o isolamento é importante. Pense nas seguintes diretrizes ao testar suas cargas de trabalho com o GKE Sandbox.

Chamadas do sistema

Aplicável ao Autopilot e aos clusters Standard

Cargas de trabalho que geram um grande volume de chamadas de sistema com baixa sobrecarga, como um grande número de operações pequenas de E/S, podem exigir mais recursos do sistema durante a execução em um sandbox. Por isso, talvez seja necessário usar nós mais poderosos ou adicionar mais nós ao cluster.

Acesso direto ao hardware ou à virtualização

Aplicável ao Autopilot e aos clusters Standard

Se a carga de trabalho precisar de qualquer um dos itens a seguir, o GKE Sandbox talvez não seja adequado porque impede o acesso direto ao kernel do host no nó:

  • Acesso direto ao hardware do nó
  • Recursos de virtualização no nível do kernel
  • Contêineres privilegiados

A seguir