Este documento descreve 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. Este documento pressupõe que você conhece o seguinte:
- gVisor, o projeto de código aberto que o GKE Sandbox usa.
Este documento é para especialistas em segurança aprenderem sobre os benefícios do GKE Sandbox. Para saber mais sobre as funções comuns e exemplos de tarefas que referenciamos no Google Cloud conteúdo, consulte Funções e tarefas comuns do usuário do GKE.
É possível usar o GKE Sandbox ao executar clusters multilocatários porque os provedores de Software as a Service (SaaS) geralmente executam código desconhecido enviado pelos usuários. O GKE Sandbox também é uma medida de defesa em profundidade útil para executar contêineres de alto valor.
Para saber como ativar e usar o GKE Sandbox, consulte Configurar o GKE Sandbox.
Visão geral
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.
Possíveis ameaças
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 Google Cloud serviços ou metadados de cluster.
Como o GKE Sandbox mitiga possíveis 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.
As cargas de trabalho ou serviços de IA/ML geralmente exigem uma implantação mais rápida na produção. O gVisor foi projetado para proteger contra classes inteiras de vulnerabilidades comuns do Linux. Com o GKE Sandbox, é possível aumentar a postura de segurança em cargas de trabalho intensivas de GPU e TPU sem grandes mudanças no código. Os principais casos de uso em que o GKE Sandbox se encaixa bem são comuns a cargas de trabalho de IA/ML:
- Cargas de trabalho intensivas de GPU e TPU.
- Serviços que aceitam e executam código de usuário não confiável.
- Serviços que processam entradas arbitrárias do usuário.
- Cargas de trabalho que processam grandes conjuntos de dados e modelos de terceiros.
- Aplicativos que usam bibliotecas de terceiros.
Saiba mais sobre o design e a segurança do acesso ao acelerador nos guias de GPU e TPU do gVisor.
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. Ao usar o GKE Sandbox, não recomendamos o uso do compartilhamento de tempo da GPU porque ela não está totalmente isolada entre os pods. 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:
- Há suporte apenas para cargas de trabalho CUDA.
- Um subconjunto de GPUs com suporte no GKE também tem suporte no GKE Sandbox. Para mais informações, consulte a tabela de suporte para detalhes.
- O gVisor oferece suporte apenas a versões selecionadas do driver NVIDIA. O GKE Sandbox garante que o driver
lateste odefaultpara cada GPU com suporte em cada versão do GKE sejam compatíveis. Não há garantia de que outros drivers funcionem. - Nem todos os recursos de GPU funcionarão nativamente (por exemplo, RDMA ou IMEX). Os recursos de GPU serão aceitos caso a caso com base na necessidade do cliente. Registre um caso de suporte ou um bug nos problemas do GitHub do gVisor.
É possível usar o GKE Sandbox com cargas de trabalho de GPU sem custo adicional.
Suporte ao modelo de GPU do GKE Sandbox
A tabela a seguir descreve o suporte para diferentes modelos de GPU no GKE Sandbox:
| Modelo | Visualizar | Suporte de GA | Observações |
|---|---|---|---|
|
|
|
- | - |
|
|
|
- | - |
|
|
- |
|
Com suporte desde o lançamento inicial. |
|
|
indisponível | indisponível | As V100 e P100 usam drivers proprietários e não terão suporte. |
|
|
- | - | O GKE Sandbox não oferece suporte a tipos de nós do Windows ou do Ubuntu, que são necessários para nós de estação de trabalho virtual. |
TPUs no GKE Sandbox
Na versão 1.31.3-gke.1111001 e mais recentes do GKE, o GKE Sandbox oferece suporte ao uso de TPUs.
O GKE Sandbox não mitiga todas as vulnerabilidades de drivers de TPU, mas mantém a proteção contra vulnerabilidades do kernel do Linux. Para detalhes sobre como o projeto gVisor protege as cargas de trabalho de TPU, consulte o Guia de suporte a TPUs.
As seguintes versões de hardware de TPU são aceitas: V4pod, V4lite, V5litepod, V5pod e V6e.
É possível usar o GKE Sandbox com cargas de trabalho de TPU 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 Google Cloud serviços ou metadados de cluster.
- Use a Federação de Identidade da Carga de Trabalho para GKE para conceder aos pods acesso aos Google Cloud serviços.
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:
Pods do Autopilot em execução na classe de computação
Scale-Out: SMT desativada.Tipos de máquina com processadores Intel: SMT desativado por padrão.
Tipos de máquinas sem processadores Intel: SMT ativado por padrão.
Tipos de máquinas com apenas uma linha de execução por núcleo: sem suporte a SMT. Todas as vCPUs solicitadas visíveis.
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 \
--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.
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
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 \ --location=LOCATION \ --machine-type=MACHINE_TYPE \ --node-labels=cloud.google.com/gke-smt-disabled=false \ --image-type=cos_containerd \ --sandbox type=gvisorSubstitua:
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.
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.yamlVerifique se os pods do DaemonSet estão no estado de execução.
kubectl get pods --selector=name=enable-smt -n kube-systemO resultado será assim:
NAME READY STATUS RESTARTS AGE enable-smt-2xnnc 1/1 Running 0 6mVerifique se
SMT has been enabledaparece 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 operação 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, Google Cloud ele 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:
- Métricas de uso da memória no nível do contêiner. No entanto, o uso da memória do pod é compatível.
- Armazenamento do Hostpath (em inglês).
- Os limites de CPU e memória são aplicados somente para pods garantidos e com burst e somente quando esses limites são especificados para todos os contêineres em execução no pod.
- Contêineres em execução no modo privilegiado
- VolumeDevices
- Portforward (em inglês).
- Módulos de segurança do kernel do Linux, como Seccomp, Apparmor ou Selinux Sysctl,
NoNewPrivileges, MountPropagation bidirecional ou ProcMount (páginas em inglês). FSGroup é compatível com o GKE versão 1.22 e posterior.
O Cloud Service Mesh não é compatível com pods do GKE Sandbox em clusters do Autopilot.
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
- Configure o GKE Sandbox.
- Leia a visão geral de segurança.
- Saiba mais sobre o ciclo de vida dos pods.