Fim da vida útil do Apache Kafka: mantenha sua infraestrutura de streaming segura | TuxCare ELS

O Apache Kafka é a espinha dorsal da infraestrutura de dados em tempo real para milhares de organizações em todo o mundo. Sua arquitetura de alta taxa de transferência e tolerante a falhas o tornou a escolha padrão para streaming de eventos, pipelines de dados e mensagens de missão crítica em diversos setores, desde serviços financeiros até comércio eletrônico. No entanto, o ritmo acelerado de lançamento do Kafka faz com que os períodos de suporte às versões terminem muito mais rápido do que a maioria das equipes corporativas espera; e, quando chega a data de fim de vida útil (EOL) do Apache Kafka, o impacto vai muito além do próprio broker.

Este artigo explica o que o fim do ciclo de vida do Kafka realmente significa para as equipes de infraestrutura de dados, onde se esconde o verdadeiro risco à segurança, por que o caminho de atualização para o Kafka 4.0 é mais exigente do que uma atualização de versão comum e como o Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare permite que você mantenha cobertura total de segurança e conformidade sem forçar uma atualização para a qual suas equipes ainda não estejam preparadas.

Principais conclusões

• As dependências multiplicam sua superfície de vulnerabilidade: Quando uma versão do Kafka chega ao fim de sua vida útil, você fica preso às versões específicas das dependências que a acompanham. Essas versões fixadas, com o tempo, ficam fora dos períodos de suporte de seus fornecedores originais, deixando você exposto a vulnerabilidades sem correção e sem um caminho direto para atualização.
• Atualizações apressadas são caras e arriscadas: A transição do Kafka 3.x para o 4.x exige a migração obrigatória do ZooKeeper para o KRaft, atualizações da versão do Java, alterações na compatibilidade da API do protocolo e a remoção de ferramentas, o que requer um planejamento cuidadoso e testes extensivos, e não prazos apertados.
• O fim do ciclo de vida (EOL) do Apache Kafka não significa o fim da segurança: O TuxCare ELS amplia a cobertura de segurança para essas versões em fim de vida e suas árvores de dependências, para que as organizações possam manter a segurança e a conformidade enquanto planejam uma atualização deliberada e com recursos adequados, seguindo seu próprio cronograma.

O que é o ciclo de vida do produto Apache Kafka?

O Kafka segue um cronograma de lançamentos baseado em prazos, estabelecido em 2016. A comunidade publica uma nova versão secundária aproximadamente a cada quatro meses, resultando em cerca de três versões por ano. A cada versão é atribuído um ramo com numeração específica, por exemplo, 3.7, 3.8, 3.9, 4.0, com seu próprio fluxo de correções.

A comunidade oferece suporte às três últimas versões secundárias a qualquer momento, o que significa um período de suporte de aproximadamente 12 a 16 meses por versão. O Kafka não divulga antecipadamente datas formais de fim de vida útil; uma versão atinge efetivamente o status de fim de vida útil (EOL) do Apache Kafka quando é retirada da lista de versões suportadas na página oficial de downloads, à medida que versões mais recentes são lançadas. Na prática, isso significa que, a cada quatro meses, uma versão perde o suporte da comunidade sem grande aviso prévio.

O cronograma atual de suporte às versões do Kafka:

Observação: a Kafka não divulga datas oficiais de fim de vida útil (EOL). Esses prazos são calculados com base na política de suporte contínuo da comunidade para três versões consecutivas e nos intervalos aproximados de quatro meses entre os lançamentos.

Esse ritmo é agressivo para os padrões corporativos. Organizações em setores regulamentados, ou que operam infraestruturas complexas de fluxos de dados — nas quais as atualizações exigem ciclos de validação prolongados —, frequentemente se veem utilizando versões que já ultrapassaram discretamente sua data de fim de vida útil (EOL) antes que uma atualização planejada esteja pronta para ser executada.

O que o fim da vida útil (EOL) do Apache Kafka significa para a infraestrutura de dados?

Para um servidor de aplicativos simples, chegar ao fim da vida útil significa que o sistema deixa de receber correções. Para organizações que utilizam o Kafka como o sistema nervoso central de sua infraestrutura de dados, conectando produtores, consumidores, pipelines do Kafka Connect, aplicativos do Kafka Streams e sistemas de análise a jusante, o quadro é estruturalmente diferente e significativamente mais complexo.

