AuditEvent. Junto com as ClusterRoles da plataforma e um relatório de compliance sob demanda, isso dá uma trilha consultável do que a automação fez e quando.
Um AuditEvent é um CRD que só tem
spec (sem subresource status). O
operator cria AuditEvents e nunca os atualiza nem apaga, mas nada no cluster
garante a imutabilidade: não existe admission webhook, e a ClusterRole
chatcli-role-admin distribuída com a plataforma pode dar update/patch
em AuditEvents (chatcli-role-superadmin também pode dar delete). Se você
precisa de uma trilha à prova de adulteração, veja
Imutabilidade e envie os eventos para um
sistema externo.Por que Audit Trail para AIOps
Quando uma plataforma toma decisões autônomas em infraestrutura de produção, a rastreabilidade deixa de ser opcional:Responsabilização
Quando uma remediação começou, ficou aguardando aprovação, foi aprovada,
rejeitada ou expirou? Qual controller fez isso? Cada uma dessas etapas
deixa um registro.
Investigação Pós-Incidente
Todo evento carrega um
correlationId (o nome da Issue), então a trilha de
um incidente — criação, remediação, notificações, resolução — sai com um
único filtro.Compliance Regulatório
Evidência para auditorias de controle de mudanças (SOC 2, ISO 27001,
PCI-DSS e similares): registro das ações automatizadas mais RBAC
documentado. A plataforma fornece os registros; ela não é certificada em
nenhum framework.
Melhoria Contínua
MTTD, MTTR, taxa de sucesso das remediações e resultado das aprovações,
calculados sob demanda a partir dos CRDs da plataforma.
AuditEvent CRD
OAuditEvent só tem spec, sem status. Short name: ae.
Especificação Completa
Um evento real, como o controller de remediação grava quando um plano começa a executar:operator/api/v1alpha1/auditevent_types.go):
Tipos de Evento (EventType)
O operator emite 14 tipos de evento, a mesma lista que o comentário do campoeventType no CRD documenta. Todos são gravados com actor.type: controller, exceto uma aprovação ou rejeição decidida por pessoas (veja a aba Governança):
- Incidentes
- Remediação
- Governança
- Alertas e entrega
AuditActor
O campoactor identifica quem ou o que executou a ação:
Outras ações humanas (dar acknowledge ou snooze em um incidente, edições via
kubectl) não viram AuditEvents. Para saber quem alterou qual objeto, use o audit log do API server do Kubernetes.
AuditResource
O camporesource identifica o recurso Kubernetes afetado:
Formato de Nome e Namespace
Cada AuditEvent recebe o nome:audit-1773930600123456789-a7f3b2.
O evento é criado no namespace do recurso afetado (o namespace da Issue, do RemediationPlan, do ApprovalRequest ou do SLO), e não no namespace do operator. Consulte com -A ou com o namespace do workload.
Só duas labels são definidas: platform.chatcli.io/event-type e platform.chatcli.io/severity. Não existe label de correlação; filtre por spec.correlationId (exemplos abaixo).
Annotation de Imutabilidade
Todo AuditEvent é criado com a annotationplatform.chatcli.io/immutable: "true". O operator não traz admission webhook, então a annotation é só um marcador. Para tornar a trilha resistente a adulteração:
- faça valer a annotation com uma regra de policy engine (Kyverno, Gatekeeper) que rejeite
UPDATEeDELETEem recursos que a carregam, exceto para o seu job de retenção; - revise quem tem
update/patch/deleteemauditevents(a própria ServiceAccount do operator,chatcli-role-adminechatcli-role-superadmintêm); - exporte os eventos para um SIEM ou para um storage write-once.
Audit Recorder
OAuditRecorder (operator/controllers/audit_recorder.go) é o componente interno que os controllers chamam para gravar AuditEvents. Ele não é uma API pública nem ponto de extensão: um único recorder é criado na inicialização e compartilhado pelos reconcilers de Issue, Remediation, Notification, SLO e SLA. Os reconcilers de Approval, Chaos, Federation, AIInsight, Anomaly e PostMortem não têm um.
Qual Controller Grava o Quê
Exemplo de Evento Gerado
Uma violação de SLA, como o controller de SLA grava:Compliance Reporter
OComplianceReporter calcula um relatório sob demanda, servido pela API REST em GET /api/v1/analytics/compliance (role viewer). Nada é agendado nem armazenado: cada chamada lista os CRDs da plataforma e calcula os números.
Solicitando um Relatório
O relatório cobre objetos criados dentro do período (por
metadata.creationTimestamp). Ele lê Issues, RemediationPlans, ApprovalRequests, IncidentSLAs e AuditEvents — os AuditEvents só alimentam o resumo de auditoria; os demais números vêm dos próprios recursos.
A resposta embrulha o relatório em spec. As chaves são PascalCase (fixadas por tags JSON explícitas), e durações são inteiros em nanossegundos:
Métricas do Relatório
- Métricas de Incidentes
- Métricas de Remediação
- Métricas de SLA
- Métricas de Aprovação
Calculadas a partir das Issues criadas na janela.
Audit Summary
Contagem dos AuditEvents criados na janela, por severidade e por tipo de evento:Roles de RBAC do Kubernetes
A plataforma traz 4 ClusterRoles para pessoas e ferramentas que trabalham com os CRDs da plataforma viakubectl. Elas são criadas pelo Helm chart do operator (rbac.create: true, o padrão) ou pelo make deploy (operator/config/rbac/role.yaml), nunca pelo operator em runtime (hardening H5: o operator não tem permissão para criar ClusterRoles, e nada no operator vincula essas roles — o vínculo é feito por você).
Definição de Roles
- Viewer
- Operator
- Admin
- SuperAdmin
chatcli-role-viewer — acesso somente leitura aos CRDs ligados a incidentes.Concedendo uma Role
Vincule uma role a um usuário ou grupo como qualquer ClusterRole:RoleBinding com namespace apontando para a mesma ClusterRole para limitar o acesso a um namespace. Revogar é apagar o binding. Mudanças de role aparecem no audit log do Kubernetes; os AuditEvents do operator cobrem o que os controllers fazem, não quem recebeu qual role.
A API REST e o dashboard usam um modelo próprio, API keys com
viewer, operator ou admin, descrito em Web Dashboard. As ClusterRoles acima são para pessoas e ferramentas que chegam aos CRDs via kubectl.API REST de Auditoria
A API REST do operator (porta 8090, headerX-API-Key, qualquer role a partir de viewer) expõe dois endpoints somente leitura. Ambos aceitam apenas GET.
GET /api/v1/audit
Lista eventos, filtrados e paginados em memória, do mais recente para o mais antigo pelotimestamp (o horário de criação quando ele falta; empates por nome), então cada página é um trecho estável da trilha.
Parâmetros de query:
Não há filtro por actor nem por correlation ID; para pegar todos os eventos de um incidente, filtre
correlationId no cliente (veja os exemplos com kubectl e jq abaixo).
Exemplo de requisição:
details vira uma única string detail com pares chave=valor unidos por ; (sem ordem fixa), e actor.controller e resource.uid são descartados. Use kubectl get auditevent <nome> -o yaml para ver o objeto completo.
GET /api/v1/audit/export
Aceita os mesmos filtros (namespace, type, severity, resource, from, to), mas sem paginação, e devolve todos os eventos correspondentes como um documento JSON para download (Content-Disposition: attachment; filename=audit-events-<timestamp>.json):
items têm o mesmo formato do endpoint de listagem:
jq -c '.items[]' para transformar em um evento por linha.
A API REST tem rate limit de 600 requisições por minuto por API key
válida (30 por minuto por host de cliente sem chave). O acesso a ela só é logado no stdout do operator (
[REST] método caminho status duração role=...); chamadas REST não criam AuditEvents.Integração com SIEM
Não existe push nativo para SIEM. Consulte o endpoint de exportação de forma agendada e encaminhe para Splunk, Elastic, Datadog ou qualquer outro coletor. Os exemplos abaixo usamalpine com curl e jq, e uma API key guardada em um Secret (chatcli-audit-exporter, chave api-key, com uma key viewer).
Splunk
1
Configure o HEC (HTTP Event Collector)
Crie um token HEC no Splunk para receber os eventos da plataforma AIOps.
2
Crie o CronJob de exportação
3
Crie o índice e os dashboards
Configure um índice dedicado
chatcli_audit no Splunk e crie dashboards
para visualizar eventos por tipo, severidade e namespace.Elasticsearch
Comandos kubectl
Consultas de auditoria comuns via kubectl
Consultas de auditoria comuns via kubectl
Retenção de Eventos
O operator nunca apaga AuditEvents — não há TTL, configuração de retenção
nem owner reference, então eles não são coletados junto com a Issue. Cada
evento é um objeto no etcd; configure um job de retenção para manter a
contagem sob controle.
Trilha de Auditoria do Servidor
Os AuditEvents acima cobrem o operator. O servidor ChatCLI (chatcli server, o pod que uma Instance executa) tem uma trilha separada, em arquivo: defina spec.server.security.auditLogPath na Instance (vira CHATCLI_AUDIT_LOG_PATH) com um caminho absoluto, e cada chamada gRPC é anexada como uma linha JSON encadeada por hash (kind: "grpc": ação, actor, role, IP do chamador, resultado, duração), intercalada com as entradas de requisições LLM na mesma cadeia verificável. Detalhes e verificação (/config security verify-audit) estão em Segurança.
O pod da Instance tem root filesystem somente leitura; só /tmp e /home/chatcli/.chatcli são graváveis, ambos volumes emptyDir perdidos no restart. Para manter o arquivo entre restarts, habilite spec.persistence e aponte o caminho para dentro do volume de sessões, por exemplo /home/chatcli/.chatcli/sessions/audit.jsonl.
Próximos Passos
Workflow de Aprovação
Como os planos são estacionados e decididos — a origem dos eventos
approval_*, incluindo os gates criados pelo decision engine e pelo tier
do cluster.SLOs e SLAs
Alertas de burn rate e timers de SLA por trás de
slo_violation e
sla_breach, e o compliance de SLA real por severidade.Web Dashboard
A visão de auditoria, as API keys e as roles da REST.
Plataforma AIOps
Voltar para a visão geral da plataforma AIOps.