← Todas as notícias
ARTIGO
17 de outubro de 2026 Atualizado em 23 de setembro de 2026 2 min de leitura

Tetragon traz segurança de runtime eBPF no kernel para frotas cloud-native

O Tetragon, projeto eBPF da Cilium/CNCF, adiciona observabilidade de runtime com consciência Kubernetes e aplicação de políticas no kernel, dando aos MSP deteção além dos scanners estáticos.

Neste artigo
  1. Aplicação que corre dentro do kernel
  2. Onde se enquadra junto dos controlos existentes
  3. Um complemento para a higiene de segredos

O Tetragon, um subprojeto da Cilium e um projeto da Cloud Native Computing Foundation, oferece às equipas com consciência Kubernetes observabilidade de runtime e aplicação opcional de políticas no kernel, com base em eBPF. Para os fornecedores de serviços geridos que operam frotas mistas de clientes, adiciona uma camada de deteção e controlo que fica abaixo do que os scanners de contentores e os controladores de admissão conseguem ver.

Um corredor frio de um centro de dados com paredes brancas, ladeado por altos armários de servidores com portas de tela
Foto: Eclipse55 (CC BY-SA 4.0), Wikimedia Commons.

Aplicação que corre dentro do kernel

Ao contrário das ferramentas que enviam todos os eventos para o espaço do utilizador antes de decidir o que fazer, o Tetragon filtra e aplica políticas diretamente dentro do programa eBPF que observa a syscall. Isso fecha a janela entre a deteção e a ação que as ferramentas apenas em espaço de utilizador deixam aberta e mantém a sobrecarga suficientemente baixa para uso em produção. O projeto consegue rastrear a execução de processos, o acesso a ficheiros e a atividade de rede, e depois ligar cada evento ao pod e ao contentor que o produziu, sem um sidecar por carga de trabalho.

Onde se enquadra junto dos controlos existentes

O Tetragon não substitui o scanning de imagens nem os gates de CI; cobre o que acontece depois de uma workload já estar em execução. Uma implementação prática começa em pequena escala: inventariar quais os namespaces que já têm uma TracingPolicy aplicada e depois alargar a cobertura primeiro às workloads críticas dos clientes. As políticas pertencem ao controlo de versões como qualquer outra configuração, para que as alterações passem pela mesma revisão que o código.

  • Comece com políticas apenas de alerta em namespaces sensíveis antes de ativar a aplicação com bloqueio.
  • Observe a execução inesperada de processos e o acesso a ficheiros sensíveis como primeiras regras de deteção.
  • Encaminhe os eventos do Tetragon para o SIEM já utilizado para outros alertas da frota.
  • Mantenha as definições de políticas em git para que as alterações sejam revistas como código.

Um complemento para a higiene de segredos

O Tetragon observa workloads em execução; não verifica o que já está registado num repositório. O TruffleHog, uma ferramenta de código aberto amplamente utilizada para o scanning de segredos, preenche essa lacuna ao encontrar e verificar credenciais no código antes de chegarem à produção. Executá-lo em CI em cada pull request e verificar as descobertas antes de qualquer rotação mantém as duas ferramentas focadas em fases diferentes do mesmo problema.

Nenhuma das ferramentas substitui a outra. A combinação da aplicação em runtime com o scanning de segredos antes do commit dá aos MSP cobertura em ambas as extremidades do pipeline sem adicionar detalhes de ataque à documentação virada para o cliente.

Fontes: Documentação do Tetragon, GitHub — cilium/tetragon.