O ingress-nginx não recebe patch de segurança desde março de 2026.
Ele continua funcionando, e é por isso que o risco passa despercebido.
A saída recomendada pelo próprio Kubernetes é a Gateway API, e o Envoy Gateway é uma das implementações dela. A tentação é tratar a migração como tradução: pegar cada anotação e reescrever no formato novo. Só que a migração não se resume a trocar YAML.
No nginx, cada app levava a própria regra de IP numa anotação. No Envoy, a regra sobe para uma SecurityPolicy no Gateway compartilhado. Ela muda de dono: sai do time da app e vai para a plataforma. Um erro, que antes afetava uma app, agora afeta todas as rotas.
Ela também muda de camada. A allowlist por IP é uma decisão de L3 tomada em L7. O proxy filtra o IP que ele acredita ser o do cliente. Se houver SNAT no caminho, todo mundo vira o IP do node. Se o X-Forwarded-For for aceito sem critério, qualquer um escreve o próprio IP.
Abaixo, os pontos que a documentação confirma e que eu teria errado se só traduzisse as anotações: SNAT, precedência por substituição, CIDR largo copiado e o API gateway que vira o único cliente.
Qual regra de acesso sumiu, ou abriu demais, numa migração que parecia só de ferramenta no seu ambiente?
Referências
- Kubernetes Blog, aposentadoria do Ingress NGINX (11/11/2025)
- Gateway API
- Envoy Gateway, restringir acesso por IP
- Envoy Gateway, Client Traffic Policy (X-Forwarded-For, Proxy Protocol)
- Envoy Gateway, SecurityPolicy (precedência e mergeType)
- Envoy Gateway, API extension types
- ingress-nginx, Annotations
- Kubernetes, preservar o IP de origem do cliente
- Microsoft Learn, Standard Load Balancer no AKS
Top comments (0)