Kubernetes Access to a VPC Private Subnet Through a Proxy
Deploying a proxy for Kubernetes access into a VPC private subnet is direct, if you control the moving parts. The goal is simple: allow cluster workloads to communicate with private resources while keeping the subnet unreachable from the public internet.
1. Control the network paths.
In AWS, create a private subnet inside your VPC. No internet gateway. No public IPs. Configure route tables to send traffic to a proxy host or NAT instance in a public subnet, or an internal jump proxy reachable over peered connections. Kubernetes nodes in this subnet will reach the proxy only, never a public endpoint directly.
2. Deploy the proxy service.
Run the proxy as a Deployment or DaemonSet in Kubernetes, if the cluster can span subnets. Alternatively, place the proxy outside the cluster—on an EC2 instance or AWS Load Balancer—and point your pods to it with environment variables or sidecars. Use Nginx, HAProxy, or Envoy for HTTP(S), or SOCKS5 proxies for raw TCP. Ensure the proxy enforces ACLs so only authorized pods can send traffic.
3. Configure Kubernetes networking.
Update Service manifests to route external traffic through the proxy. If you use DNS, point service endpoints to the proxy host. With Istio or another service mesh, set egress rules to force all external calls through the proxy, keeping the source private subnet hidden.
4. Secure everything.
Lock down security groups to allow only proxy traffic between Kubernetes nodes and target private resources. Enable TLS wherever possible. Monitor logs from the proxy for anomalies.
Example deployment flow:
- Create private subnet in VPC.
- Deploy Proxy host in public subnet or reachable peer.
- Update route tables to point to Proxy.
- Deploy pods with proxy configuration.
- Test access to private endpoints.
Done right, this setup lets Kubernetes access a VPC private subnet through a proxy deployment with zero public exposure. Fast. Controlled. Auditable.
See how it works in minutes — run it live with hoop.dev.