Não haverá mais patches de segurança após a data de fim de vida útil (EOL)

Quando uma versão do Kafka chega ao fim de vida útil (EOL), a comunidade Apache deixa de publicar correções de segurança para ela. Qualquer vulnerabilidade divulgada após a data de EOL, seja no próprio broker, no worker do Kafka Connect ou nas bibliotecas de cliente, não receberá um patch oficial para essa versão. A única solução oferecida pela comunidade é a atualização para uma versão com suporte.

Para equipes que operam grandes clusters do Kafka, essenciais para a produção, nos quais as atualizações exigem testes prolongados, validação coordenada do pipeline e sequenciamento cuidadoso da implantação, isso nem sempre é uma opção em curto prazo. O intervalo entre o momento em que o status de fim de vida útil (EOL) entra em vigor e o momento em que uma atualização pode, de fato, ser concluída e validada é exatamente quando se acumulam vulnerabilidades não corrigidas.

Riscos de segurança e conformidade após o fim da vida útil

As consequências em termos de conformidade decorrentes da utilização de uma versão do Kafka em fim de vida (EOL) são diretas. A norma PCI DSS (Requisito 6.3.3) exige que patches críticos e de alta gravidade sejam instalados no prazo de um mês a partir do lançamento do patch; no entanto, em uma versão do Apache Kafka em fim de vida, não há patches para instalar, o que torna impossível a conformidade por meios normais. Os auditores SOC 2 sinalizam a presença de software em fim de vida útil em ambientes de produção. Executar um cluster do Kafka em uma versão sem suporte cria lacunas na documentação que vêm à tona em questionários de segurança, atrasam as certificações de fornecedores e, em setores regulamentados, impedem a renovação de contratos com clientes.

Para organizações nas quais o Kafka está incluído no escopo da PCI, processa informações de identificação pessoal ou sustenta serviços com obrigações contratuais de SLA, o risco de não conformidade decorrente desse evento de fim de vida útil (EOL) não é meramente teórico. Trata-se de uma constatação de auditoria prestes a se concretizar.

Histórico do CVE: o que o registro de vulnerabilidades revela

O histórico de vulnerabilidades CVE do Kafka ilustra o tipo de vulnerabilidade que fica permanentemente sem correção em versões que chegaram ao fim do ciclo de vida.

CVE-2023-25194 (NVD CVSS 3.1: 8,8 – Alto) expôs um vetor de execução remota de código e negação de serviço no Kafka Connect. Ao configurar as propriedades SASL JAAS do cliente Kafka de um conector para referenciar um servidor LDAP malicioso, um operador autenticado poderia acionar a desserialização de dados não confiáveis no worker do Connect, permitindo a execução de código arbitrário caso houvesse gadgets disponíveis no classpath. Isso afetou clusters do Kafka desde a versão 2.3.0, e a vulnerabilidade foi grave o suficiente para gerar boletins de segurança da IBM para vários produtos, incluindo o IBM Maximo Application Suite e o IBM Business Automation Workflow. A correção exigiu a atualização para versões corrigidas; versões mais antigas, fora do ciclo de vida, que executavam o Kafka Connect permaneceram expostas, sem nenhum caminho oficial de correção disponível.

CVE-2025-27819 (NVD CVSS 3.1: 7,5 – Alta) é uma continuação da vulnerabilidade CVE-2023-25194, revelando que a mesma vulnerabilidade do módulo JndiLoginModule do SASL JAAS existia nos brokers do Kafka, e não apenas no Kafka Connect, afetando as versões 2.0.0 a 3.3.2. O ataque requer acesso à rede do cluster e a permissão AlterConfigs no recurso do cluster. Uma exploração bem-sucedida permite que um invasor estabeleça conexões arbitrárias com um servidor LDAP controlado por ele e provoque condições de negação de serviço. A vulnerabilidade foi divulgada publicamente em junho de 2025, e a correção que desativa os módulos de login problemáticos por padrão só foi disponibilizada nas versões 3.9.1 e 4.0.0. Os ramos em fim de vida útil não receberam nenhuma correção.

