[REVIEW] log-analysis: add Kubernetes audit event evidence gates

[malb200710-dev]

Skill Being Reviewed

Skill name: log-analysis
Skill path: skills/secops/log-analysis/

False Positive Analysis

Benign Kubernetes audit activity that should not be treated as suspicious admin abuse:

{
  "verb": "update",
  "user": {"username": "system:kube-controller-manager"},
  "userAgent": "kube-controller-manager/v1.30.0",
  "objectRef": {"resource": "leases", "namespace": "kube-system"},
  "responseStatus": {"code": 200},
  "stage": "ResponseComplete"
}

Why this is benign:
Kubernetes controllers and operators generate frequent update, patch, and create events as part of normal reconciliation. Log analysis needs user, userAgent, objectRef, namespace, stage, and responseStatus context before escalating write verbs.

Coverage Gaps

The skill covers Windows, Linux, network, cloud audit, and application logs, but does not require Kubernetes API audit evidence. That can miss high-signal cluster events or over-flag normal controller traffic.

Missed variant 1: interactive pod command execution

{
  "verb": "create",
  "objectRef": {"resource": "pods", "subresource": "exec", "namespace": "prod", "name": "api-7f9"},
  "user": {"username": "alice@example.com"},
  "sourceIPs": ["203.0.113.10"],
  "responseStatus": {"code": 101},
  "stage": "ResponseStarted"
}

Why it should be caught:
pods/exec, pods/attach, and pods/portforward can represent interactive access into workloads. The analysis should preserve subresource, user, source IP, userAgent, and response status rather than collapsing the event into a generic create.

Missed variant 2: impersonation and delegated access

{
  "verb": "get",
  "user": {"username": "bob@example.com"},
  "impersonatedUser": {"username": "system:serviceaccount:prod:deploy-bot"},
  "objectRef": {"resource": "secrets", "namespace": "prod"},
  "responseStatus": {"code": 200}
}

Why it should be caught:
Impersonation changes who the request acts as. Reviews that only look at user.username can miss delegated access, break attribution, or fail to identify risky impersonation permissions.

Missed variant 3: failed RBAC probing and noisy denials

{
  "verb": "list",
  "objectRef": {"resource": "secrets", "namespace": "prod"},
  "responseStatus": {"code": 403},
  "userAgent": "kubectl/v1.30.0"
}

Why it should be caught:
Denied events are not successful compromise, but repeated 401/403 activity against sensitive resources can indicate RBAC probing. The skill should separate denied reconnaissance from allowed sensitive access.

Edge Cases

• RequestReceived events may lack final authorization outcome; prefer ResponseComplete for outcome analysis and ResponseStarted for long-running exec/attach/portforward streams.
• Kubernetes audit policy level affects available fields. Metadata may omit request/response body, while RequestResponse can expose sensitive data and needs handling rules.
• System users and controllers can legitimately touch secrets/configmaps/leases; baseline by user.username, groups, userAgent, namespace, and objectRef.
• Managed Kubernetes services may route audit logs through cloud-native logging with provider-specific field names, but the core audit fields should still be mapped.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add Kubernetes audit log evidence gates requiring verb, stage, user, impersonatedUser, sourceIPs, userAgent, objectRef, requestURI, responseStatus, audit policy level, sensitive subresource handling (exec, attach, portforward, secrets), and false-positive guidance for controllers/operators.

Comparison to Other Tools

Tool	Catches this?	Notes
Kubernetes audit docs	Partial	Document stages and fields, but the skill does not ask analysts to preserve them.
Kubernetes audit policy docs	Partial	Explain audit levels and rules, but not how to triage security findings.
MITRE ATT&CK Kubernetes data components	Partial	Identify pod creation/command execution data sources, but require local evidence mapping.
Generic log analysis	No	Treats events as generic JSON and loses Kubernetes-specific verb/subresource semantics.

Sources Checked

• Kubernetes Auditing: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
• Kubernetes kube-apiserver Audit Configuration v1: https://kubernetes.io/docs/reference/config-api/apiserver-audit.v1/
• Kubernetes User Impersonation: https://kubernetes.io/docs/reference/access-authn-authz/user-impersonation/
• MITRE ATT&CK Container Administration Command T1609: https://attack.mitre.org/techniques/T1609/

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: to be provided privately after maintainer acceptance

[malb200710-dev]

Implementation PR opened: #1558

It adds Kubernetes audit source coverage, event evidence gates, high-signal patterns, false-positive guards, a pitfall, and Kubernetes/MITRE references.