Google mostra como usar o ClusterNetworkPolicy no GKE para aplicar políticas de rede em todo o cluster

O problema que o ClusterNetworkPolicy (CNP) ataca é conhecido de quem opera Kubernetes em escala: a NetworkPolicy padrão vive no namespace. Para impor uma regra global, é preciso replicar o mesmo manifesto em cada um deles e torcer para ninguém sobrescrever. O CNP sobe esse controle para o nível do cluster, com três camadas de precedência: Admin (avaliada primeiro, regras que ninguém contorna), Network policy (as políticas por namespace das equipes de aplicação) e Baseline (fallback, como um default-deny entre namespaces).

No Codelab, o cenário usa um cluster GKE Standard com Dataplane V2 (ADVANCED_DATAPATH, baseado em eBPF), um node pool TPU v5e em topologia 2x2 com o taint google.com/tpu=present:NoSchedule e o Gemma 4 (google/gemma-4-E2B-it) servido com vLLM no namespace gemma-llm. Há ainda o client-ns, com o cliente autorizado, e o untrusted-tenant, que simula um cliente malicioso. O fluxo tem três passos. Primeiro, um CNP na camada Baseline com subject.namespaces vazio nega todo ingress entre pods, liberando só DNS na porta 53. Segundo, o time do LLM cria uma NetworkPolicy comum que aceita a porta 8000 vinda dos pods rag-agent do client-ns. Terceiro, um CNP na camada Admin bloqueia egress para o metadata server (169.254.169.254) fora do DNS, e usa action: Pass para delegar o restante às camadas seguintes. Como o bloqueio está no topo, nem uma política allow-all de egress num namespace o desfaz.

Para validar, o post aponta o Hubble (fluxos eBPF em tempo real, sem sidecar) e o GKE Network Policy Logging, que joga os veredictos no Cloud Logging. Dá para filtrar por disposition="deny", namespaces de origem e destino e pelo nome da política. O próprio autor avisa que, em produção, as regras precisam ser planejadas conforme o ambiente.

Não há versão anterior do CNP na cobertura do CEVIU, então não dá para falar em evolução do recurso. O que existe é contexto próximo sobre a mesma plataforma de rede. Em 28 de outubro de 2026, o CEVIU publicou "VPC Flow Logs no GKE: como diagnosticar tráfego de workloads mais rápido, segundo o Google Cloud", e em 2 de novembro de 2026, "Google Cloud mostra como usar VPC Flow Logs para agilizar o troubleshooting de workloads no GKE". Também em 2 de novembro de 2026, saiu "GKE Dataplane V2 contorna limite de identidades do Cilium em workloads de agentes de IA de alta densidade". O Dataplane V2 é justamente o motor que o CNP usa, e os flow logs cobrem a observabilidade do tráfego que as políticas agora controlam.

Para quem opera plataforma, o ganho é separar responsabilidades: o time de plataforma crava guardrails e default-deny, e as equipes de aplicação ajustam só o que é delas. Na leitura editorial, isso reduz drift de políticas por namespace e facilita auditoria. Quem roda workloads de IA em GKE ganha uma forma direta de proteger o endpoint do modelo e o token de service account exposto pelo metadata. Vale testar com o logging ligado antes de ativar o deny em produção.