Esta página descreve como o GKE Sandbox protege o kernel do anfitrião nos seus nós quando os contentores no pod executam código desconhecido ou não fidedigno. Por exemplo, os clusters multiinquilinos, como os fornecedores de software como serviço (SaaS), executam frequentemente código desconhecido enviado pelos respetivos utilizadores. O GKE Sandbox também é uma medida de defesa em profundidade útil para executar contentores de elevado valor.
Esta página destina-se a especialistas em segurança que querem saber mais sobre as vantagens do GKE Sandbox. 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. Google Cloud
Antes de ler esta página, certifique-se de que conhece a documentação oficial do gVisor, o projeto de código aberto que o GKE Sandbox usa.
Para obter instruções sobre como ativar e usar o GKE Sandbox, consulte o artigo Configure o GKE Sandbox.
Vista geral
O GKE Sandbox oferece uma camada adicional de segurança para impedir que o código não fidedigno afete o kernel anfitrião nos nós do cluster. Antes de abordar o funcionamento do GKE Sandbox, é útil compreender a natureza dos potenciais riscos que ajuda a mitigar.
Um tempo de execução do contentor, como o containerd, oferece algum grau de isolamento entre os processos do contentor e o kernel em execução no nó.
No entanto, o tempo de execução do contentor é frequentemente executado como um utilizador privilegiado no nó e tem acesso à maioria das chamadas do sistema para o kernel do anfitrião.
Potenciais ameaças
Os clusters multi-inquilinos e os clusters cujos contentores executam cargas de trabalho não fidedignas estão mais expostos a vulnerabilidades de segurança do que outros clusters. Os exemplos incluem fornecedores de SaaS, fornecedores de alojamento Web ou outras organizações que permitem aos respetivos utilizadores carregar e executar código. Uma falha no tempo de execução do contentor ou no kernel do anfitrião pode permitir que um processo em execução num contentor "escape" do contentor e afete o kernel do nó, o que pode provocar a falha do nó.
Também existe o potencial de um inquilino malicioso obter acesso e exfiltrar os dados de outro inquilino na memória ou no disco, explorando tal falha.
Por último, uma carga de trabalho não fidedigna pode potencialmente aceder a outros Google Cloud serviços ou metadados do cluster.
Como o GKE Sandbox mitiga potenciais ameaças
O gVisor é uma reimplementação do espaço do utilizador da API do kernel do Linux que não
precisa de privilégios elevados. Em conjunto com um tempo de execução do contentor, como o
containerd, o kernel do espaço do utilizador reimplementa a maioria das chamadas do sistema
e presta-lhes serviços em nome do kernel do anfitrião. O acesso direto ao kernel do anfitrião está limitado. Consulte o
guia de arquitetura do gVisor
para obter informações detalhadas sobre o funcionamento. Do ponto de vista do contentor, o gVisor é quase transparente e não requer alterações à aplicação contentorizada.
Quando pede o GKE Sandbox num pod em clusters do Autopilot, o GKE executa esse pod num sandbox. No GKE Standard, se ativar o GKE Sandbox nos nós, todos os pods que são executados nesses nós são executados em isolamentos de processos.
Cada sandbox usa o seu próprio kernel de espaço do utilizador. Tendo isto em conta, pode tomar decisões sobre como agrupar os contentores em pods, com base no nível de isolamento necessário e nas caraterísticas das suas aplicações.
O GKE Sandbox é especialmente adequado para os seguintes tipos de aplicações. Consulte as Limitações para mais informações que lhe permitam decidir que aplicações colocar em sandbox.
- Aplicações não fidedignas ou de terceiros que usam tempos de execução como Rust, Java, Python, PHP, Node.js ou Golang
- Front-ends, caches ou proxies de servidores Web
- Aplicações que processam multimédia ou dados externos através de CPUs
- Cargas de trabalho de aprendizagem automática que usam CPUs
- Aplicações que consomem muita CPU ou memória
As cargas de trabalho ou os serviços de IA/ML exigem frequentemente uma implementação mais rápida na produção. O gVisor foi concebido para proteger contra classes inteiras de vulnerabilidades comuns do Linux. Com a GKE Sandbox, pode aumentar a sua postura de segurança em cargas de trabalho intensivas em GPU e TPU sem alterações importantes ao seu código. Os principais exemplos de utilização em que a sandbox do GKE se enquadra bem são comuns às cargas de trabalho de IA/AA:
- Cargas de trabalho intensivas da GPU e TPU.
- Serviços que aceitam e executam código de utilizador não fidedigno.
- Serviços que processam entradas arbitrárias do utilizador.
- Cargas de trabalho que processam grandes conjuntos de dados e modelos de terceiros.
- Aplicações que usam bibliotecas de terceiros.
Para saber mais sobre a conceção e a segurança do acesso ao acelerador, consulte os guias de GPU e TPU do gVisor.
Recomendações de segurança adicionais
Quando usar o GKE Sandbox, recomendamos que siga também estas recomendações:
Especifique os limites de recursos em todos os contentores em execução numa sandbox. Isto protege contra o risco de uma aplicação defeituosa ou maliciosa privar o nó de recursos e afetar negativamente outras aplicações ou processos do sistema em execução no nó.
Se estiver a usar a federação de identidade da carga de trabalho para o GKE, bloqueie o acesso aos metadados do cluster através da política de rede para bloquear o acesso a
169.254.169.254. Isto protege contra o risco de uma aplicação maliciosa aceder a informações para dados potencialmente privados, como o ID do projeto, o nome do nó e a zona. A Workload Identity Federation para o GKE está sempre ativada nos clusters do GKE Autopilot.
Limitações
O GKE Sandbox funciona bem com muitas aplicações, mas não com todas. Esta secção fornece mais informações sobre as limitações atuais do GKE Sandbox.
GPUs no GKE Sandbox
Na versão 1.29.2-gke.1108000 e posteriores do GKE, o GKE Sandbox suporta a utilização de GPUs NVIDIA.
O GKE Sandbox não mitiga todas as vulnerabilidades dos controladores da NVIDIA, mas mantém a proteção contra vulnerabilidades do kernel do Linux. Para ver detalhes sobre como o projeto gVisor protege as cargas de trabalho da GPU, consulte o guia de suporte de GPU
As seguintes limitações aplicam-se às cargas de trabalho de GPU no GKE Sandbox:
- Apenas são suportadas cargas de trabalho CUDA.
- Um subconjunto de GPUs suportadas no GKE é suportado no GKE Sandbox. Para mais informações, consulte a tabela de apoio técnico para ver detalhes.
- O gVisor só suporta determinadas versões de controladores NVIDIA. O GKE Sandbox garante que o controlador
lateste o controladordefaultpara cada GPU suportada para cada versão do GKE são compatíveis. Não é garantido que outros controladores funcionem. - Nem todas as funcionalidades da GPU funcionam nativamente (por exemplo, RDMA ou IMEX). As funcionalidades da GPU vão ser suportadas caso a caso com base nas necessidades do cliente. Apresente um registo de apoio ao cliente ou apresente um erro nos problemas do GitHub do gVisor.
Pode usar o GKE Sandbox com cargas de trabalho de GPU sem custos adicionais.
Suporte de modelos de GPU do GKE Sandbox
A tabela seguinte descreve o suporte para diferentes modelos de GPU no GKE Sandbox:
| Modelo | Pré-visualização | Apoio técnico do GA | Notas |
|---|---|---|---|
|
|
- |
|
Suportado desde o lançamento inicial. |
|
|
|
- | - |
|
|
|
- | - |
|
|
|
- | - |
|
|
- | - | brevemente |
|
|
não suportado | não suportado | As GPUs V100 e P100 usam controladores proprietários e não são suportadas. |
|
|
- | - | {gke_sandbox} não suporta tipos de nós do Windows nem do Ubuntu, que são necessários para nós de estações de trabalho virtuais. |
TPUs no GKE Sandbox
Na versão 1.31.3-gke.1111001 e posteriores do GKE, o GKE Sandbox suporta a utilização de TPUs.
O GKE Sandbox não mitiga todas as vulnerabilidades do controlador da TPU, mas mantém a proteção contra vulnerabilidades do kernel do Linux. Para ver detalhes sobre como o projeto gVisor protege as cargas de trabalho da TPU, consulte o guia de apoio técnico da TPU.
As seguintes versões de hardware da TPU são suportadas: V4pod, V4lite, V5litepod, V5pod e V6e.
Pode usar o GKE Sandbox com cargas de trabalho de TPU sem custos adicionais.
Configuração do node pool
Aplica-se a clusters padrão
- Não pode usar o GKE Sandbox em pools de nós do Windows Server.
- Não pode ativar o GKE Sandbox no node pool predefinido para separar os serviços do sistema em execução no node pool predefinido de cargas de trabalho não fidedignas que usam o GKE Sandbox.
- Quando usar o GKE Sandbox, o cluster tem de ter, pelo menos, dois pools de nós. Tem de ter sempre, pelo menos, um pool de nós onde o GKE Sandbox está desativado. Este conjunto de nós tem de conter, pelo menos, um nó, mesmo que todas as suas cargas de trabalho estejam em sandbox.
- As versões do GKE anteriores a 1.24.2-gke.300 não suportam os tipos de máquinas e2-micro, e2-small e e2-medium. A versão 1.24.2-gke.300 e posteriores do GKE suportam estes tipos de máquinas.
- Os nós têm de usar a imagem do nó do SO otimizado para contentores com o containerd (
cos_containerd).
Acesso aos metadados do cluster
Aplica-se a clusters do Autopilot e Standard
- Os nós que executam pods em sandbox são impedidos de aceder aos metadados do cluster ao nível do sistema operativo no nó.
- No GKE Standard, pode executar pods normais num nó com o GKE Sandbox ativado. No entanto, por predefinição, esses pods normais não podem aceder aos serviços nem aos metadados do cluster. Google Cloud
- Use a federação de identidades da carga de trabalho para o GKE para conceder aos pods acesso aos Google Cloud serviços.
A SMT pode estar desativada
Aplica-se a clusters do Autopilot e Standard
As definições de multithreading simultâneo (SMT) são usadas para mitigar vulnerabilidades de canal lateral que tiram partido da partilha do estado central por parte dos threads, como as vulnerabilidades de amostragem de dados microarquitetónicos (MDS).
Nas versões 1.25.5-gke.2500 ou posteriores e 1.26.0-gke.2500 ou posteriores do GKE, o gVisor está configurado para usar a Programação do núcleo do Linux para mitigar ataques de canal lateral. As definições de SMT permanecem inalteradas em relação às predefinições. A programação do núcleo é usada apenas para cargas de trabalho executadas com o gVisor.
A partir da versão 1.24.2-gke.300 do GKE, a SMT é configurada por tipo de máquina com base na vulnerabilidade da máquina à MDS, da seguinte forma:
Pods do Autopilot em execução na
Scale-Outclasse de computação: SMT desativado.Tipos de máquinas com processadores Intel: SMT desativado por predefinição.
Tipos de máquinas sem processadores Intel: SMT ativado por predefinição.
Tipos de máquinas com apenas uma thread por núcleo: sem suporte de SMT. Todas as vCPUs pedidas visíveis.
Antes da versão 1.24.2-gke.300, a SMT está desativada em todos os tipos de máquinas.
Ative a SMT
Aplica-se a clusters padrão
Nos clusters padrão do GKE, pode ativar a SMT se estiver desativada no tipo de máquina selecionado. É-lhe cobrado o valor de cada vCPU, independentemente de ativar ou manter desativado o SMT. Para obter informações sobre os preços, consulte os preços do Compute Engine.
GKE versão 1.24.2-gke.300 e posterior
Defina a flag --threads-per-core quando
criar um node pool 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 existente onde quer criar o novo conjunto de nós.LOCATION: a região ou a zona do Compute Engine do cluster.MACHINE_TYPE: o tipo de máquina.
Para mais informações sobre o --threads-per-core, consulte o artigo
Defina o número de threads por núcleo.
Versões do GKE anteriores a 1.24.2-gke.300
Crie um novo node pool no cluster com a etiqueta 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 o seguinte:
CLUSTER_NAME: o nome de um cluster existente onde quer criar o novo conjunto de nós.LOCATION: a região ou a zona do Compute Engine do cluster.MACHINE_TYPE: o tipo de máquina.
Implemente o DaemonSet no node pool. O DaemonSet só é executado em nós com a etiqueta
cloud.google.com/gke-smt-disabled=false.kubectl create -f \ https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yamlCertifique-se de que os pods DaemonSet estão no estado de execução.
kubectl get pods --selector=name=enable-smt -n kube-systemO resultado é semelhante ao seguinte:
NAME READY STATUS RESTARTS AGE enable-smt-2xnnc 1/1 Running 0 6mVerifique se
SMT has been enabledaparece nos registos dos pods.kubectl logs enable-smt-2xnnc enable-smt -n kube-system
Capacidades
Aplica-se a clusters padrão
Por predefinição, o contentor está impedido de abrir sockets não processados para reduzir o potencial de ataques maliciosos. Determinadas ferramentas relacionadas com a rede, como ping
e tcpdump, criam sockets brutos como parte da respetiva operação principal. Para ativar os sockets brutos, tem de adicionar explicitamente a capacidade NET_RAW ao contexto de segurança do contentor:
spec:
containers:
- name: my-container
securityContext:
capabilities:
add: ["NET_RAW"]
Se usar o GKE Autopilot, Google Cloud impede que
adicione a autorização NET_RAW a contentores devido às implicações de segurança desta capacidade.
Dependências externas
Aplica-se a clusters do Autopilot e Standard
O código não fidedigno executado na área restrita pode ter autorização para alcançar serviços externos, como servidores de bases de dados, APIs, outros contentores e controladores CSI. Estes serviços estão a ser executados fora do limite da sandbox e têm de ser protegidos individualmente. Um atacante pode tentar explorar vulnerabilidades nestes serviços para sair do sandbox. Tem de considerar o risco e o impacto de estes serviços serem acessíveis pelo código executado na sandbox e aplicar as medidas necessárias para os proteger.
Isto inclui implementações do sistema de ficheiros para volumes de contentores, como controladores ext4 e CSI. Os controladores CSI são executados fora do isolamento do sandbox e podem ter acesso privilegiado ao anfitrião e aos serviços. Uma exploração nestes controladores pode afetar o kernel do anfitrião e comprometer todo o nó. Recomendamos que execute o controlador CSI num contentor com a menor quantidade de autorizações necessárias para reduzir a exposição em caso de exploração. O GKE Sandbox suporta a utilização do controlador CSI do Persistent Disk do Compute Engine.
Funcionalidades incompatíveis
Não pode usar o GKE Sandbox com as seguintes funcionalidades do Kubernetes:
- Métricas de utilização de memória ao nível do contentor. No entanto, a utilização de memória do pod é suportada.
- Armazenamento Hostpath
- Os limites de CPU e memória só são aplicados a pods garantidos e pods com capacidade de expansão, e apenas quando os limites de CPU e memória são especificados para todos os contentores em execução no pod.
- Contentores executados no modo privilegiado
- VolumeDevices
- Portforward
- Módulos de segurança do kernel do Linux, como Seccomp, Apparmor ou Selinux,
Sysctl,
NoNewPrivileges, bidirectional MountPropagation, ou ProcMount. FSGroup é suportado na versão 1.22 e posteriores do GKE.
O Cloud Service Mesh não é suportado para pods do GKE Sandbox em clusters do Autopilot.
Caraterísticas da carga de trabalho
Aplica-se a clusters do Autopilot e Standard
A imposição de uma camada adicional de indireção para aceder ao kernel do nó tem desvantagens ao nível do desempenho. O GKE Sandbox oferece a vantagem mais tangível em grandes clusters multi-inquilino onde o isolamento é importante. Tenha em atenção as seguintes diretrizes quando testar as suas cargas de trabalho com a GKE Sandbox.
Chamadas do sistema
Aplica-se a clusters do Autopilot e Standard
As cargas de trabalho que geram um grande volume de chamadas do sistema de baixo custo, como um grande número de pequenas operações de E/S, podem exigir mais recursos do sistema quando são executadas num ambiente de testes restrito. Por isso, pode ter de usar nós mais potentes ou adicionar nós adicionais ao cluster.
Acesso direto ao hardware ou à virtualização
Aplica-se a clusters do Autopilot e Standard
Se a sua carga de trabalho precisar de qualquer um dos seguintes elementos, o GKE Sandbox pode não ser adequado, uma vez que impede o acesso direto ao kernel do anfitrião no nó:
- Acesso direto ao hardware do nó
- Funcionalidades de virtualização ao nível do kernel
- Contentores privilegiados
O que se segue?
- Configure o GKE Sandbox.
- Leia a Descrição geral de segurança.
- Saiba mais sobre o ciclo de vida do pod.