Essa é exatamente a categoria de vulnerabilidades relacionadas a vetores de RCE autenticados na infraestrutura central do Kafka, cuja correção exige atualizações de versão, o que se torna uma exposição permanentemente não resolvida nas versões em fim de vida (EOL).

O risco oculto: a árvore de dependências do Kafka

A superfície de vulnerabilidade de uma implantação do Kafka não se limita ao binário do broker. O Kafka vem com um conjunto substancial de dependências que trazem seus próprios riscos de segurança e, quando o Kafka chega ao fim da vida útil (EOL), o problema não é que esses projetos upstream deixem de disponibilizar patches. O problema é que você fica preso às versões específicas das dependências que a versão do Kafka em fim de vida fixou, e essas versões fixadas, com o tempo, ficam fora dos períodos de suporte dos próprios projetos upstream.

A biblioteca `kafka-clients`, por si só, depende de bibliotecas de compactação, incluindo `snappy-java`, `LZ4-java` e `zstd-jni`. O broker e o Kafka Connect dependem do `Jackson Databind` e de módulos relacionados do Jackson para processamento de JSON, do `Netty` para transporte de rede e do `slf4j` com o `Log4j2` para registro em log. Versões anteriores do Kafka dependiam do Apache ZooKeeper, um projeto que, por sua vez, possui seu próprio histórico de vulnerabilidades (CVE) para gerenciamento de metadados de cluster. As ferramentas do broker incluem o RocksDB para armazenamento de estado do Kafka Streams, e a biblioteca padrão completa do Scala é fornecida como uma dependência de tempo de execução.

Cada uma dessas dependências possui seu próprio fluxo de CVE de origem. A biblioteca snappy-java, por exemplo, esteve diretamente envolvida no CVE-2023-34455 (NVD CVSS 3.1: 7,5 Alta), uma vulnerabilidade de negação de serviço que afetou as versões 0,8.0 a 3,5.0 do Kafka, na qual uma carga maliciosa compactada com o snappy-java poderia fazer com que os brokers alocassem quantidades arbitrariamente grandes de memória heap, levando a uma exceção OutOfMemoryException e a uma negação de serviço em todo o cluster. O Jackson Databind gerou dezenas de CVEs de alta gravidade ao longo de sua história, relacionados à deserialização insegura. O Netty possui seu próprio histórico de vulnerabilidades na camada de rede.

Quando uma versão do Kafka atinge o status de EOL, você deixa de receber lançamentos do Kafka que atualizam essas versões de dependências para você. Você fica limitado às versões fixadas pela versão do Kafka em EOL, e essas versões específicas também podem, eventualmente, deixar de receber correções retroativas de seus próprios projetos upstream. O resultado é o mesmo: os scanners de vulnerabilidades executados em implantações do Kafka em EOL geram resultados em toda a árvore de dependências que não têm um caminho direto para correção, deixando as equipes de segurança com uma lista crescente de resultados de varredura sem solução e sem um caminho de atualização compatível dentro da versão em EOL.

Opções para manter a segurança e a conformidade

As organizações que utilizam versões do Apache Kafka em fim de vida útil (EOL) têm duas opções à disposição. Uma delas envolve um esforço significativo de engenharia, risco operacional e prazos prolongados. Já a segunda, o Suporte de Ciclo de Vida Ilimitado da TuxCare, elimina imediatamente a lacuna de segurança.

Opção 1: Atualizar para a versão atual do Kafka

A solução a longo prazo é atualizar o cluster do Kafka para uma versão atualmente suportada. As versões atualmente com suporte ativo incluem o Kafka 3.9, 4.0, 4.1 e 4.2, cada uma delas com cobertura contínua de patches.

