Duas falhas atingem o provedor Kubernetes Ingress NGINX na linha 3.7: uma desativa a exigência de certificado de cliente em um host e a outra permite usar o segredo de CA de outro namespace. A terceira atinge a implementação experimental FastProxy e derruba o processo do Traefik a partir de conexões atualizadas para WebSocket. Todas foram corrigidas em 3.7.15.
Aplicativo
Traefik
Data do compilado
Vulnerabilidades
3
As três falhas foram corrigidas em 3.7.15. A primeira foi introduzida em 3.7.11 junto com o compartilhamento de opções TLS entre Ingresses. A segunda existe desde 3.7.0, quando o suporte à anotação auth-tls-secret entrou no provedor. A terceira afeta apenas instalações com experimental.fastProxy ativado. A indicação de correção descreve as versões do projeto e não confirma a atualização da sua instância.
Gravidade altaCorreção disponível
Outro Ingress no mesmo host desativa a exigência de certificado de cliente
O provedor Kubernetes Ingress NGINX aplica a opção de TLS com autenticação mútua por Ingress, não por host. Quando um Ingress declara a anotação nginx.ingress.kubernetes.io/auth-tls-secret e outro Ingress do mesmo host declara um caminho sem a mesma configuração, o host fica com duas opções de TLS diferentes. O Traefik trata isso como conflito e volta às opções padrão, que não solicitam certificado de cliente, a menos que core.strictTLSOptions esteja ativado. Um cliente remoto sem certificado alcança os backends que deveriam exigir autenticação mútua. A falha existe desde 3.7.0, versão que introduziu a leitura dessa anotação.
Casos de uso afetados
Você usa o provedor Ingress NGINX com auth-tls-secret para proteger um host e mantém outro Ingress nesse mesmo host para um caminho público. O Ingress público remove a exigência de certificado do host inteiro e expõe o backend protegido.
Você separa aplicações por caminho no mesmo host e espera que cada uma tenha a própria política de certificado de cliente. A configuração por Ingress permite que um caminho sem a anotação altere o resultado do host.
Confira na sua instância
Liste os Ingresses que usam a anotação auth-tls-secret e agrupe por host. Procure outros Ingresses no mesmo host sem a mesma anotação. Confira se core.strictTLSOptions está ativado no Traefik e examine o log em nível ERROR para mensagens de conflito de opções TLS no host. Em ambiente de teste, acesse o backend protegido sem certificado de cliente e confirme que a conexão é recusada depois de atualizar para 3.7.15.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
3.7.x
>= v3.7.0-ea.1, <= v3.7.14
v3.7.15
O Traefik 2 e as versões 3 anteriores à 3.7.0 não são afetados, porque não interpretam a anotação auth-tls-secret. Ativar core.strictTLSOptions transforma o conflito em recusa de configuração e impede a queda para as opções padrão, sem substituir a atualização.
Gravidade altaCorreção disponível
Corrida no leitor compartilhado após upgrade HTTP/1 no FastProxy derruba o processo
No FastProxy experimental, depois que o backend aceita uma atualização de protocolo, como 101 Switching Protocols para WebSocket, o pool de conexões continua lendo da conexão do backend enquanto o copiador do túnel lê do mesmo leitor com buffer, sem sincronização entre os dois. Um cliente sem autenticação que abre e aborta conexões atualizadas repetidamente corrompe o estado interno do leitor e provoca um panic não recuperado, que encerra o processo do Traefik. O resultado é a indisponibilidade de todos os serviços atendidos por aquela instância.
Casos de uso afetados
Você ativou experimental.fastProxy e atende aplicações que usam WebSocket ou outro upgrade de protocolo. Um cliente sem credenciais pode encerrar o processo do Traefik repetindo conexões atualizadas e abortadas.
Você concentra vários domínios em uma única instância do Traefik com FastProxy. A queda do processo interrompe o acesso a todos os serviços daquela instância, e também ao backend que aceita o upgrade.
Confira na sua instância
Confira se experimental.fastProxy está ativado na configuração estática. Procure reinícios inesperados do processo e registros de panic no log do Traefik. Nos logs do backend, observe sequências de conexões atualizadas e abortadas em curto intervalo. Após atualizar para 3.7.15, mantenha uma rotina de abertura e cancelamento de conexões WebSocket em ambiente de teste e confirme que o processo permanece estável.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
3.2 a 3.7
>= v3.2.0, <= v3.7.14
v3.7.15
Apenas instalações com experimental.fastProxy ativado são afetadas. O Traefik 2 não é afetado, porque o FastProxy entrou na versão 3.2. As linhas 3.2 a 3.6 estão fora de manutenção e exigem atualização para uma versão corrigida da linha 3.7.
Gravidade baixaCorreção disponível
Cache de opções TLS ignora a checagem de namespace em auth-tls-secret
Com allowCrossNamespaceResources desativado, que é o padrão, a checagem de namespace sobre a anotação nginx.ingress.kubernetes.io/auth-tls-secret só acontece na primeira montagem da opção TLS de autenticação de cliente. Um Ingress posterior que referencie um segredo de CA já usado por outro Ingress reutiliza a opção compartilhada sem passar pela checagem. Um usuário autorizado a criar Ingresses em um namespace pode impor o segredo de CA de outro namespace como autoridade de certificado de cliente das próprias rotas, furando o isolamento configurado e descobrindo se aquele segredo existe e está em uso. O conteúdo do segredo não é revelado.
Casos de uso afetados
Você permite que locatários criem Ingresses nos próprios namespaces e mantém allowCrossNamespaceResources desativado. Uma locatário pode referenciar um segredo de CA de outro namespace e conferir se ele existe pela resposta do Ingress.
Você compartilha um segredo de CA entre aplicações e espera que a separação por namespace seja mantida pela checagem do provedor. A primeira montagem da opção TLS vale para Ingresses de outros namespaces.
Confira na sua instância
Confira o valor de allowCrossNamespaceResources no provedor e a versão instalada. Procure Ingresses que usem auth-tls-secret em mais de um namespace e compare as referências com os segredos existentes. Examine os eventos e os logs do provedor para reutilização de opções TLS entre Ingresses. Em ambiente de teste, crie um Ingress em um namespace que referencie o segredo de CA de outro e confirme, depois da atualização para 3.7.15, que a referência é recusada.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
3.7.x
>= v3.7.11, <= v3.7.14
v3.7.15
A falha foi introduzida em 3.7.11, quando as opções TLS de autenticação de cliente foram compartilhadas entre Ingresses. Versões anteriores não são afetadas e o Traefik 2 não tem esse provedor.
Programador há mais de 20 anos, fundador da Powertic e da Promovaweb. Embaixador do n8n no Brasil e da Baserow, Chatwoot, Miro e Kestra. Membro do Product Team do Mautic.
Canais oficiais
Nossos Links
Encontre a Promovaweb no canal que combina com o seu próximo passo.
