Individual skill

analyzing-kubernetes-audit-logs

Parses Kubernetes API server audit logs (JSON lines) to detect exec-into-pod, secret access, RBAC modifications, privileged pod creation, and anonymous API access. Builds threat detection rules from audit event patterns. Use when investigating Kubernetes cluster compromise or building k8s-specific SIEM detection rules.

internal/tools/skills/data/container-security/analyzing-kubernetes-audit-logs/SKILL.md

Read pinned source

Source commit d42f381ad34843e71a42658e5c57290c713e85af

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Instructions only
Last checked
Nov 7, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
1,307
Repository last updated
Nov 5, 2026
License
Apache-2.0

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Analyzing Kubernetes Audit Logs


## When to Use

- When investigating security incidents that require analyzing kubernetes audit logs
- When building detection rules or threat hunting queries for this domain
- When SOC analysts need structured procedures for this analysis type
- When validating security monitoring coverage for related attack techniques

## Detection Gaps & Validation

- **`level: Metadata` hides the payload:** at Metadata level the `requestObject` is dropped, so privileged-pod detection (`securityContext.privileged`, `hostPID`, capability adds) and secret *values* are invisible. Use `level: RequestResponse` for `pods` create/update and for `clusterrolebindings` to see the escalation body.
- **Subresources are separate:** `pods/exec` and `pods/attach` are distinct from `pods` - a rule matching only `resource == "pods"` misses every shell-in. Match the subresource explicitly.