O blog oficial do Kubernetes publicou em 14 de maio um post de Adrian Moisey e Dan Winship (Red Hat) sobre o campo .spec.externalIPs em recursos do tipo Service. A peca destrincha por que o campo, criado como solucao pragmatica anos atras, hoje e um vetor de risco em clusters multi-tenant.

O que o campo faz

Em um cluster Kubernetes rodando em nuvem gerenciada (EKS, GKE, AKS), o tipo LoadBalancer faz o cluster provisionar um load balancer cloud que recebe trafego externo e o entrega ao Service. Mas quem roda Kubernetes bare-metal — em datacenter proprio, em VM on-prem, em homelab — nao tem essa peca por padrao.

O campo .spec.externalIPs foi uma tentativa antiga de cobrir esse gap. Quando setado, o kube-proxy passa a aceitar trafego destinado aos IPs declarados e roteia para os pods do Service. Para o admin que precisava expor um servico em IP externo conhecido sem ter LoadBalancer cloud, era a saida mais simples.

Onde mora o risco

O problema e que o campo nao tem controle de quem pode declarar quais IPs. Qualquer ServiceAccount com permissao de criar Service no namespace pode colocar qualquer IP no campo — inclusive um IP que pertence a outro Service legitimo, ou um IP usado por outro tenant do cluster.

Quando dois Services declaram o mesmo IP, o comportamento do kube-proxy fica nao-deterministico. Em um cluster multi-tenant, um Service mal-intencionado pode capturar trafego destinado a outro Service. O post chama isso de “hijack” — captura de trafego por reivindicacao do IP.

O risco e tipicamente nao-explorado porque a maioria dos clusters tem RBAC fechado o suficiente para que tenants nao criem Service em namespace alheio. Mas o problema fica latente: configuracao errada de RBAC abre a porta, e nao ha barreira nativa no Kubernetes para isso.

O que existe hoje como alternativa

O post recomenda nao usar externalIPs em producao multi-tenant. Para clusters bare-metal, duas alternativas modernas resolvem o problema sem o vetor de risco.

MetalLB: implementa LoadBalancer em clusters bare-metal usando BGP ou Layer 2 ARP. O admin define um pool de IPs que o MetalLB pode alocar; o cluster usa type: LoadBalancer normalmente. O controle de quais IPs sao permitidos fica centralizado, fora do alcance dos tenants.

kube-vip: solucao alternativa usando VIPs gerenciados pelo proprio cluster, sem necessidade de BGP. Util em ambientes menores onde a topologia de rede nao permite BGP.

IngressController dedicado: para trafego HTTP/HTTPS, montar nginx, Traefik ou Envoy como Ingress e usar um Service de tipo NodePort + algum mecanismo de DNS round-robin externo ao cluster. Sem expor o campo externalIPs em lugar nenhum.

O que ainda nao esta claro

O post nao decreta deprecation formal do campo. externalIPs continua valido na API. O que o time recomenda e: cuidado ao usar, especialmente em clusters multi-tenant; preferir alternativas modernas para casos novos; auditar clusters legados para identificar quem usa o campo hoje.

A pergunta aberta e se em algum momento o Kubernetes vai introduzir gating mais explicito — permissao especifica para declarar externalIPs, validacao na admission, ou ate remocao do campo em alguma versao futura. O post nao da pista de quando.

O que verificar agora em quem opera cluster

Para clusters em producao, faz sentido rodar uma busca rapida pelos Services que tem spec.externalIPs setado. Comando direto: kubectl get svc -A -o jsonpath='{range .items[?(@.spec.externalIPs)]}{.metadata.namespace}/{.metadata.name}: {.spec.externalIPs}{"\n"}{end}'.

Se a lista nao for vazia, vale entender o motivo de cada uso. Service interno que so foi exposto assim por preguica de configurar MetalLB pode ser migrado sem dor. Service exposto deliberadamente em IP de borda pede plano de migracao mais cuidadoso.

O RBAC do cluster e outro lugar para olhar. Se a permissao de create services esta concedida amplamente em namespaces tenant, vale apertar o controle agora, antes de o campo virar problema concreto.

O risco que merece monitoramento

O post nao anuncia CVE nem vulnerabilidade explorada em campo. O risco e estrutural, latente. O que vale acompanhar e a discussao na lista SIG-Network e em KEPs futuros sobre como o Kubernetes pretende lidar com o campo. Decisao de deprecation completa, se vier, deve ter ciclo longo de aviso — mas e o tipo de mudanca que pode mexer com cluster de quem nao prestou atencao.

Reportado originalmente por Kubernetes Blog em 2026-05-14.