☸️ Shadow K8s Namespace

Parallel vulnerable namespaces (kube-system-shadow).

→ Explore in ATT&CK matrix (1 mappings) Deployment detail

What it is

A namespace that looks like a system or platform namespace, holding decoy workloads and decoy secrets, run on isolated nodes. Attackers inside a cluster explore system namespaces for privileged credentials. Reading its secrets, exec into its pods or changes to its role bindings are recorded by the Kubernetes audit log, where the platform logs reads.

Implementation requirements

Create a namespace named like a system or platform namespace, holding decoy workloads (D012), decoy Kubernetes Secrets (honeytokens) and plausible ConfigMaps
Run it on a separate, tainted node pool or a separate decoy cluster. A deliberately weak-looking workload on a shared node can become a stepping stone if it is actually exploitable
Monitoring: audit-policy rules for get and list on Secrets in the namespace, pods/exec and pods/attach on its pods, and RoleBinding changes in it. Add a runtime sensor rule for shells in its containers
Managed clusters, check before relying on it: EKS, turn on the audit control-plane log type (off by default). AKS, add a diagnostic setting with category kube-audit; the cheaper kube-audit-admin leaves out get and list. GKE, writes go to Admin Activity logs (always on) but get and list go to Data Access logs, which are off by default. Self-managed, the API server logs nothing until it is started with an audit policy. Reading a decoy Secret is a get: on AKS with kube-audit-admin, or on GKE without Data Access logs, it is never recorded
Safety: its service accounts are bound to no roles outside the namespace, a NetworkPolicy blocks egress, and nothing is actually vulnerable. OPSEC: labels, annotations and image versions like the namespace it imitates
Rollback: Delete the namespace, its node pool or decoy cluster, and its audit rules.
Upkeep: Keep image versions in step with the namespace it imitates. Monthly proof-of-life Secret read.

Technologies

KubernetesAWSAzureGCP

ATT&CK coverage 1

Technique	Tactic	Status	Confidence	Tier
T1543.005 Container Service	Privilege Escalation	theoretical	moderate	T4
↳ Detection point: seen once the attacker is working inside a high-fidelity decoy
↳ Evidence (2 sources) Container Orchestration Honeypot: Observing Attacks in the Wild — On Docker/Kubernetes honeypots attackers created privileged containers, Pods and a DaemonSet, ran bash payloads, escaped to the host and planted SSH keys and cron jobs. MITRE ATT&CK Enterprise v20.0 — ATT&CK v20 documents T1543.005 Container Service as an adversary behaviour.

Evidence

Decoy Environment (D3-DE) — MITRE D3FEND standard
Container Orchestration Honeypot: Observing Attacks in the Wild — Spahn, N.; Hanke, N.; Holz, T.; Kruegel, C.; Vigna, G., RAID 2023 peer-reviewed
MITRE ATT&CK Enterprise v20.0 — MITRE 2026 standard