A realidade prática, especialmente para a transição da versão 3.x para a 4.x, é que essa é uma das atualizações mais exigentes da história do Kafka. O Kafka 4.0 remove completamente o suporte ao ZooKeeper; os clusters que ainda operam no modo ZooKeeper devem concluir a migração de metadados do ZooKeeper para o KRaft antes de poderem atualizar para a versão 4.0 ou qualquer versão posterior. Para clusters em versões mais antigas do Kafka, o caminho de migração pode exigir várias etapas intermediárias: atualizar para a versão 3.4, atualizar o ZooKeeper para a versão 3.8, atualizar para a versão 3.9, executar a migração de metadados do ZooKeeper para o KRaft e, então, prosseguir para a versão 4.0. O Kafka 4.0 também deixa de oferecer suporte ao Java 8 por completo e exige o Java 17 para brokers e ferramentas, descontinua o MirrorMaker 1 sem um caminho de migração direto, remove versões obsoletas da API do protocolo de cliente e remove a API transformValues() do Kafka Streams. Cada uma dessas mudanças precisa ser tratada antes que a atualização possa prosseguir. Para organizações que operam grandes infraestruturas de Kafka, dando suporte a várias equipes e pipelines, uma atualização para a versão 4.x devidamente planejada leva meses, não semanas.

Opção 2: Suporte de ciclo de vida estendido da TuxCare: o caminho recomendado

Essa é a opção que resolve o problema imediato sem criar novos problemas. O Suporte de Ciclo de Vida Ilimitado da TuxCare para o Kafka significa que você continua executando sua versão atual do Kafka em produção, ao mesmo tempo em que recebe cobertura contínua de patches de segurança para o broker e sua árvore de dependências, fornecida por meio de sua cadeia de ferramentas existente, sem a necessidade de migração forçada.

A falha de segurança é corrigida imediatamente. Sua conformidade é mantida. Suas equipes têm liberdade para planejar a atualização adequada em um cronograma que faça sentido do ponto de vista operacional, incluindo o tempo necessário para executar corretamente a migração do ZooKeeper para o KRaft, validar a compatibilidade das versões do Java em toda a sua pilha de aplicativos e coordenar a implantação em todos os serviços produtores e consumidores que dependem do seu cluster do Kafka. Sem atualizações forçadas sob pressão de prazos, sem emergências de conformidade, sem falhas de compatibilidade na infraestrutura de produção que sustenta os pipelines de dados em tempo real.

Os riscos de apressar uma atualização do Kafka

Quando um status de EOL é registrado em um painel de segurança e a equipe de conformidade começa a fazer perguntas, a pressão para agir imediatamente é real. Entender o que uma atualização apressada do Kafka realmente implica é tão importante quanto compreender a própria vulnerabilidade.

O que uma atualização do Kafka realmente envolve

Uma atualização adequada do Kafka, especialmente da versão 3.x para a 4.x, é um projeto de infraestrutura em várias fases, e não apenas uma mudança de versão. Isso requer o planejamento do caminho de atualização com base na sua versão atual e no modo de metadados, a execução de quaisquer atualizações intermediárias necessárias, a conclusão da migração do ZooKeeper para o KRaft, se aplicável, a realização de reinicializações contínuas dos brokers em todo o cluster, a validação de que todos os aplicativos clientes permaneçam compatíveis com a nova versão do broker, a verificação de que todos os conectores do Kafka Connect funcionem corretamente no cluster atualizado, o teste dos aplicativos do Kafka Streams em relação a quaisquer alterações na API e a execução de implementações coordenadas nos ambientes de desenvolvimento, teste e produção.

Adaptação de código: O Kafka 4.0 remove APIs obsoletas, incluindo transformValues() no Kafka Streams e versões legadas da API de protocolo. Os aplicativos que utilizam qualquer uma das APIs removidas devem ser atualizados antes que a atualização do cluster possa prosseguir.

Verificação de compatibilidade: Todos os produtores, consumidores, conectores do Kafka Connect e aplicativos do Kafka Streams no ecossistema precisam ser verificados quanto à compatibilidade com a versão-alvo do Kafka. Um único cliente ou conector incompatível pode causar falhas no pipeline de dados que afetam os sistemas a jusante.

Adaptação da cadeia de ferramentas: Os pipelines de CI/CD, os scripts de implantação, as configurações de monitoramento e as definições de infraestrutura como código que fazem referência a configurações específicas do Kafka precisam ser revisados e atualizados, especialmente em relação às alterações de configuração do KRaft que consolidam o diretório kraft/config no diretório config principal na versão 4.0.

