Skip to main content
RunBook Academy

KubernetesXCIV · Audit LoggingAudit logs

Audit policy stages — RequestReceived, ResponseStarted, ResponseComplete, Panic

Advanced⏱ ~14 minkubectlkube-apiserveraudit-policy

What you'll learn

  • Explain the audit policy stages
  • Identify the four stages (RequestReceived, ResponseStarted, ResponseComplete, Panic)
  • Configure the audit policy
  • Plan the production patterns

Prerequisites

Verified against Kubernetes 1.34.x · kubeadm 1.34.x · kubectl 1.34.x · etcd 3.6.x · CoreDNS 1.11.x · containerd 1.7.x / 2.x · 2026-08-16

Not yet marked complete on this device.

The Kubernetes audit policy has four stages: RequestReceived, ResponseStarted, ResponseComplete, and Panic. Each stage emits an audit event with the request and response metadata. The policy is the configuration. This lesson walks the stages, the events, the policy, and the production patterns.

The audit stages

The audit stages:

sequenceDiagram
    participant C as Client
    participant API as kube-apiserver
    participant A as Audit
    C->>API: Request
    API->>A: RequestReceived
    API->>API: Process request
    API->>A: ResponseStarted (if long)
    API->>A: ResponseComplete (always)
    API-->>C: Response
    Note over API,A: If panic during process: Panic

The stages are the audit events.

The RequestReceived stage

The RequestReceived stage:

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "abc-123",
  "stage": "RequestReceived",
  "requestURI": "/api/v1/namespaces/default/pods",
  "verb": "create",
  "user": {
    "username": "kubernetes-admin",
    "groups": ["system:masters", "system:authenticated"]
  },
  "sourceIPs": ["10.0.1.10"],
  "userAgent": "kubectl/v1.34.0",
  "objectRef": {
    "resource": "pods",
    "namespace": "default",
    "name": "nginx",
    "apiGroup": ""
  },
  "requestReceivedTimestamp": "2026-08-16T10:00:00.000Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding"
  }
}

The RequestReceived stage is emitted when the request is received.

The ResponseStarted stage

The ResponseStarted stage:

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "abc-123",
  "stage": "ResponseStarted",
  "requestURI": "/api/v1/namespaces/default/pods/nginx/log",
  "verb": "get",
  "user": {...},
  "sourceIPs": ["10.0.1.10"],
  "objectRef": {...},
  "responseStatus": {...},
  "requestReceivedTimestamp": "2026-08-16T10:00:00.000Z",
  "stageTimestamp": "2026-08-16T10:00:05.000Z"
}

The ResponseStarted stage is emitted for long-running requests.

The ResponseComplete stage

The ResponseComplete stage:

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "abc-123",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/default/pods",
  "verb": "create",
  "user": {...},
  "objectRef": {...},
  "responseStatus": {
    "metadata": {},
    "code": 201
  },
  "requestReceivedTimestamp": "2026-08-16T10:00:00.000Z",
  "stageTimestamp": "2026-08-16T10:00:01.000Z"
}

The ResponseComplete stage is emitted when the request is completed.

The Panic stage

The Panic stage:

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "abc-123",
  "stage": "Panic",
  "requestURI": "/api/v1/namespaces/default/pods",
  "verb": "create",
  "user": {...},
  "objectRef": {...},
  "requestReceivedTimestamp": "2026-08-16T10:00:00.000Z",
  "stageTimestamp": "2026-08-16T10:00:01.000Z",
  "error": "audit plugin panicked"
}

The Panic stage is emitted when the audit plugin panics.

The audit policy

The audit policy:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# Log all requests at the Metadata level
- level: Metadata
  namespaces: ["kube-system", "default"]

# Log all secret requests at the RequestResponse level
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets"]

# Don't log /healthz, /readyz, /metrics
- level: None
  nonResourceURLs:
  - /healthz*
  - /readyz*
  - /metrics

The policy is the configuration.

The audit levels

The audit levels:

LevelDescription
NoneDon’t log
MetadataLog the request metadata (URI, user, etc.)
RequestLog the request metadata + body
RequestResponseLog the request + response metadata + body
MetadataLog the request metadata (default)

The levels are the granularity.

The audit backends

The audit backends:

flowchart LR
    A[kube-apiserver] --> B[Audit log]
    B --> C[Log file]
    B --> D[Webhook]
    B --> C[Log file]
    B --> D[Webhook]

The backends are the destinations.

The production patterns

The production patterns:

flowchart LR
    A[Audit policy] --> B[Requests at Metadata]
    B --> C[Secrets at RequestResponse]
    C --> D[Log file]
    C --> E[Webhook]
    D --> F[Log shipping]
    F --> G[Loki]
    E --> H[SIEM]

The pattern is the production discipline.

The cross-course references

  • The API server course covers the audit configuration.
  • The Security course covers the audit policies.
  • The SIEM course covers the integration.

Quiz

Knowledge check · 4 questions

  1. Q1. What are the four audit policy stages?

  2. Q2. The Panic stage is emitted when the audit plugin panics.

  3. Q3. Walk the audit policy for a cluster.

    Cluster with kube-apiserver. The team is configuring the audit policy.

  4. Q4. What are the audit levels?

Passing score: 75%. Answers are checked in this browser.

Production discipline

  • Configure the audit policy. Per-namespace, per-resource.
  • Set the audit levels. Metadata for normal, RequestResponse for secrets.
  • Configure the backends. Log file, webhook.
  • Mount the policy in the kube-apiserver. The configuration.
  • Document the audit policy. The rules, the levels.
  • Test the audit policy. Verify the events.

The audit policy stages are the security trail. Operating it well is the stages, the policy, the backends, and the production patterns.