Skip to main content
A plataforma AIOps do ChatCLI registra as etapas-chave do pipeline — ciclo de vida da Issue, execução de remediações, gates de aprovação, entregas de notificação, alertas de burn rate de SLO e violações de SLA — como recursos 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

O AuditEvent 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:
Referência de campos (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 campo eventType 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):
Nenhum outro tipo de evento é gravado. Nomes que materiais antigos listavam, como approval_granted (o nome real é approval_approved), pattern_learned, config_changed, cluster_connected, cluster_disconnected, escalation_triggered, postmortem_created e runbook_generated, nunca aparecem. Experimentos de chaos, os vereditos de confiança do decision engine, a análise de IA, a detecção de anomalias, a federação e as chamadas à API REST não geram AuditEvents próprios. Não construa alertas nem relatórios em cima desses nomes.

AuditActor

O campo actor 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 campo resource identifica o recurso Kubernetes afetado:

Formato de Nome e Namespace

Cada AuditEvent recebe o nome:
Exemplo: 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 annotation platform.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 UPDATE e DELETE em recursos que a carregam, exceto para o seu job de retenção;
  • revise quem tem update/patch/delete em auditevents (a própria ServiceAccount do operator, chatcli-role-admin e chatcli-role-superadmin têm);
  • exporte os eventos para um SIEM ou para um storage write-once.
O operator grava AuditEvents em modo best-effort: se um create falha, o controller loga o erro e segue em frente, então uma lacuna na trilha não bloqueia a remediação.

Audit Recorder

O AuditRecorder (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

O ComplianceReporter 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

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 via kubectl. 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

chatcli-role-viewer — acesso somente leitura aos CRDs ligados a incidentes.
Não inclui: policies (Approval, Notification, Escalation), ChaosExperiments, ClusterRegistrations, SourceRepositories, Instances.

Concedendo uma Role

Vincule uma role a um usuário ou grupo como qualquer ClusterRole:
Use um 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, header X-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 pelo timestamp (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:
Exemplo de resposta:
A visão REST achata o registro: 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):
Formato de exportação — um único objeto JSON indentado (não é NDJSON), cujos items têm o mesmo formato do endpoint de listagem:
Use 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 usam alpine 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

Se a API REST do operator roda com TLS (CHATCLI_AIOPS_TLS_CERT / CHATCLI_AIOPS_TLS_KEY), troque as URLs para https:// e passe a CA com --cacert.

Comandos 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.
Exporte para o seu SIEM antes que a janela de retenção feche se precisar guardar os eventos por mais tempo.

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.
O operator em si não grava audit log em arquivo. Ele não lê CHATCLI_AUDIT_LOG_PATH; o valor security.auditLogPath do chart do operator ainda renderiza essa variável, mas não tem efeito.

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.