Carga de testes: Não se pode ignorar a realização de testes de integração abrangentes em todo o pipeline, desde os produtores, passando pelos intermediários, até os consumidores. Mudanças no comportamento do reequilíbrio, novas implementações de coordenadores de grupo e alterações na versão do protocolo precisam ser validadas sob carga realista antes da implantação em produção.

O que acontece quando uma atualização é feita às pressas

Quando as equipes concentram esse trabalho sob a pressão de prazos, as consequências são previsíveis e seguem um padrão consistente.

Aumento da carga de suporte: Problemas de compatibilidade não detectados durante os testes intensivos vêm à tona na produção. Picos de atraso no consumidor, falhas nos conectores e comportamentos inesperados de reequilíbrio geram uma onda de incidentes que as equipes de engenharia e operações precisam absorver, além das cargas de trabalho normais.

Instabilidade do sistema: Os clusters do Kafka sustentam os fluxos de dados dos quais os sistemas a jusante dependem. Mudanças sutis de comportamento introduzidas por uma atualização na atribuição de partições, na coordenação de grupos de consumidores e no tratamento do armazenamento de estado do Kafka Streams podem causar falhas intermitentes que são difíceis de reproduzir e que se manifestam sob volumes de dados de produção que os ambientes de pré-produção raramente alcançam.

Acúmulo de dívida técnica: Soluções provisórias implementadas sob pressão de tempo tornam-se permanentes. Os aplicativos são adaptados rapidamente para passar nas verificações de compatibilidade, em vez de acumular adequadamente as suposições que geram problemas para o próximo ciclo de atualização. O problema do fim de vida útil (EOL) do Apache Kafka é adiado, não resolvido.

Custos não planejados: Horas extras de engenharia para emergências, atrasos no lançamento de funcionalidades, despesas indiretas com resposta a incidentes e o custo de oportunidade de engenheiros de dados sênior dedicarem-se à depuração de falhas no pipeline de produção, em vez de desenvolverem novos recursos — tudo isso se acumula rapidamente e de maneiras difíceis de prever com antecedência.

A solução fácil: TuxCare ELS para o Apache Kafka EOL

A TuxCare oferece suporte contínuo ao ciclo de vida para versões do Kafka em fim de vida útil. Em vez de forçar uma atualização do cluster para a qual suas equipes ainda não estão preparadas, você continua operando sua implantação atual em fim de vida útil com cobertura contínua de patches de segurança, fornecida por meio de sua cadeia de ferramentas de compilação e implantação já existente.

A TuxCare vem fazendo isso há mais de uma década, fornecendo patches de segurança para sistemas operacionais, ambientes de execução, bibliotecas e estruturas de aplicativos que chegaram ao fim de vida útil. A empresa já distribuiu mais de 220.000 patches de segurança em todo o ecossistema de código aberto. Quando afirmam que sabem como manter versões em fim de vida útil seguras em escala empresarial, isso não é apenas discurso de marketing. Eles têm feito isso em grande escala, de forma consistente.

Cobertura completa da árvore de dependências: O ELS da TuxCare para o Apache Kafka abrange o broker e suas dependências diretas e transitivas, incluindo snappy-java, Jackson Databind, Netty e outras bibliotecas que apresentam suas próprias vulnerabilidades CVE, sem custo adicional. Os scanners de vulnerabilidades não respeitam os limites dos pacotes, e a cobertura da TuxCare também não. Toda a área de aplicação de patches é abordada, não apenas os pacotes de nível superior do Kafka.

Processo refinado e automatizado de aplicação de patches: A TuxCare monitora o NVD, os alertas de segurança dos fornecedores, a lista de CVEs do próprio Apache e os feeds de segurança do GitHub — todos os canais onde vulnerabilidades do Kafka e de suas dependências são divulgadas. Quando um CVE é identificado, ferramentas algorítmicas e automação assistida por IA se encarregam de aplicar as correções de segurança à versão suportada, e especialistas em segurança validam cada patch antes de sua distribuição. Cada atualização passa por testes de integridade, funcionalidade e regressão antes de chegar aos seus repositórios. Para obter detalhes técnicos completos, consulte o white paper técnico da TuxCare sobre seu processo de aplicação de patches em código aberto.

