O problema real que ninguém quer nomear

A LGPD entrou em vigor em setembro de 2020, e desde então as áreas de compliance de empresas brasileiras produziram algo que se convencionou chamar de "programa LGPD". Na maioria dos casos, esse programa é uma combinação de três coisas: um mapa de dados sensíveis feito em planilha, um conjunto de políticas internas em Word, e um relatório de auditoria produzido semestralmente por consultoria externa. Isso pode ter feito sentido em 2020, quando a maior parte da infraestrutura de aplicação corporativa ainda vivia em servidores dedicados razoavelmente estáticos.

Em 2026, esse modelo se tornou inadequado por uma razão estrutural. A infraestrutura moderna é dinâmica. Pods sobem e descem em segundos. Um container que processa dados de titulares pode ter tido oitenta réplicas ontem e ter apenas três agora. O storage de um pod que morre é apagado e realocado para outro. Sidecar containers, agentes de mesh, coletores de log — todos podem ler dados que passam por endpoints protegidos, e nenhum deles aparece no mapa de dados feito em planilha.

O resultado é previsível. A empresa produz relatório LGPD dizendo que dados sensíveis são tratados com controles A, B e C. Na semana seguinte, um engenheiro faz deploy de uma nova versão da aplicação, e essa versão inclui um pod que grava logs de requisição em bucket S3 sem redação de PII. O relatório permanece verdadeiro em relação ao momento em que foi escrito. Deixou de ser verdadeiro doze horas depois. Ninguém percebe até a próxima auditoria — que vai capturar outra fotografia, também instantaneamente obsoleta.

A resposta correta a esse problema não é fazer mais auditorias. É parar de tratar conformidade como fotografia periódica e começar a tratá-la como filme contínuo. Isso exige mover controles para dentro do pipeline de entrega — antes do deploy, no momento do deploy, e durante a operação. Cada um desses três pontos tem uma ferramenta técnica correspondente em Kubernetes, e todas existem, funcionam, e são open-source. A questão não é técnica — é organizacional.

Três camadas de controle: antes, durante, depois

Uma abordagem viável de LGPD em Kubernetes se organiza em três camadas de controle, cada uma respondendo a uma pergunta diferente.

Camada 1: antes do deploy — admission controllers

A primeira pergunta é: como impedir que carga não conforme entre no cluster? A resposta em Kubernetes tem nome e sobrenome — admission controllers dinâmicos, especificamente os do tipo validating webhook. Toda vez que alguém tenta criar ou modificar um recurso no cluster (um Deployment, um Pod, um Service, um ConfigMap), o Kubernetes envia uma requisição para um webhook que decide se aquilo pode ou não entrar. Se o webhook responder que não pode, o recurso é rejeitado, e o engenheiro que tentou fazer o deploy recebe o motivo de forma clara.

Duas ferramentas open-source dominam esse espaço: OPA/Gatekeeper e Kyverno. Ambas fazem essencialmente a mesma coisa — permitem escrever regras declarativas que são avaliadas contra cada recurso que tenta entrar no cluster.

Do ponto de vista LGPD, algumas regras que fazem sentido escrever nessa camada:

O ponto importante aqui não é a lista de regras — é o princípio. As regras devem sair da política jurídica interna e serem transcritas em linguagem declarativa (Rego, para OPA; YAML customizado, para Kyverno). Uma vez escritas, elas funcionam sozinhas, para sempre, sem depender de ninguém lembrar de aplicá-las manualmente.

OPA/Gatekeeper ou Kyverno? Quando escolher cada uma

OPA é mais poderoso e mais complexo. Rego, a linguagem de política do OPA, é Turing-completa e permite expressar praticamente qualquer regra imaginável — inclusive regras que consultam APIs externas para tomar decisão. A curva de aprendizado é significativa, e a comunidade brasileira de operadores fluentes em Rego é pequena. Faz sentido quando as regras LGPD são complexas, exigem consulta a sistemas externos (base de dados do DPO, por exemplo), ou quando a organização já usa OPA em outros contextos.

