Secure Kubernetes Access to VPC Private Subnets with an Internal Proxy

You can’t reach your Kubernetes workloads in a VPC private subnet without punching dangerous holes in security. You need controlled access. You need a proxy that works inside the private network. And you need it deployed in minutes, not hours.

Kubernetes access to a VPC private subnet is often blocked by design. This is good for security, but a headache for connectivity. Many teams still route through public gateways, exposing nodes to the open internet. A better pattern is to deploy a secure proxy service inside your private subnet, reachable only through verified channels.

A proxy inside a Kubernetes cluster, running in a private subnet, can be the single entry point to your private workloads. Combined with network policies, security groups, and identity-aware gateways, it provides tight control over traffic. You eliminate public exposure, reduce attack surface, and keep compliance auditors happy.

Here’s what makes this approach effective:

• The proxy runs as a Kubernetes Deployment or DaemonSet inside the private subnet.
• Connections come through a secure tunnel or a peered internal network.
• No public IPs are exposed on pods or load balancers.
• Access control is tied to user identity and request context, not just network location.

Deploying this setup usually involves:

1. Creating or using a VPC with private subnets.
2. Running your Kubernetes workloads entirely in these subnets.
3. Deploying a proxy (nginx, Envoy, HAProxy, or custom) as a Kubernetes workload.
4. Routing inbound traffic through private networking or a secure ingress tunnel.
5. Enforcing RBAC and network policies for fine-grained control.

This method works across major cloud providers. In AWS, the VPC private subnet is connected via PrivateLink or a VPN. In GCP, you can use VPC Service Controls and private IP access. Azure provides similar private endpoints. The principle is always the same: no open public path, strict ingress control, and proxy-level observability.

Done right, your Kubernetes cluster gains direct, secure VPC access without any public exposure. Your proxy acts like a sentry inside the walls, logging every packet, enforcing every policy, and refusing every unverified request.

If you want to skip the manual build and watch it run live in minutes, see how it works with hoop.dev. You can set up Kubernetes access to a VPC private subnet with a secure proxy without touching a single public port, and see it in action before you finish your coffee.