← CKS: Kubernetes security in production
07 / 8 · 28 MIN

Auditing and evidence preservation

Collect what is needed without creating new data exposure.

Concept and mechanism

Define the question auditing should answer: who requested an operation, on which object, when, and with what result. Metadata can meet that goal without collecting bodies. Request and RequestResponse add content that may include sensitive data. The first matching rule decides the level; placing a Secret exception after a broad rule can leave exposure unchanged. An event with create pods and 403 shows denial of that request, not a running Pod. Relate events by identity, object, and time while keeping evidence-supported conclusions separate from what still needs confirmation.

Guided application

A missing event is interpretable only after checking coverage, delivery, retention, and time window. A policy file in Git does not prove API-server application or backend receipt. Before rebuilding a node, preserve records existing only locally with origin, integrity, and controlled access. If auditing already copied a credential into a system with more readers, correction must address both future collection and disclosed material. In a fictional banking investigation, coordinate APS, security, and data owners to preserve useful evidence without publishing sensitive contents in a broad channel. Record decisions and limitations for handover across time zones.

IN PRACTICE

A Metadata rule for Secrets should precede a general RequestResponse rule when both can match.

Common pitfalls

Ignoring first-match behavior; missing event treated as negative proof; rebuilding before preservation; logs treated as nonsensitive.

Related topics: Runtime detection and coordinated response · Network boundaries and cluster exposure

Take this idea with you

Investigation quality depends on known coverage, preserved evidence, and controlled exposure.

Create account

Reference: API auditing · Kubernetes v1.35; current six-domain CKS outline