Securing Kubernetes: Blocking kubectl debug node for stronger cluster safety

Kubernetes clusters often feel secure—until one misstep exposes the entire host. Despite setting runAsNonRoot: true and readOnlyRootFilesystem: true, a single command can shatter your defenses. The culprit? kubectl debug node, a built-in feature that grants root access to the underlying host with minimal restrictions.

The moment an attacker gains access to credentials with sufficient privileges, your carefully configured isolation collapses. This isn’t theoretical. It’s a documented privilege escalation vector that targets the host’s PID, network, and filesystem namespaces. The only way to prevent it is to treat kubectl debug node as a security risk—not a convenience.

How kubectl debug node bypasses your security controls

When you run kubectl debug node/my-node-name -it --image=ubuntu, Kubernetes doesn’t just spin up another pod. It creates a privileged "debugger" pod that bypasses standard restrictions by design. This pod attaches directly to the host’s root filesystem, PID namespace, and network stack—effectively merging the container with the host machine.

This behavior is intentional. Kubernetes allows it because debugging production nodes is sometimes necessary. But in environments where security is paramount, it becomes a dangerous loophole. If a service account or user credential is compromised, attackers can use this feature to move laterally across your infrastructure.

Three layers to permanently disable node debugging

1. Enforce Pod Security Admission at the namespace level

The simplest defense is to stop the debug pod from ever being created. Kubernetes’ Pod Security Admission (PSA) profiles can reject pods that require host-level privileges. By labeling your namespace with pod-security.kubernetes.io/enforce=restricted, you block any pod requesting hostPID, hostNetwork, or sensitive hostPath mounts.

To apply this to your default namespace:

kubectl label --overwrite ns default pod-security.kubernetes.io/enforce=restricted

This change is immediate. Any attempt to run kubectl debug node in this namespace will fail with a clear "Forbidden" error, preventing the debug pod from ever launching.

2. Enforce restricted security cluster-wide with admission configuration

Manual namespace labels are effective but prone to human error. A more reliable approach is to make the restricted profile the default for every new namespace across your cluster. This requires configuring the Kubernetes API server with an AdmissionConfiguration file.

Create a file named admission-config.yaml with the following content:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: PodSecurity
    configuration:
      apiVersion: pod-security.admission.config.k8s.io/v1
      kind: PodSecurityConfiguration
      defaults:
        enforce: "restricted"
        enforce-version: "latest"
      exemptions:
        namespaces:
          - kube-system
          - kube-public
          - k0s-system

This configuration ensures that any new namespace created will automatically enforce the restricted profile. For clusters running k0s, pass this file to the API server by updating /etc/k0s/k0s.yaml:

spec:
  api:
    extraArgs:
      admission-control-config-file: /etc/k0s/admission-config.yaml

Restart the k0s controller, and your cluster-wide security posture tightens without manual intervention.

3. Tighten RBAC to remove debug access from non-admin users

Even with PSA in place, attackers may still target the API endpoints used by kubectl debug node. Specifically, they need access to two critical subresources:

• nodes/proxy — Required for node-level debugging sessions
• pods/ephemeralcontainers — Used for pod-level debugging

Audit your ClusterRoles and ensure that non-admin users do not have permissions to these endpoints. Remove or restrict access in your RBAC policies to eliminate this attack vector entirely.

Test your defenses safely with a local k0s lab

Want to see these protections in action without risking a production cluster? You can simulate a Kubernetes environment inside a Docker container using k0s, a lightweight Kubernetes distribution designed for edge and local development.

Start by launching a privileged container with the k0s image:

docker run -d --name k0s-lab \
  --hostname k0s-lab \
  --privileged \
  -v /var/lib/k0s \
  -p 6443:6443 \
  docker.io/k0sproject/k0s:v1.36.1-k0s.0 \
  k0s controller --enable-worker --ignore-pre-flight-checks

Wait about 15 seconds for the API server to initialize, then extract the kubeconfig:

docker exec k0s-lab k0s kubeconfig admin > ~/.kube/k0s-lab.config
export KUBECONFIG=~/.kube/k0s-lab.config

kubectl get nodes

Now, enforce the restricted profile on the default namespace:

kubectl label --overwrite ns default pod-security.kubernetes.io/enforce=restricted

Attempt to run the debug command:

kubectl debug node/k0s-lab -it --image=ubuntu

Instead of gaining a shell, you’ll receive an immediate rejection:

Error from server (Forbidden): pods "node-debugger-..." is forbidden: violates PodSecurity "restricted:latest": hostNetwork: true, hostPID: true...

Your local lab is now secure—and you’ve proven your cluster’s defenses.

Balancing security with emergency access: the break-glass approach

Blocking kubectl debug node too aggressively can complicate incident response. The solution? Designate a dedicated "break-glass" namespace where emergency debugging is allowed—but only when explicitly invoked.

Create a namespace named break-glass and label it as privileged:

kubectl create ns break-glass
kubectl label ns break-glass pod-security.kubernetes.io/enforce=privileged

To debug a node in an emergency, explicitly target this namespace:

kubectl debug node/k0s-lab -it --image=ubuntu -n break-glass

This creates an audit trail and ensures that day-to-day operations remain secure, while authorized personnel still have a controlled path to resolve critical issues.

The future of Kubernetes security isn’t just hardening—it’s elimination

Security in Kubernetes isn’t about adding layers—it’s about removing unnecessary attack paths. The kubectl debug node command is a powerful tool, but in the wrong hands, it becomes a backdoor. By combining Pod Security Admission, cluster-wide enforcement, and strict RBAC, you can close this vector entirely.

Start with your local lab. Validate your changes. Then apply them to production. The goal isn’t just to detect breaches—it’s to prevent them from ever happening.