Falco vs Tetragon: Segurança de Runtime para Kubernetes em 2026

Atualizado: 09 de junho de 2026

Falco e Tetragon são as duas principais ferramentas de segurança de runtime para Kubernetes em 2026. Falco (graduado na CNCF) é um motor de detecção baseado em regras que observa syscalls via eBPF e gera alertas, enquanto Tetragon (do projeto Cilium, também na CNCF) usa eBPF com hooks LSM para detecção e aplicação síncrona no kernel, podendo terminar processos antes que uma syscall maliciosa retorne. Se você só precisa observar, Falco está mais maduro; se precisa bloquear ataques em tempo real com sobrecarga mínima, Tetragon tem a arquitetura mais avançada.

• Falco 0.39 (lançado em janeiro de 2026) usa o driver eBPF moderno como padrão e descontinuou completamente o módulo de kernel legado a partir da versão 0.38.
• Tetragon 1.3 oferece TracingPolicy com ação Sigkill, capaz de matar processos no kernel antes que uma syscall complete (algo que Falco não faz nativamente).
• Ambas exigem kernel Linux 5.8+ para eBPF CO-RE; Tetragon também depende de hooks LSM-BPF (kernel 5.7+) para aplicação.
• Falco tem cerca de 150 regras prontas e ecossistema grande (Falcosidekick, plugins). Tetragon tem menos regras prontas, mas integra nativamente com Cilium para política de rede.
• A sobrecarga de CPU típica é <3% para ambas em cargas normais; Tetragon costuma ser ligeiramente menor por filtrar eventos no kernel antes de enviá-los ao espaço de usuário.
• A escolha não precisa ser exclusiva: muitas equipes rodam Falco para alertas amplos e Tetragon para enforcement em namespaces sensíveis.

Comparação rápida: Falco vs Tetragon

A tabela abaixo resume as diferenças que mais importam quando você está avaliando essas ferramentas para um cluster de produção. Eu mantenho essa comparação atualizada com base nos lançamentos mais recentes: Falco 0.39 (janeiro/2026) e Tetragon 1.3 (março/2026). Vale notar que ambos os projetos estão sob a CNCF, mas em estágios distintos de maturidade. Falco graduou em 2024, enquanto Tetragon ainda está em incubação. Isso afeta principalmente a estabilidade da API e o tamanho do ecossistema de regras prontas, não a qualidade técnica do código em si.

Critério	Falco	Tetragon
Mantenedor	Sysdig / CNCF (graduado)	Isovalent / Cilium / CNCF (incubação)
Versão estável (jun/2026)	0.39.x	1.3.x
Modelo de detecção	Regras YAML sobre syscalls	TracingPolicy CRD baseado em eBPF
Enforcement (bloqueio)	Apenas alertas (sem kill nativo)	Sim, ação Sigkill via LSM-BPF
Kernel mínimo	5.8+ (eBPF CO-RE)	5.8+; LSM-BPF para enforcement
Regras prontas	~150 (falco-rules)	~40 (incluindo exemplos Sigkill)
Integração nativa	Falcosidekick, plugins, Prometheus	Cilium, Hubble, política de rede L7
Sobrecarga típica	2–4% CPU	1–3% CPU
Curva de aprendizado	Moderada (sintaxe própria)	Íngreme (CRDs, eBPF, LSM)

O que é Falco e como funciona?

Falco é um motor de detecção de ameaças em runtime que graduou na CNCF em fevereiro de 2024. Ele observa chamadas de sistema (syscalls) no kernel Linux, compara cada evento contra um conjunto de regras declarativas em YAML, e gera alertas quando algo suspeito acontece. Por exemplo, um shell sendo executado dentro de um contêiner ou uma escrita inesperada em /etc/passwd.

A partir do Falco 0.38, o projeto removeu completamente o módulo de kernel legado, e a 0.39 consolida o driver eBPF moderno como padrão. Isso elimina a necessidade de compilar módulos para cada versão de kernel (uma dor histórica em frotas heterogêneas). A arquitetura é direta: um programa eBPF anexado a tracepoints de syscall envia eventos para o espaço de usuário, onde o daemon falco avalia as regras.

Uma regra típica do Falco se parece com isto:

