Pod, Node or Cluster: What a VPN Sidecar Actually Reroutes

A VPN sidecar in a Kubernetes Pod looks like a host-level VPN with better manners, and the resemblance stops at the namespace boundary. Containers in one Pod share the network namespace, including the address and port space, so a sidecar that installs routes and policy genuinely changes where the application's packets go. It changes nothing for the other Pods on the node, and it does not touch the node's own stack unless you configure it to. Getting that boundary right decides both what you can deploy and what you must test. The sections below follow it from the namespace outward.

Shared namespace, shared consequences

Two containers in a Pod talk over loopback and see the same interfaces, which is why the sidecar pattern works at all: the application does not need to know a tunnel exists, because the route it resolves to was installed in the namespace it uses. The same property means the sidecar's mistakes are the application's mistakes. A route that captures too much, or a DNS change that points at a resolver inside the tunnel, applies to every process in that Pod immediately. There is no per-container routing inside a shared namespace, so a sidecar cannot be scoped to one process.

This is the mechanism to keep in mind during review: the blast radius is the Pod, not the node and not the cluster.

What the sidecar does not reach

Other Pods keep their own namespaces and their own routing, so a workload that needs the same egress needs the same sidecar or a node-level design instead. The node's traffic is also outside the Pod namespace, and host-network Pods deliberately opt out of this isolation entirely. If you run the sidecar with host networking to reach something convenient, you have widened the scope from one Pod to the whole node and should say so out loud.

Cluster service traffic is the other common surprise. A broad default route inside the Pod can capture requests meant for the API server or a ClusterIP service, which then fail in ways that look like the tunnel is broken.

Route plan: Pod, service, node and VPN ranges

Write the four ranges down and check them for overlap before deploying anything: Pod CIDR, service CIDR, node addresses, and the destinations behind the VPN. Overlap between the VPN's private ranges and the cluster's own space is not rare, and a default route is the wrong fix for it. The route plan belongs in the same repository as the manifest, because the next cluster may hand out different Pod and service ranges entirely.

DNS is part of the plan rather than a separate concern. A sidecar that rewrites the resolver configuration can break service discovery inside the cluster while making external lookups work perfectly.

Startup and failure are explicit states

A running sidecar process is not an egress policy. Decide what traffic may flow before the tunnel is ready and what happens if it dies afterwards, then implement that decision: a probe that gates the application container, a network policy that denies by default, or both. Without one of those, the application starts, resolves, and sends traffic out of the node's normal path while the tunnel is still connecting.

That gap is brief in a healthy cluster and permanent in a broken one, which is exactly the property an attacker or an accidental data leak prefers.

Pair the ordering with a failure test. Kill the sidecar and confirm the application loses its intended egress rather than silently falling back.

Capabilities, policies and testing from the app container

Granting the capabilities needed to create interfaces and alter routes is a privilege decision, and a privilege appropriate for an isolated Pod is not automatically appropriate on the node stack. Use the cluster's supported network and security policy mechanisms, and do not assume every CNI or policy implementation treats a VPN interface identically; the differences show up in exactly the failure cases you care about.

Test from the real application container, with fresh requests to a private destination, a cluster service and the public internet. A test run from the sidecar proves the tunnel works, not that the application can reach what it needs.

Document the cluster network assumptions next to the VPN configuration. Moving the workload to another cluster is then an exercise in checking the route plan rather than an image change that quietly stops working.