Wiki · Concept · Last reviewed June 25, 2026

Kubernetes Audit Logging

Kubernetes audit logging is the API-server record of cluster requests, policy decisions about what to capture, and the backends that preserve those events.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Kubernetes, audit logging, observability, evidence, AI infrastructure

Definition

Kubernetes audit logging is the control-plane mechanism for recording activity against the Kubernetes API. The official Kubernetes auditing guide says auditing provides a security-relevant, chronological set of records documenting actions in a cluster, including activity generated by users, applications that use the Kubernetes API, and the control plane itself.

For Spiralism, this is the cluster's action receipt. When an AI platform creates a Job, patches a Deployment, reads configuration, updates a ServiceAccount, or changes an admission policy, the audit log is one of the records that can later show which authenticated actor touched which Kubernetes object and when.

How It Works

Audit records begin inside kube-apiserver. The Kubernetes guide says each request, at each stage of execution, generates an audit event that is pre-processed by policy and written to a backend. The defined stages are RequestReceived, ResponseStarted, ResponseComplete, and Panic. The current backend implementations named by the guide are log files and webhooks.

The audit policy decides what is recorded and how much detail is included. Rules are evaluated in order, and the first matching rule sets the level. Kubernetes defines four levels: None, Metadata, Request, and RequestResponse. Metadata records request metadata without request or response bodies. Request adds the request body. RequestResponse adds request and response bodies. That extra detail can be useful during incident reconstruction, but it can also place sensitive data into logs.

The audit configuration API defines the shape of the evidence. An audit Event can include an audit ID, stage, request URI, verb, user, impersonated user, authentication metadata, source IPs, user agent, object reference, response status, request object, response object, timestamps, and annotations. The policy object defines ordered rules, omitted stages, and whether managed fields should be omitted.

Operationally, kube-apiserver accepts flags such as --audit-policy-file, --audit-log-path, --audit-webhook-config-file, and --audit-webhook-mode. The reference says webhook mode can be batch, blocking, or blocking-strict.

Agent Context

AI systems turn Kubernetes into more than deployment plumbing. A coding agent may trigger builds, an evaluation runner may create short-lived Jobs, a tool gateway may scale workers, and an internal assistant may read cluster state through a ServiceAccount. If those actions pass through the Kubernetes API, audit logging can help separate human operators, controllers, agents, and service accounts in the evidence trail.

The useful question is not "did the model behave?" but "what did the platform let the system do?" Kubernetes audit events can show a delegated identity creating resources, changing RBAC, touching Secrets, updating admission policy, or interacting with workloads that host model and tool services.

Governance Use

A governance-grade record should preserve the audit policy file, rule order, levels, omitted stages, omitted managed fields setting, log or webhook backend, API-server flags, retention path, protected namespaces, high-risk resources, service accounts, aggregation pipeline, redaction policy, and incident-review access. For AI infrastructure, it should also map audit events to workload type: model serving, tool execution, retrieval, evaluation, batch training support, or administrative automation.

The policy should be deliberate. A cluster that runs agent sandboxes may need strong records around Jobs, Pods, RoleBindings, ClusterRoleBindings, Secrets, admission policies, Gateway routes, and ServiceAccounts. It may not need request and response bodies for every read. A defensible policy records enough to reconstruct authority without turning the audit store into a sensitive secondary database.

Limits

Audit logging is not full observability. It does not record every shell command inside a container, every packet, every model prompt, or every file touched by an agent. It records Kubernetes API activity according to policy. It also has operational cost: the Kubernetes guide notes that auditing increases API-server memory consumption because auditing context is stored for each request.

Audit fields still require interpretation. The audit configuration reference notes that user agent is client-provided and must not be trusted; source IP chains can include proxy-provided values. Provider-managed Kubernetes services may expose audit data through provider-specific logging products, so managed-cluster claims need separate provider documentation.

Source Discipline

Claims about stages, levels, policy evaluation, event fields, backends, and API-server flags should cite Kubernetes documentation. Claims about SIEM integrations, cloud-provider audit products, admission-controller annotations, redaction processors, or compliance dashboards should cite the implementation actually used.

The local evidence should include a sample event, policy version, API-server configuration, export destination, retention rule, access-control record, and the incident or audit question the log is meant to answer.

Spiralist Reading

Spiralism reads Kubernetes audit logging as a ledger of cluster speech.

A workload asks, a controller changes, a human approves, a service account acts. The audit log does not make the action wise or harmless. It keeps the claim from dissolving into fog.

Sources

Return to Wiki