Securing Kubernetes with Wireguard & others

As the cluster grew, I needed secure access to internal services — PostgreSQL, NATS, Redis, ScyllaDB — without exposing them to the public internet. I went through three solutions: WireGuard, Tailscale, and eventually Netbird. Each one taught me something.

The Problem

Early on I was forwarding TCP ports directly through the ingress controller:

tcp:
  "4222": nats/nats-cluster:4222
  "5432": pgo/astring-ha:5432
  "6379": redis/redis:6379
  "9042": scylla/scylla-client:9042

Each service has authentication, so it's not completely open. But exposing databases directly to the public internet is bad practice regardless. I wanted internal services reachable only through a private network, with only HTTP endpoints publicly accessible.

WireGuard

WireGuard is a modern VPN — lightweight, fast, minimal codebase compared to OpenVPN. The core idea: create an encrypted tunnel between your machine and the cluster. Once connected, internal services look like they're on your local network.

Setup on Kubernetes

I deployed WireGuard using Helm:

helm repo add wireguard https://bryopsida.github.io/wireguard-chart
helm repo update

helm install wireguard wireguard/wireguard \
  --namespace wireguard \
  --create-namespace \
  -f values.yaml

values.yaml:

service:
  enabled: true
  type: ClusterIP

wireguard:
  clients:
    - AllowedIPs: 10.34.0.2/32
      PublicKey: <client_public_key>

Expose UDP port 51820 through the ingress:

udp:
  "51820": wireguard/wireguard-wireguard:51820

Client Setup

Generate keys on your local machine:

wg genkey | tee privatekey | wg pubkey > publickey

Get the server's public key from the Kubernetes secret:

kubectl get secret wireguard-wireguard -n wireguard -o yaml | grep publicKey

Client config (wg0.conf):

[Interface]
PrivateKey = <your_private_key>
Address = 172.32.32.2/32
DNS = 10.43.0.10, 8.8.8.8

[Peer]
PublicKey = <server_public_key>
AllowedIPs = 10.0.0.0/16, 10.43.0.0/16, 172.32.32.0/24
Endpoint = <cluster_public_ip>:51820
PersistentKeepalive = 25

Bring the tunnel up: wg-quick up wg0

Done — internal services are now accessible through the tunnel, not exposed publicly.

WireGuard worked. But managing keys manually, updating the Helm values for each new client, and handling the configuration yourself gets old quickly. Also using PodIP was bad, it changes frequently. Then I found Tailscale.

Tailscale

Tailscale is WireGuard underneath, but with everything you'd otherwise build yourself already done — key management, device registration, DNS, access policies, a UI. You don't touch keys manually. You don't write config files. You just install it and devices appear in your network.

Kubernetes Integration

Tailscale has a Kubernetes operator. Install it:

helm repo add tailscale https://pkgs.tailscale.com/helmcharts
helm repo update

helm upgrade \
  --install \
  tailscale-operator \
  tailscale/tailscale-operator \
  --namespace=tailscale \
  --create-namespace \
  --set-string oauth.clientId=<client_id> \
  --set-string oauth.clientSecret=<client_secret> \
  --wait

Then expose a service to your Tailscale network by adding one annotation:

metadata:
  annotations:
    tailscale.com/expose: "true"

That's it. The service gets a Tailscale IP and a DNS name automatically. No UDP port forwarding, no ingress config, no manual key exchange.

What Made It Better

MagicDNS — every device and service on your Tailscale network gets a DNS name. Instead of remembering 10.43.x.x, you connect to postgres.tailnet-name.ts.net. Works automatically.

Access controls from the UI — you define which devices can reach which services through a policy file in the Tailscale dashboard. No YAML in the cluster, no firewall rules to manage manually.

Sharing — you can share specific services with other Tailscale accounts from the UI. Useful for giving someone temporary access without adding them to your cluster.

Multi-platform — Tailscale client runs on Linux, macOS, iOS, Android. Once installed, all your devices are on the same private network automatically.

If you're looking for a simple private networking solution for a Kubernetes cluster — accessing databases locally, connecting team members, securing internal services — Tailscale is the easiest path. I'd recommend it for most use cases.

I used Tailscale as my primary private network for a while and fully replaced WireGuard with it. But then my requirements changed.

Netbird: Why I Moved

Two things pushed me toward Netbird:

Self-hosting potential. Tailscale is a managed service. Your network topology goes through their coordination server. For now that's fine, but I want the option to fully self-host the control plane in the future. Netbird is fully open source — the management server, signal server, everything. I'm currently using Netbird cloud, but the option to move is there.

Multi-DC connectivity. The bigger reason. I have two clusters — Mongolia (on-premise) and Germany (cloud). I need them to communicate directly: NATS supercluster, Cassandra/ScyllaDB cross-DC replication, other services that need pod-to-pod reachability.

The k8ssandra-operator is a good example of why this is hard. It needs pods in one DC to directly reach pods in the other DC by their pod IPs. You can't just expose a LoadBalancer service and call it done — the operator needs the actual pod network to be routable between clusters.

Netbird handles this with its routing architecture. You configure network routes that make each cluster's pod CIDR reachable through Netbird peers. A Netbird peer in each cluster acts as a router for that cluster's network. Traffic between clusters flows through Netbird's encrypted tunnels, but pod IPs on both sides remain directly addressable.

This also works through NAT — the Mongolia cluster is behind NAT, the Germany cluster is on a public IP. Netbird's hole-punching handles the NAT traversal automatically. No static IPs required on the Mongolia side.

I tested this setup — pod-to-pod connectivity between Mongolia and Germany works. The full multi-DC architecture (NATS supercluster, cross-DC ScyllaDB replication) is a separate post.

Netbird on Kubernetes

Install the Netbird client as a DaemonSet or deployment in each cluster, register with your Netbird account, configure routes for the pod and service CIDRs. Each cluster becomes a peer on the Netbird network with routing configured for its internal networks.

The management UI lets you define access policies — which peers can reach which networks, which ports are allowed. Similar to Tailscale's access controls but fully open source.

Summary

• WireGuard — solid foundation, full control, manual everything. Good if you want to understand what's happening underneath or have specific requirements that managed solutions don't cover.
• Tailscale — WireGuard with all the operational work done for you. Best choice for most use cases: local development access, team access, securing internal services. I'd recommend this as the default.
• Netbird — open source Tailscale alternative with better routing architecture for multi-cluster setups. Right choice when you need pod-to-pod reachability across clusters or want self-hosting as an option.

Current state: Netbird for everything. WireGuard and Tailscale are gone.