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.