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.
\nThe Auditing documentation is the primary reference.
\nKubernetes 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.
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.
\nDSE 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.
\nReview 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.
\nChoose 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.
\nInclude 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.
\nProposed 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.
\nIn 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe Auditing documentation is the primary reference.\nKubernetes 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact API request and resource or subresource must be recorded?\nWhich rule matches first in the complete policy?\nWhat information is necessary beyond event metadata?\nWhere will the owner confirm the actual retained record?\n\nDSE recommendation: test policy decisions with representative requests\nDSE 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.\nReview 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.\nChoose 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.\nInclude 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.\nVerification and evidence\nProposed 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.\nIn 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.\nOfficial references\n\nAuditing — Kubernetes.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Auditing](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/) documentation is the primary reference.\n\nKubernetes 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which exact API request and resource or subresource must be recorded?\n\n- Which rule matches first in the complete policy?\n\n- What information is necessary beyond event metadata?\n\n- Where will the owner confirm the actual retained record?\n\n## DSE recommendation: test policy decisions with representative requests\n\nDSE 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.\n\nReview 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.\n\nChoose 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.\n\nInclude 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.\n\n## Verification and evidence\n\nProposed 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.\n\nIn 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.\n\n## Official references\n\n- [Auditing](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/) — Kubernetes.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/review-the-first-matching-kubernetes-audit-rule-before-collecting-bodies/", "url": "https://update.dsesecurity.com/updates/review-the-first-matching-kubernetes-audit-rule-before-collecting-bodies/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/review-the-first-matching-kubernetes-audit-rule-before-collecting-bodies/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Review the first matching Kubernetes audit rule before collecting bodies", "item": "https://update.dsesecurity.com/updates/review-the-first-matching-kubernetes-audit-rule-before-collecting-bodies/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/review-the-first-matching-kubernetes-audit-rule-before-collecting-bodies/#article", "identifier": "https://update.dsesecurity.com/updates/review-the-first-matching-kubernetes-audit-rule-before-collecting-bodies/", "url": "https://update.dsesecurity.com/updates/review-the-first-matching-kubernetes-audit-rule-before-collecting-bodies/", "headline": "Review the first matching Kubernetes audit rule before collecting bodies", "description": "Kubernetes audit policy uses the first matching rule. Check the chosen level and resource scope before enabling request or response bodies in the retained…", "abstract": "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.", "articleBody": "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.\nSource fact: documented behavior\nThe Auditing documentation is the primary reference.\nKubernetes 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact API request and resource or subresource must be recorded?\nWhich rule matches first in the complete policy?\nWhat information is necessary beyond event metadata?\nWhere will the owner confirm the actual retained record?\n\nDSE recommendation: test policy decisions with representative requests\nDSE 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.\nReview 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.\nChoose 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.\nInclude 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.\nVerification and evidence\nProposed 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.\nIn 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.\nOfficial references\n\nAuditing — Kubernetes.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T17:40:54+00:00", "dateModified": "2026-10-29T17:41:39+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/review-the-first-matching-kubernetes-audit-rule-before-collecting-bodies/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/review-the-first-matching-kubernetes-audit-rule-before-collecting-bodies/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Review the first matching Kubernetes audit rule before collecting bodies" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 525, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes — Auditing", "url": "https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/" } } ] } }