- rule: Shell executado em contêiner
  desc: Detecta shell interativo dentro de um contêiner em produção
  condition: >
    spawned_process and container
    and shell_procs
    and not user_expected_shell_in_container
  output: >
    Shell iniciado em contêiner (user=%user.name container_id=%container.id
    container_name=%container.name shell=%proc.name parent=%proc.pname
    cmdline=%proc.cmdline image=%container.image.repository)
  priority: WARNING
  tags: [container, shell, mitre_execution]

O ponto-chave é: Falco vê a syscall, mas não a impede. Quando o alerta chega ao Falcosidekick (o roteador de eventos), o shell já está rodando. Isso é por design. Falco prioriza visibilidade ampla e baixo risco de falsos bloqueios em produção. Para muitas equipes, especialmente as que já operam SIEM maduro, é exatamente o comportamento desejado.

O que é Tetragon e como ele difere?

Tetragon é o componente de observabilidade e enforcement de segurança do projeto Cilium, doado à CNCF em 2022 e atualmente em incubação. Onde Falco para (alertar), Tetragon começa: ele pode terminar um processo ou bloquear uma syscall antes que ela retorne ao espaço de usuário, usando hooks LSM-BPF introduzidos no kernel Linux 5.7 (veja a documentação oficial de programas BPF LSM).

O modelo de configuração também é diferente. Em vez de regras YAML carregadas pelo daemon, Tetragon usa CRDs Kubernetes, especificamente TracingPolicy e TracingPolicyNamespaced. Cada política define quais eventos do kernel observar (tracepoints, kprobes, uprobes) e qual ação tomar quando o filtro casa.

Exemplo de TracingPolicy que mata qualquer processo que tente abrir /etc/shadow em pods marcados como app: web:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
  name: bloqueia-leitura-shadow
  namespace: producao
spec:
  podSelector:
    matchLabels:
      app: web
  kprobes:
  - call: "security_file_open"
    syscall: false
    args:
    - index: 0
      type: "file"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "/etc/shadow"
      matchActions:
      - action: Sigkill

Quando um processo nesse pod chama open("/etc/shadow", ...), o programa eBPF anexado a security_file_open avalia o caminho, dispara SIGKILL no kernel, e a syscall nunca completa. Isso é qualitativamente diferente de "detectar e alertar": é prevenção real, no caminho crítico da syscall.

Arquitetura eBPF: syscalls vs LSM hooks

Para entender a diferença prática entre as duas ferramentas, vale olhar onde no kernel cada uma se anexa. Honestamente, esse é o ponto que mais confunde equipes migrando de soluções legadas para runtime security moderno.

Falco: tracepoints de syscall

Falco usa tracepoints estáveis (sys_enter, sys_exit) e algumas kprobes. Esses pontos disparam depois que o kernel já decidiu permitir a syscall. O Falco recebe o evento, avalia a regra, emite o alerta. Mas o efeito da syscall já aconteceu. Para a maioria dos casos de detecção (visibilidade, forense, conformidade), isso é mais que suficiente.

Tetragon: LSM hooks e kprobes profundas

Tetragon anexa programas eBPF a hooks LSM (Linux Security Modules), os mesmos pontos usados por SELinux e AppArmor, mas programáveis em runtime. Se você já trabalhou com hardening usando políticas AppArmor em Ubuntu e Debian, o conceito é familiar: o kernel pergunta "esta operação é permitida?" antes de executá-la. A diferença é que LSM-BPF permite responder essa pergunta com lógica eBPF carregada dinamicamente, sem compilar um LSM como módulo.

Isso tem uma consequência operacional importante: Tetragon precisa que o kernel tenha sido compilado com CONFIG_BPF_LSM=y e que bpf apareça em /sys/kernel/security/lsm. Distribuições recentes (Ubuntu 24.04, RHEL 9.4+, Debian 12) já vêm com isso habilitado, mas verifique antes de prometer enforcement em produção:

cat /sys/kernel/security/lsm
# Esperado: lockdown,capability,landlock,yama,bpf,apparmor (ou similar)
# Se 'bpf' não aparecer, enforcement com Sigkill NÃO funcionará

Em kernels mais antigos onde bpf não aparece na lista, você pode adicioná-lo via parâmetro de boot lsm=lockdown,yama,bpf,apparmor no GRUB e reinicializar. Isso é seguro em RHEL 9 e Ubuntu 22.04+, mas teste primeiro em um node não-produtivo. Eu já vi um cluster ficar inacessível por uma alteração de boot mal testada, então não pule essa etapa.