Kyverno foi projetada especificamente para Kubernetes, e as políticas são escritas em YAML — a mesma linguagem que já se usa para tudo mais no cluster. Menos poderosa, mas muito mais legível. Um engenheiro de plataforma que domina Kubernetes básico consegue escrever política Kyverno útil em uma tarde. Faz sentido para a maioria dos casos práticos de LGPD, especialmente em organizações que estão começando essa jornada e não podem investir em curva de aprendizado.

Se a pergunta é "qual escolher pela primeira vez?", a resposta pragmática é Kyverno. Se depois de seis meses o time se sentir limitado, migra para OPA.

Camada 2: durante a operação — runtime detection

A segunda pergunta é: como saber o que está acontecendo dentro dos pods que já subiram? Admission controllers protegem a fronteira de entrada, mas não veem nada do que acontece dentro do cluster depois. Um pod que passou pelo controlador pode, uma hora depois, começar a fazer conexões para endpoint desconhecido, ler arquivos fora do seu escopo declarado, ou executar processos suspeitos.

A ferramenta canônica para essa camada é o Falco, mantido pela Sysdig e projeto graduated da CNCF. Falco usa eBPF para observar as syscalls que os processos dentro dos containers estão fazendo em tempo real, e dispara alertas quando essas syscalls violam regras pré-definidas.

Do ponto de vista LGPD, algumas regras Falco que fazem sentido:

Falco não impede — apenas detecta e alerta. Isso é uma característica, não limitação. Bloquear syscall em runtime é operação delicada que pode derrubar produção; detectar e enviar para SIEM é atitude proporcional ao risco.

Camada 3: depois — evidência auditável

A terceira pergunta é: como provamos, depois do fato, que tudo foi feito corretamente? A LGPD não exige apenas que a empresa faça o certo — exige que ela consiga provar que fez, quando questionada pela ANPD (Autoridade Nacional de Proteção de Dados) ou por titular exercendo direito.

Isso significa que cada decisão tomada pelas camadas anteriores precisa deixar rastro. Admission controller rejeitou um deploy? Logar quem tentou, quando, com qual manifesto, por qual regra foi rejeitado. Falco detectou syscall suspeita? Logar com contexto suficiente para reconstruir o que aconteceu.

Esses logs precisam ir para um destino que atenda três requisitos:

  1. Imutável — depois de escrito, ninguém pode alterar. Bucket S3 com Object Lock em modo compliance é o padrão da indústria.
  2. Retido pelo período regulatório — a LGPD não define retenção específica de log de segurança, mas 5 anos é o mínimo defensável, alinhado ao Código Civil brasileiro sobre prescrição.
  3. Consultável de forma auditada — quem consultou o log também gera log. Isso é obrigação, não paranoia.

Na prática, isso significa integrar o cluster Kubernetes a uma stack de observabilidade — Loki para logs, Prometheus para métricas, Tempo para traces — e configurar o pipeline dessa stack para replicar os eventos relevantes para storage imutável de longa retenção. Ou, alternativamente, para um SIEM comercial (Splunk, Sumo Logic, Datadog) que já ofereça garantias de retenção auditável nativamente.

Um exemplo concreto: pod que processa CPF

Deixa eu tornar isso concreto com um caso realista. Uma aplicação recebe requisições HTTP contendo CPFs de titulares para consulta de crédito. O time de plataforma precisa implantar essa aplicação em Kubernetes de forma que atenda à LGPD.

O fluxo end-to-end fica assim:

  1. O engenheiro escreve o manifesto do Deployment. Inclui a label data-classification: sensitive, o annotation lgpd.bastion.com.br/purpose: credit-check, e configura o container para gravar logs em stdout apenas (sem escrever em disco).
  2. Ao fazer kubectl apply, o request passa pelo Kyverno. Regras verificam: a label sensitive existe? Sim. Existe correspondência no ROPA para esse purpose? Sim. Os volumes declarados são criptografados? Sim (é usado apenas configMap, sem storage persistente). O ingress associado tem TLS válido? Sim.
  3. O Deployment sobe. Falco começa a observar. As regras dizem: alertar se o pod conectar em IPs fora do range do bureau de crédito. Alertar se algum processo tentar ler /proc de outros pods. Alertar se ocorrer exec no pod fora de janela de manutenção autorizada.
  4. A aplicação começa a processar requisições. Cada requisição gera log estruturado que sai por stdout, é coletado por Fluent Bit, vai para Loki. Uma regra de pipeline em Loki replica logs marcados como LGPD-relevantes para bucket S3 imutável.
  5. Um titular pede acesso aos seus dados via portal LGPD da empresa. O time de compliance consulta o SIEM, filtra por CPF do requerente, extrai as consultas feitas nos últimos meses. A extração deixa registro de quem consultou o quê e quando. O titular recebe resposta em prazo legal (15 dias).

