All posts

The firewall let me in, but Kubernetes said no

The firewall let me in, but Kubernetes said no. That’s the moment you realize Network Policies aren’t just guardrails. They’re the wall, the gate, and the keyholder—especially when you’re trying to manage SSH access through a proxy inside a Kubernetes cluster. Kubernetes Network Policies define exactly who can talk to whom, on which port, and when. Without them, any pod can reach any other pod. With them, you shape the flow of connections until it’s locked to your exact needs. When SSH is invo

Free White Paper

Just-in-Time Access + Kubernetes RBAC: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

The firewall let me in, but Kubernetes said no.

That’s the moment you realize Network Policies aren’t just guardrails. They’re the wall, the gate, and the keyholder—especially when you’re trying to manage SSH access through a proxy inside a Kubernetes cluster.

Kubernetes Network Policies define exactly who can talk to whom, on which port, and when. Without them, any pod can reach any other pod. With them, you shape the flow of connections until it’s locked to your exact needs. When SSH is involved—especially via a proxy—you need precision. One wrong rule and your secure tunnel turns into a dead end.

Continue reading? Get the full guide.

Just-in-Time Access + Kubernetes RBAC: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Why Network Policies and SSH Proxies Collide

A Kubernetes Network Policy doesn’t understand SSH as a protocol. It sees only traffic on TCP port 22 (or whatever port you choose). If you use an SSH proxy to hop into your container environment, Kubernetes enforces whether the pod even hears your knock. Many teams leave policies wide open inside the cluster, thinking the outer layers are enough. That’s a mistake. The strongest security starts inside the cluster perimeter.

How to Enable Secure SSH Access with Network Policies

  1. Define a dedicated namespace for the workloads you need SSH access to.
  2. Label both pods and namespaces so your Network Policies have clear selectors.
  3. Write an allow policy to open SSH access only from your SSH proxy service’s pods or nodes.
  4. Write a default deny policy for all other incoming connections.
  5. Audit the egress rules so SSH is strictly one-way when needed.

When you combine these steps, Kubernetes becomes as strict or as lenient as you demand. The SSH proxy stops being a potential side door and turns into a controlled, auditable entry point.

Common Pitfalls to Avoid

  • Forgetting that Network Policies are additive. An accidental overlap can block your SSH flow.
  • Opening access by CIDR instead of pod selectors, leading to exposure if cluster IP ranges shift.
  • Ignoring DNS and service dependencies for your SSH proxy pod.

Why This Matters for Your Cluster Security

Strong boundaries reduce lateral movement if a pod is compromised. SSH proxy + Network Policies give you control over privileged paths. Without it, you’re relying on trust, not enforcement. Kubernetes was built for services talking to each other, but when you add human access, the rules must be clear and enforced at the packet level.

You can run these setups in minutes without wrestling with YAML in the dark. See it live, configured, and tested on hoop.dev—and turn SSH proxy access in Kubernetes into something you control completely.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts