Em 25 de outubro de 2023, o Instituto Nacional de Padrões e Tecnologia (NIST) relatou três CVEs que afetavam o NGINX Ingress Controller for Kubernetes:
- CVE-2022-4886 – a sanitização de caminhos do ingress-nginx pode ser contornada com a diretiva
log_format. - CVE-2023-5043 – a injeção de anotações no ingress-nginx permite a execução arbitrária de comandos.
- CVE-2023-5044 – A injeção de código ocorre por meio da anotação nginx.ingress.kubernetes.io/permanent-redirect.
Esse relatório e as publicações subsequentes (como Urgente: novas falhas de segurança descobertas no NGINX Ingress Controller para Kubernetes) causaram certa confusão (e diversas consultas ao suporte) sobre quais controladores NGINX Ingress são realmente afetados e quem deve se preocupar em corrigir as vulnerabilidades descritas por essas CVEs.
A confusão é totalmente compreensível — você sabia que existe mais de um controlador Ingress baseado no NGINX? Para começar, há dois projetos completamente diferentes chamados “NGINX Ingress Controller”:
- Projeto da comunidade – Encontrado no repositório kubernetes/ingress-nginx no GitHub, esse controlador de Ingress é baseado no plano de dados do NGINX Open Source, mas é desenvolvido e mantido pela comunidade do Kubernetes, com a documentação hospedada no GitHub.
- Projeto NGINX – Encontrado no repositório nginxinc/kubernetes-ingress no GitHub, o NGINX Ingress Controller é desenvolvido e mantido pela F5 NGINX, com documentação em docs.nginx.com. Este projeto oficial do NGINX está disponível em duas edições:
- Baseado no NGINX Open Source (opção gratuita e de código aberto)
- Baseado no NGINX Plus (opção comercial)
Também existem outros controladores Ingress baseados no NGINX, como o Kong. Felizmente, é fácil diferenciá-los pelos nomes. Se você não tiver certeza de qual está usando, verifique a imagem do contêiner do controlador Ingress em execução e compare o nome da imagem do Docker com os repositórios listados acima.
As vulnerabilidades (CVE-2022-4886, CVE-2023-5043 e CVE-2023-5044) descritas acima aplicam-se somente ao projeto da comunidade (kubernetes/ingress-nginx). Os projetos da NGINX para o NGINX Ingress Controller (nginxinc/kubernetes-ingress, tanto de código aberto quanto comercial) não são afetados por essas CVEs.
Para saber mais sobre as diferenças entre os projetos NGINX Ingress Controller e Ingress controller, leia nosso artigo no blog Guia para escolher um Ingress Controller, parte 4: opções do NGINX Ingress Controller.
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.