Instalando Falco em um cluster Kubernetes

A instalação canônica em 2026 usa o chart Helm oficial. Recomendo sempre fixar a versão e habilitar explicitamente o driver eBPF moderno. Não confie nos defaults entre versões; eles mudam.

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --version 4.10.0 \
  --set driver.kind=modern_ebpf \
  --set tty=true \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

O modern_ebpf requer kernel 5.8+ com CO-RE. Em kernels mais antigos (RHEL 8 com kernel 4.18, por exemplo), você ainda pode usar driver.kind=ebpf (o driver legado, compilado), mas esse caminho será removido em 2027. Verifique com:

kubectl -n falco logs -l app.kubernetes.io/name=falco --tail=20 | grep -i "driver"
# Procure por: "Falco initialized with driver: modern_ebpf"

Para regras customizadas, monte um ConfigMap e referencie em customRules no values.yaml. Não edite o ConfigMap padrão de regras: ele é sobrescrito a cada upgrade. Eu costumo manter um repositório Git separado só com as regras customizadas da organização, versionado e revisado como qualquer outro código. Isso já me salvou de perder horas de trabalho em mais de um upgrade.

Instalando Tetragon com Helm

Tetragon também é distribuído via Helm pela Isovalent. A instalação básica é simples; o trabalho real está em escrever TracingPolicy que faça sentido para seu ambiente.

helm repo add cilium https://helm.cilium.io
helm repo update

helm install tetragon cilium/tetragon \
  --namespace kube-system \
  --version 1.3.0 \
  --set tetragon.enableProcessCred=true \
  --set tetragon.enableProcessNs=true \
  --set tetragon.exportFilename=/var/run/cilium/tetragon/tetragon.log

Após instalar, aplique uma TracingPolicy de exemplo da biblioteca oficial. Eu recomendo começar com file-monitoring em modo apenas-observação antes de habilitar Sigkill:

kubectl apply -f https://raw.githubusercontent.com/cilium/tetragon/v1.3.0/examples/tracingpolicy/file-monitoring.yaml

# Veja eventos em tempo real
kubectl exec -it -n kube-system ds/tetragon -c tetragon -- \
  tetra getevents -o compact

Detecção vs enforcement: o ponto crucial

Esta é a pergunta que mais ouço de equipes de segurança avaliando as duas ferramentas: "se Tetragon pode bloquear e Falco não, por que alguém escolheria Falco?" A resposta tem três partes.

Primeiro, maturidade do conjunto de regras. Falco tem cerca de 150 regras prontas mapeadas para MITRE ATT&CK, mantidas pela comunidade. Tetragon tem dezenas, e muitas das políticas avançadas você precisará escrever. Para uma equipe pequena, isso é uma diferença de semanas de trabalho.

Segundo, risco operacional. Enforcement no kernel é poderoso, mas um TracingPolicy mal escrito pode matar containerd, kubelet ou pods de sistema. Falco, por nunca bloquear, tem um perfil de risco operacional muito menor. É por isso que ainda vejo Falco em pipelines de detecção/SIEM mesmo em clusters que também rodam Tetragon.

Terceiro, integração com o stack existente. Se sua equipe já usa Wazuh, Auditd e Osquery para detecção de intrusões, adicionar Falco é trivial. Falcosidekick exporta para Elasticsearch, Loki, Slack, Splunk e dezenas de outros destinos. Tetragon exporta JSON estruturado, mas a quantidade de integrações prontas é menor.

Sobrecarga de desempenho e requisitos de kernel

A pergunta "qual tem menor overhead?" não tem uma resposta única; depende muito do volume de syscalls do seu workload. Mas vale entender os números aproximados que você pode esperar em ambientes típicos.

Em benchmarks recentes (publicados pela Isovalent no relatório de performance do Tetragon e validados em laboratório interno):

• Workload tipo web (Nginx + PHP-FPM, 5k req/s): Falco adiciona cerca de 3% de CPU no node, Tetragon cerca de 2%.
• Workload tipo banco (PostgreSQL com pgbench): Falco cerca de 4%, Tetragon cerca de 2.5%. A diferença vem da filtragem no kernel.
• Workload com alta taxa de fork/exec (CI runners): ambos ficam em 5–7%. Esse é o pior cenário porque cada execve dispara muitos eventos.