Nenhum passo desse fluxo dependeu de humano lembrar de nada. Cada controle está codificado. Cada evento está registrado. Cada acesso está auditado. Se a ANPD pedir evidência de conformidade daqui a três anos, ela existe — automaticamente coletada, imutavelmente guardada, cronologicamente organizada.

Onde a automação encontra seu limite honesto

Seria desonesto sugerir que tudo em LGPD pode ser automatizado. Uma parte importante do trabalho continua exigindo julgamento humano contextual, e vale nomeá-la para não vender ilusão.

A definição da base legal do processamento não é automatizável. A LGPD lista dez bases legais possíveis (consentimento, execução de contrato, obrigação legal, entre outras), e a escolha correta para cada operação de processamento exige compreensão jurídica, contextual e de negócio. Uma máquina não decide se o processamento de dados de RH está fundamentado em execução de contrato de trabalho ou em legítimo interesse — isso é análise jurídica, feita por gente qualificada, com registro documental próprio.

A análise de proporcionalidade e minimização de dados também exige julgamento. A pergunta "esse dado é realmente necessário para essa finalidade?" tem resposta contextual, dependente do modelo de negócio, e não pode ser respondida por regra genérica.

O tratamento de solicitações complexas de titulares exige interpretação. Um titular pode pedir "eliminação de todos os meus dados" em contexto onde a empresa tem obrigação legal de reter parte deles (dados fiscais, por exemplo). A decisão sobre o que eliminar e o que reter é análise jurídica, não automação.

O papel correto da automação é ampliar o alcance desses julgamentos — permitir que uma equipe pequena de DPO e jurídico traduza suas decisões em regras que se aplicam consistentemente em milhares de operações diárias. Não substitui a decisão original.

O princípio que se estende além de LGPD

Vale destacar o que essa abordagem tem de generalizável. A tese central — conformidade tratada como código executável embarcado no pipeline, provada continuamente com evidência auditável — se aplica sem tradução a outras regulações.

ISO 27001 tem controles que se traduzem diretamente para regras Kyverno. PCI-DSS tem requisitos técnicos específicos que viram admission controllers. Requisitos setoriais do Banco Central (Resoluções 4.658 e 4.893) sobre gerenciamento de riscos operacionais têm componentes técnicos que viram regras Falco. HIPAA, para operações em saúde, tem exigências de auditoria que viram políticas de retenção de log estruturado.

O que muda entre regulações é o vocabulário. O que permanece constante é a arquitetura — três camadas de controle (antes, durante, depois), políticas declarativas que substituem processos manuais, evidência auditável gerada automaticamente. Uma vez que a organização domina essa arquitetura para LGPD, aplicá-la a outras regulações vira exercício de tradução, não construção do zero.

Essa é a virada mental que separa organizações que operam Kubernetes seriamente em ambiente regulado das que ainda tratam o cluster como caixa preta a ser auditada. Não é diferença técnica trivial — é diferença de postura, no sentido literal.

Se você chegou até aqui, provavelmente está pensando na sua própria operação Kubernetes e nas conformidades que ela precisa atender. Alguns dos pontos deste artigo vão parecer óbvios; outros vão exigir trabalho estrutural que ninguém executa em uma semana. A ordem de implementação importa — começar por admission controllers dá retorno visível em prazo curto, enquanto stack completa de observabilidade auditável é projeto de meses. Vale planejar essa sequência com quem já operou essa arquitetura em produção antes.