October 9, 2026 路 #23
A debug pod on the host network
Someone added a debug pod to production. What is the blast radius?
apiVersion: v1
kind: Pod
metadata:
name: net-debug
spec:
hostNetwork: true
hostPID: true
containers:
- name: debug
image: nicolaka/netshoot:v0.13
securityContext:
privileged: true
volumeMounts:
- name: host
mountPath: /host
volumes:
- name: host
hostPath:
path: /Next puzzle in UTC
One try. The first answer sticks.
How to fix it
hostNetwork, hostPID, privileged, and hostPath of / together are full node access. Use kubectl debug with a profile, and ban this shape with admission.
Each flag is a different escape. hostNetwork: true puts the container in the node's network namespace, so it can bind low ports and see node traffic. hostPID: true lets it see and signal host processes. privileged: true drops the capability boundary. hostPath of / mounted at /host is the node's disk. Together this is a root shell on the node, wearing a Pod manifest.
Debug images are not the problem. The scheduling of this manifest into a production namespace is the problem. kubectl debug can attach an ephemeral container to a running pod with a profile that does not include the host's root filesystem.
Fix
Delete the pod. Ban the fields with an admission policy:
spec:
hostNetwork: false
hostPID: false
containers:
- securityContext:
privileged: false
A ValidatingAdmissionPolicy that rejects hostPath path /, hostNetwork: true, and privileged: true outside a dedicated break-glass namespace is the durable version of this review comment.