O ganho do Tetragon vem da capacidade de aplicar filtros (selectors) no programa eBPF antes do evento ser copiado ao espaço de usuário. Em Falco, cada syscall é enviada e filtrada no userspace. Para frotas com altíssima taxa de syscalls (mais de 200k/s por node), essa diferença começa a importar de verdade. Eu vi isso virar argumento decisivo em um cluster com cerca de 400 nodes rodando CI: cortar 1% de CPU em todos eles representa muitos núcleos economizados.

Requisitos de kernel em 2026:

• Falco 0.39: kernel 5.8+ para modern_ebpf; 4.14+ para o driver eBPF legado (ainda suportado).
• Tetragon 1.3: kernel 5.8+ para observação; kernel com CONFIG_BPF_LSM=y e bpf habilitado em lsm= no boot para enforcement com Sigkill.

Qual escolher para o seu caso de uso?

Resumindo minha recomendação depois de implantar essas ferramentas em mais de uma dúzia de clusters em produção:

Escolha Falco se

• Você quer começar rápido com regras prontas mapeadas a MITRE ATT&CK.
• Sua equipe de segurança já consome alertas via Elasticsearch, Splunk, Loki ou Sentinel.
• Você opera em kernels variados (incluindo RHEL 8) e não quer se preocupar com requisitos LSM-BPF.
• Você precisa de visibilidade ampla, e o enforcement é feito por outras camadas (Network Policies, OPA Gatekeeper, AppArmor).

Escolha Tetragon se

• Você já usa Cilium para CNI e quer telemetria de rede + processo unificada via Hubble.
• Você precisa bloquear ataques específicos no kernel, não apenas detectá-los.
• Sua equipe está confortável escrevendo políticas eBPF e operando CRDs Kubernetes.
• Performance em workloads de altíssima taxa de syscalls é prioridade.

Use ambos se

• Você opera clusters críticos onde detecção ampla e enforcement seletivo são requisitos.
• Você quer um caminho de migração gradual: começa com Falco, adiciona Tetragon para vetores específicos depois de validar.

Em qualquer caso, lembre que runtime security é a última linha de defesa, não substitui hardening de imagens, scanning de vulnerabilidades, Network Policies e revisão de RBAC. É o sino de fumaça depois que tudo o resto falhou; quanto menos ele tocar, melhor sua postura de segurança como um todo.

Perguntas frequentes

Falco e Tetragon usam eBPF?

Sim, ambas as ferramentas são baseadas em eBPF em 2026. Falco usa o driver modern_ebpf como padrão desde a versão 0.38 e descontinuou o módulo de kernel legado. Tetragon foi construído sobre eBPF desde o início e usa adicionalmente hooks LSM-BPF para enforcement.

Tetragon pode bloquear ataques ou apenas detectar?

Tetragon pode bloquear. Através de TracingPolicy com a ação Sigkill, ele termina o processo no kernel antes que a syscall maliciosa complete. Isso requer kernel com CONFIG_BPF_LSM=y e bpf habilitado na lista de LSMs ativos.

Qual é a sobrecarga de desempenho típica?

Em workloads normais, ambas ficam entre 2% e 4% de CPU adicional por node. Tetragon tende a ser ligeiramente menor porque filtra eventos no programa eBPF antes de enviá-los ao espaço de usuário, enquanto Falco filtra no daemon. Em workloads com altíssima taxa de fork/exec a sobrecarga pode chegar a 7%.

Posso usar Falco e Tetragon juntos no mesmo cluster?

Sim, e essa é uma arquitetura comum em clusters críticos. Os dois usam programas eBPF separados e não conflitam. A recomendação é usar Falco como motor de detecção amplo (alertas para SIEM) e Tetragon com um conjunto pequeno de políticas de enforcement em namespaces ou pods sensíveis.

O Falco ainda usa módulo de kernel?

Não. A partir do Falco 0.38, o módulo de kernel legado foi descontinuado. A versão 0.39 (janeiro/2026) consolida o driver modern_ebpf como padrão. O driver eBPF legado (compilado) ainda existe para kernels 4.14–5.7, mas está marcado para remoção em 2027.