Integração perfeita: Os pacotes ELS da TuxCare integram-se diretamente ao Maven, ao Gradle e a outras ferramentas padrão de compilação e gerenciamento de dependências em Java já utilizadas nas implantações do Kafka. Não há alterações no seu pipeline de compilação, nos seus fluxos de trabalho de CI/CD nem na forma como suas equipes trabalham. Você migra para o repositório seguro da TuxCare com alterações mínimas na configuração, e as atualizações de segurança são distribuídas automaticamente por toda a sua cadeia de ferramentas existente.

Resposta rápida garantida por SLA: Quando novas vulnerabilidades são divulgadas em versões do Kafka em fim de vida (EOL), seja no próprio broker ou em sua árvore de dependências, a TuxCare fornece patches dentro de um prazo garantido, respaldado por acordos de nível de serviço. Vulnerabilidades de gravidade alta e crítica (CVSS 7+) são corrigidas em até 14 dias após a divulgação pública. Você não precisa esperar por um backport da comunidade que talvez nunca chegue para uma versão do Apache Kafka em fim de vida útil (EOL). Você recebe patches prontos para produção em um cronograma que permite seu planejamento, com suporte especializado 24 horas por dia, 7 dias por semana, para triagem de vulnerabilidades e solução de problemas.

Continuidade de segurança com boa relação custo-benefício: O custo do TuxCare ELS é uma fração do que custa uma migração de cluster de emergência quando imposta por um prazo de conformidade, considerando o tempo de engenharia, o risco operacional, a resposta a incidentes e o atraso no plano de trabalho. Cobertura de segurança previsível, um cronograma de atualizações controlado e a ausência de emergências de conformidade são o que tornam o suporte estendido a estratégia de nível empresarial para gerenciar a exposição ao fim da vida útil (EOL) do Apache Kafka.

Para saber exatamente quais vulnerabilidades foram corrigidas nessas versões com fim de vida útil (EOL), a TuxCare mantém uma rrastreador CVE em tempo real para todas as tecnologias em fim de vida (EOL) suportadas.

Não deixe que o fim da vida útil do Apache Kafka coloque seus pipelines de dados em risco

O fim do ciclo de vida (EOL) do Apache Kafka não significa que seu cluster esteja imediatamente comprometido, nem que você precise realizar uma migração de emergência para a qual suas equipes não estejam preparadas. Mas significa que a cobertura de segurança da qual sua infraestrutura de streaming dependia não existe mais, e essa lacuna precisa ser gerenciada de forma deliberada.

As organizações que lidam bem com isso são aquelas que tratam o fim da vida útil (EOL) do Apache Kafka como um problema de segurança a ser gerenciado, e não como um prazo ao qual se deve reagir sob pressão. É possível planejar uma atualização deliberada para uma versão atual do Kafka quando isso realmente se encaixar na capacidade da sua equipe, incluindo o tempo adicional necessário para executar corretamente a migração do ZooKeeper para o KRaft e validar a compatibilidade dos clientes em todo o seu ecossistema de pipeline. É possível avaliar se uma migração de plataforma atende a um objetivo arquitetônico real. Ou você pode usar o TuxCare ELS para manter total segurança e conformidade enquanto toma essas decisões de acordo com seu próprio cronograma, e não com o de um auditor de conformidade.

O suporte estendido não é uma solução provisória. É a opção que mantém sua infraestrutura do Kafka segura, sua conformidade intacta e suas equipes de engenharia focadas no desenvolvimento, e não em resolver problemas urgentes. Se o fim da vida útil (EOL) do Apache Kafka estiver em seu radar de segurança neste momento, acesse Suporte de Ciclo de Vida Ilimitado da TuxCare para Software de Código Aberto para ver como o suporte estendido pode proteger sua infraestrutura de streaming pelo tempo que você precisar.

Resumo

Nome do artigo

Fim da vida útil do Apache Kafka: mantenha seus pipelines de dados seguros

Descrição

Está executando o Apache Kafka EOL em produção? Mantenha a segurança e a conformidade sem precisar fazer uma migração forçada. O TuxCare ELS amplia a segurança além do fim da vida útil.

Autor

Muzzammil Hasann

Nome da editora

TuxCare

Logotipo da editora