Conceito e mecanismo
Define a pergunta que a auditoria deve responder: quem pediu uma operação, em que objeto, quando e com que resultado. Metadata pode satisfazer esse objetivo sem recolher corpos. Request e RequestResponse acrescentam conteúdo que pode incluir dados sensíveis. A primeira regra correspondente decide o nível; colocar uma exceção para Secrets depois de uma regra abrangente pode deixar a exposição intacta. Um evento com create pods e 403 mostra uma recusa desse pedido, não um Pod em execução. Relaciona eventos pela identidade, objeto e tempo, mantendo explícito o que a evidência permite concluir e aquilo que ainda precisa de confirmação.
Aplicação guiada
A ausência de um evento só é interpretável depois de verificar cobertura, entrega, retenção e janela temporal. Um ficheiro de política em Git não prova que o API server o aplica nem que o backend recebe dados. Antes de reconstruir um node, preserva os registos que só existem localmente, com origem, integridade e acesso controlado. Se a auditoria já copiou uma credencial para um sistema com mais leitores, a correção precisa de tratar tanto futuras recolhas como material divulgado. Numa investigação bancária fictícia, coordena APS, segurança e responsáveis pelos dados para manter evidência útil sem publicar conteúdo sensível num canal amplo. Regista decisões e limitações para o handover entre fusos horários.
Uma regra Metadata para Secrets deve preceder uma regra geral RequestResponse quando ambas podem corresponder.
Armadilhas comuns
Primeira regra ignorada; falta de evento como prova negativa; reconstrução antes de preservar; logs como dados não sensíveis.
Tópicos relacionados: Deteção runtime e resposta coordenada · Fronteiras de rede e exposição do cluster
A qualidade da investigação depende de cobertura conhecida, evidência preservada e exposição controlada.
Referência: API auditing · Kubernetes v1.35; current six-domain CKS outline