Which SOC 2 criteria does the Kubernetes audit log support?

It is strong evidence for the access-control and monitoring criteria. LogTriage's compliance mapper ties a credential-access finding (unauthorized secret reads) to CC6.1, a lateral-movement finding (a new ClusterRoleBinding or exec into a pod) to CC6.3, and an exfiltration characterization to CC7.2. The audit log is the ground truth for who accessed which resource, which is exactly what these controls ask you to prove.

Why is a service account reading secrets a CC6.3 concern?

CC6.3 is about role-based access and least privilege. When a service account can list secrets cluster-wide — as attacker-sa does across the production and kube-system namespaces in our sample — that is over-permissioned RBAC, and the audit log is the evidence that the permission was both granted and used. Tightening the RBAC role is the remediation the control expects you to document.

Can the audit log alone prove secret exfiltration for SOC 2?

The audit log proves access — who read which secret and when — which is the detection. Proving the data physically left the cluster needs network telemetry. For response and evidence purposes a secret read by an unauthorized identity should be treated as exposed regardless, and rotated. The audit trail is sufficient to establish the CC6.1 access-control finding.

Does the mapping run without the AI model?

Yes. LogTriage's compliance mapper is static and deterministic — it derives controls from the finding's MITRE tactic and severity, so even a rule-based analysis that never calls Claude still carries the correct SOC 2 control citation on the report.

SOC 2 Evidence from Kubernetes Audit Logs

Why this matters for SOC 2

Kubernetes secrets are base64-encoded rather than encrypted by default, so a single get secrets call with the right RBAC role, or an exec into the right pod, can expose an entire cluster’s credentials at once. The Kubernetes audit log is the only record that someone actually looked — and SOC 2’s access-control and monitoring criteria are precisely the ones that ask you to prove you can see and account for that access. An auditor examining a containerized platform will expect the audit log to be enabled, retained, and reviewed.

What evidence the Kubernetes audit log provides

A user, verb, objectRef, and sourceIPs record of every request to the API server — direct evidence for CC6.1 (Logical and Physical Access Controls)
A record of RBAC changes (a create on clusterrolebindings, such as our sample’s attacker-admin binding) that speaks to CC6.3 (Role-Based Access and Least Privilege)
Evidence that unusual access to sensitive resources is monitored and surfaced, supporting CC7.2 (System Monitoring)
The verb: exec / pods/exec records that show interactive access into running workloads — often the pivot point in a compromise

How LogTriage maps this to SOC 2 controls

The Kubernetes audit parser extracts objectRef, verb, and sourceIPs directly and treats secret and exec operations as high-sensitivity regardless of the specific resource name, so the detection does not depend on a hand-maintained list of “important” secrets. The compliance mapper then keys on the finding’s MITRE tactic: a credential-access characterization (unauthorized secret reads) maps to CC6.1, a lateral-movement characterization (a new ClusterRoleBinding granting broad rights, or exec into a pod) maps to CC6.3, and an exfiltration characterization maps to CC7.2 (System Monitoring). The mapping is deterministic and appears on every report. For the detection logic behind it, see the Kubernetes secret exfiltration use case and the guide on analyzing Kubernetes audit logs.

Evidence checklist

Confirm audit logging is enabled at Metadata level for all requests and RequestResponse for sensitive resources, and that the output is centrally retained
List every secret accessed by any non-infrastructure identity, with sourceIPs and timestamps, as CC6.1 access evidence
Retain RBAC-change records (ClusterRoleBinding / RoleBinding create/update) and tie each to an approved request for CC6.3
Document that unusual secret or exec access actually surfaced in review, not just that it was loggable, for CC7.2
Rotate every credential contained in any secret read during a suspicious window — assume exposure, not intent

Frequently Asked Questions

Which SOC 2 criteria does the Kubernetes audit log support?: It is strong evidence for the access-control and monitoring criteria. LogTriage's compliance mapper ties a credential-access finding (unauthorized secret reads) to CC6.1, a lateral-movement finding (a new ClusterRoleBinding or exec into a pod) to CC6.3, and an exfiltration characterization to CC7.2. The audit log is the ground truth for who accessed which resource, which is exactly what these controls ask you to prove.
Why is a service account reading secrets a CC6.3 concern?: CC6.3 is about role-based access and least privilege. When a service account can list secrets cluster-wide — as attacker-sa does across the production and kube-system namespaces in our sample — that is over-permissioned RBAC, and the audit log is the evidence that the permission was both granted and used. Tightening the RBAC role is the remediation the control expects you to document.
Can the audit log alone prove secret exfiltration for SOC 2?: The audit log proves access — who read which secret and when — which is the detection. Proving the data physically left the cluster needs network telemetry. For response and evidence purposes a secret read by an unauthorized identity should be treated as exposed regardless, and rotated. The audit trail is sufficient to establish the CC6.1 access-control finding.
Does the mapping run without the AI model?: Yes. LogTriage's compliance mapper is static and deterministic — it derives controls from the finding's MITRE tactic and severity, so even a rule-based analysis that never calls Claude still carries the correct SOC 2 control citation on the report.

See your compliance mapping generated automatically

Every LogTriage report includes a deterministic compliance mapping — SOC 2, PCI DSS, HIPAA, NIST CSF, and ISO 27001 — stamped on every report, AI-generated or rule-based.

Try Live Demo → Analyze Your Own Logs