# Review the first matching Kubernetes audit rule before collecting bodies > Kubernetes audit policy uses the first matching rule. Check the chosen level and resource scope before enabling request or response bodies in the retained audit stream. - Canonical URL: https://update.dsesecurity.com/updates/review-the-first-matching-kubernetes-audit-rule-before-collecting-bodies/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T17:40:54+00:00 - Modified: 2026-10-29T17:41:39+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Kubernetes audit policy uses the first matching rule. Check the chosen level and resource scope before enabling request or response bodies in the retained audit stream. ## Potentially affected Review scope: documented Kubernetes API audit policy matching and levels; audit storage, managed-service controls and organizational retention require separate assessment. ## DSE recommendation Map representative API requests to their first matching rule and intended audit level, then verify the retained event without collecting unnecessary bodies. ## Article 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](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/) 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](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/) — Kubernetes. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — Auditing - Authority: kubernetes.io - URL: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Review the first matching Kubernetes audit rule before collecting bodies,” DSE Security, https://update.dsesecurity.com/updates/review-the-first-matching-kubernetes-audit-rule-before-collecting-bodies/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.