Kubernetes v1.36: O fim do Service ExternalIPs e o que você precisa fazer agora

Kubernetes v1.36: O fim do Service ExternalIPs e o que você precisa fazer agora

A partir do Kubernetes 1.36, o campo .spec.externalIPs está oficialmente obsoleto. Essa funcionalidade, historicamente usada como um atalho de load balancer em clusters on-premise, nunca foi segura — permitindo a exploração da vulnerabilidade CVE-2020-8554. A conclusão para times de engenharia é clara: abandone essa prática e migre imediatamente para soluções de controle de tráfego mais robustas, como MetalLB, Gateway API ou LoadBalancer Services gerenciados, para garantir a integridade e segurança do seu ecossistema.

Historicamente, o campo .spec.externalIPs surgiu como uma tentativa rudimentar de emular o comportamento de cloud load balancers em ambientes que não dispunham de integração nativa com provedores de nuvem. Embora funcional para testes rápidos, a implementação ignora princípios fundamentais de isolamento de infraestrutura. Em qualquer cenário onde os usuários não possuem níveis totais de confiança — que é, por definição, quase todos os ambientes corporativos —, essa abordagem abre brechas para o CVE-2020-8554, permitindo que usuários maliciosos ou desavisados interceptem tráfego legítimo de outros serviços.

Por que essa mudança é um movimento estratégico de segurança?

Desde a versão 1.21, o projeto Kubernetes desencoraja o uso dessa funcionalidade. Por muito tempo, a comunidade priorizou a compatibilidade, mantendo o recurso como "inseguro por padrão". No entanto, a maturidade do ecossistema cloud-native consolidou alternativas superiores que não sacrificam a governança em nome da conveniência. A depreciação no v1.36 é o primeiro passo para a remoção total do suporte no kube-proxy, o que forçará conformidade em ambientes que hoje ignoram boas práticas de SecOps.

O que essa depreciação NÃO afeta?

É comum confundir terminologias no Kubernetes. É crucial notar que esta mudança afeta apenas o campo .spec.externalIPs definido nas especificações de um Service. Detalhes como o campo .status.addresses no recurso Node ou o comportamento de exibição de IPs em Services do tipo LoadBalancer no kubectl permanecem inalterados.

Quais são as alternativas para o seu ambiente?

Para times que dependem dessa funcionalidade, a migração não precisa ser traumática. Considere as seguintes rotas:

1. LoadBalancer Services com Controles de Acesso: Substitua o uso de externalIPs por serviços do tipo LoadBalancer. Ao gerenciar o IP via .status (e não .spec), você previne que usuários comuns alterem a configuração, restringindo a operação via RBAC.
2. Controladores de Load Balancer (Ex: MetalLB): Esta é a solução de governança ideal. Ao utilizar ferramentas como o MetalLB, o administrador define pools de IPs autorizados. Isso centraliza o controle, evita duplicidade (conflitos de IP) e garante que a atribuição de tráfego seja centralizada no time de Operações.
3. Gateway API: A recomendação de longo prazo é a transição para a Gateway API. Ela foi desenhada especificamente para superar as limitações do Ingress e dos Services tradicionais, oferecendo uma separação clara entre a definição de rede (Gateway) e a definição de rota (Routes), permitindo um controle RBAC muito mais granular.

Qual é o cronograma da depreciação?

• Kubernetes 1.36: O campo foi marcado como deprecated; logs e warnings de segurança serão emitidos.
• v1.40 (+1 ano): O suporte via kube-proxy será desativado por padrão, com mecanismos temporários de opt-in.
• v1.43 (+2 anos): Remoção completa e intransigente do campo.

Não espere pela desativação forçada. A antecipação de riscos operacionais através de políticas rigorosas de infraestrutura é o que diferencia empresas com alta estabilidade operacional.

Perguntas Frequentes

• Por que o .spec.externalIPs foi descontinuado?
  O campo permitia que usuários comuns do cluster reivindicassem IPs arbitrários sem privilégios de administrador, criando uma falha de segurança séria conhecida como CVE-2020-8554. A mudança visa eliminar esse comportamento 'inseguro por design'.

• Se eu não uso o campo, preciso me preocupar?
  Se o seu time não configurou o campo em nenhum Service, não há ação imediata. No entanto, é altamente recomendado habilitar o admission controller 'DenyServiceExternalIPs' para impedir que essa prática seja adotada inadvertidamente no futuro.

• O que devo usar no lugar do externalIPs?
  A recomendação é migrar para controladores de load balancer especializados para ambientes on-premise, como o MetalLB, ou adotar a moderna Gateway API, que oferece controle de acesso refinado (RBAC) para o gerenciamento de IPs.

---

Artigo originalmente publicado em Kubernetes Blog.