SSH Access in Kubernetes with Secure Network Policies and Proxies

Pods were dying before anyone could read the logs. SSH into the Kubernetes cluster was blocked, and brute-forcing network access was not an option. The only way through was to understand how Kubernetes Network Policies shape, restrict, and allow SSH access when a proxy stands in the middle.

Kubernetes Network Policies define the allowed traffic between pods and from external sources. They operate at the IP and port level, implemented by the cluster’s CNI plugin. By default, if no policy exists, all traffic is allowed. Once a policy is applied to a pod, all ingress and egress not explicitly allowed is denied.

When you need SSH access to a pod—often for debugging—you cannot bypass these rules. Even if your SSH proxy pod is deployed, Network Policies can block the connection. To make SSH work through a proxy, you must:

1. Tag the target pod with specific labels.
2. Write a NetworkPolicy resource allowing ingress on port 22 from the proxy pod label or namespace.
3. Allow egress from the proxy pod to the target host or namespace.
4. Ensure the CNI plugin supports these rules without silent overrides.

A basic example policy to allow SSH from a proxy namespace looks like this:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: allow-ssh-from-proxy
 namespace: target-namespace
spec:
 podSelector:
 matchLabels:
 role: ssh-target
 ingress:
 - from:
 - namespaceSelector:
 matchLabels:
 name: proxy-namespace
 ports:
 - protocol: TCP
 port: 22
 policyTypes:
 - Ingress

This ensures only pods in proxy-namespace with the correct labels can reach port 22 of your SSH target pods. Egress rules on the proxy must be set too, or the packets never make it out.

For clusters behind strict security boundaries, a layered setup pairs the SSH proxy with ephemeral pods. These short-lived proxy containers accept authenticated connections, then forward them internally to the target pod over the allowed paths. Network Policies keep every other path closed. This approach preserves both security and observability.

Implementing this well requires precise coordination between DevOps and security disciplines. Test with real traffic. Validate changes with kubectl exec and low-level TCP probes before signing off. SSH access in Kubernetes is not about opening doors—it is about creating one safe door and locking every other one.

Want to sidestep the boilerplate and see SSH into Kubernetes work with secure, policy-compliant proxies? Try it live with hoop.dev and get a working setup in minutes.