Review the first matching Kubernetes audit rule before collecting bodies

Bottom line: Choose what an audit event must contain before enabling broad body collection. Review rule order against concrete API requests and keep the policy decision separate from whether an event actually reaches its approved destination.

Source fact: documented behavior

The Auditing documentation is the primary reference.

Kubernetes evaluates audit rules in order, and the first matching rule determines the event’s audit level. The documented levels range from None to Metadata, Request and RequestResponse; Metadata omits both bodies, while the latter two include request bodies and, for RequestResponse, response bodies. Request-body and response-body levels do not apply to non-resource requests, and the example treats pods, pods/log and pods/status as separate resource selections.

What the source does not establish

This article reviews audit policy content and matching, not a universal logging profile or a compliance determination. It does not establish delivery, retention, access control or availability of a particular audit backend. Resolve those requirements separately and use nonsensitive inputs when rehearsing body collection.

Applicability questions

• Which exact API request and resource or subresource must be recorded?
• Which rule matches first in the complete policy?
• What information is necessary beyond event metadata?
• Where will the owner confirm the actual retained record?

DSE recommendation: test policy decisions with representative requests

DSE recommends a small policy worksheet with a representative request in each row. Record the requester, verb, resource or non-resource path, namespace where relevant, expected first match and intended level. Include a request that should be excluded as deliberately as one that needs investigation evidence.

Review the complete ordered policy rather than one proposed insertion. Place the new rule in that context and have a second administrator identify the expected winner. Keep specific exceptions and broader catch-all rules visible together. Resolve a disagreement about the winning rule before changing a production audit stream.

Choose body collection from an explicit investigation requirement. Ask the data owner what may enter the event, who can read it and what should remain excluded. Use harmless synthetic objects for rehearsal. Avoid enabling the broadest level merely to make the audit display look more detailed.

Include subresources in the worksheet when they matter to the operational question. Keep the expected record distinct from the application’s own logs and from an ordinary cluster event. Have the audit owner define an approved observation method and a destination-side check before declaring the policy effective. Retain the policy revision with the request definitions.

Verification and evidence

Proposed verification, not performed: apply the reviewed policy only in an approved test environment and submit the worksheet’s nonsensitive requests. Compare the retained event level and body presence with the prediction for each case. Include a harmless subresource case and a non-resource case when they are relevant to the deployment.

In a separate controlled revision, move one overlapping rule and predict the changed first match before repeating the request. Preserve actual events with sensitive values excluded, policy order, request identity and destination observations. Record missing or unexpected events as failures to investigate; do not equate policy-file acceptance with successful audit retention.

Official references

• Auditing — Kubernetes.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.