[substrate] Add Kubernetes ServiceAccount token abuse catalog entry

[gapilongo]

Problem

Kubernetes coverage is thin. When an operator finds a service account token at /var/run/secrets/kubernetes.io/serviceaccount/token inside a pod, there's no catalog entry guiding the next steps (check can-i --list, escalate via overprivileged roles, pivot to control plane).

Acceptance criteria

• New file data/technique_catalog/k8s_sa_token_abuse.yaml:
  • technique_id: k8s_sa_token_abuse
  • attack_ids: [T1552.005] (Unsecured Credentials: Cloud Instance Metadata API — overlaps with k8s service-account auto-mount)
  • aliases: ["k8s SA token", "kubernetes service account token", "/var/run/secrets/kubernetes.io"]
  • defining_conditions:
    • Pod has automountServiceAccountToken: true (k8s default)
    • SA bound to a Role/ClusterRole with usable verbs
  • exploitation_steps: extract token, configure kubectl, run kubectl auth can-i --list, check for namespace pivots, escalate via pod-creation if create pods permission
  • detection_signals: k8s audit log events, Falcon Cloud-Native sensor signatures, Kyverno/OPA policy denials
  • hardened_mitigations: automountServiceAccountToken: false per workload, BoundServiceAccountTokenVolume, OPA policies enforcing least-privilege RBAC
• Concept keywords registered
• Unit test

Pointers

• Schema reference: data/technique_catalog/esc1.yaml
• HackTricks k8s: https://book.hacktricks.xyz/pentesting-cloud/kubernetes-security
• k8s docs: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/

Difficulty

S-M (2-3 hours) — content curation + the exploitation chain has more conditional branches than the IMDS or docker.sock cases.