Orphan Pod Masquerading
Creating orphan pods that mimic controller-managed naming conventions to blend in with legitimate workloads
An orphan pod is a pod without an owner reference, meaning it was created directly rather than by a controller like a Deployment or DaemonSet. Attackers can exploit this by creating orphan pods that mimic the naming conventions of controller-managed pods, making malicious workloads blend in during casual inspection.
When a Deployment is created, Kubernetes generates a ReplicaSet with a pod-template-hash, then the ReplicaSet creates Pods. The hash is computed using the 32-bit FNV-1 against the PodTemplateSpec, then encoded using SafeEncodeString to produce a 9-10 character alphanumeric string. The resulting Pod name follows the pattern [deployment-name]-[hash]-[random]:
nginx-5d6f7b8c9-x4k2m
│ │ │
│ │ └── Random 5-character suffix
│ └── Pod template hash (from ReplicaSet)
└── Deployment name
The pod-template-hash is stored in .metadata.labels.pod-template-hash:
kubectl get pod nginx-5d6f7b8c9-x4k2m -o jsonpath='{.metadata.labels.pod-template-hash}'
5d6f7b8c9
An attacker can manually create a Pod that mimics this naming pattern:
apiVersion: v1
kind: Pod
metadata:
name: nginx-5d6f7b8c9-m4l1c
labels:
app: nginx
pod-template-hash: 5d6f7b8c9
spec:
containers:
- name: nginx
image: malicious
At first glance, this Pod appears to belong to the nginx Deployment. The name follows the expected pattern, and the labels match what you’d expect from a legitimate Pod. During a quick kubectl get pods review, this malicious Pod would blend in with the other nginx replicas, making it difficult to identify without deeper inspection.
DaemonSet Naming
DaemonSets create Pods directly without an intermediate ReplicaSet, making them another target for spoofing. Since DaemonSets run one Pod per node, an attacker might create a fake DaemonSet pod to blend in with system-level workloads like log collectors or monitoring agents. The naming pattern is [daemonset-name]-[random]:
fluentd-x7k9m
│ │
│ └── Random 5-character suffix
└── DaemonSet name
An attacker can create an orphan pod mimicking this pattern to blend in with monitoring or logging infrastructure that typically runs as DaemonSets.
Legitimate Orphan Pods
Not all orphan pods are malicious. Legitimate orphan pods exist in these cases:
- Pods created directly using kubectl run with
--restart=Neverfor debugging or one-time tasks - Pods created directly from pod manifests using
kubectl create -f pod.yamlfor testing or specific workloads
Impact
Orphan pods disguised as controller-managed workloads can evade casual inspection and complicate incident response
Mitigation
- Verify pod ownership using
.metadata.ownerReferences - Monitor for pods without valid owner references
References
- Owners and Dependents
- Why Kubernetes Compares With Hash
- ComputeHash Source Code - Where pod-template-hash is generated