The Kaja Team
Secure access to private Kubernetes clusters without exposing them
Run clusters with no public IP and still reach your apps. Here's how secure tunneling and built-in VPN keep everything locked down.
Many teams want Kubernetes clusters that don't expose a public API or ingress. That improves security but makes it harder to access apps and run operations from outside the network. Opening firewalls or punching holes is exactly what we want to avoid.
With Kaja, you can keep clusters fully private and still get secure access:
- Secure tunneling — The Kaja agent establishes an outbound tunnel to the control plane. No inbound ports, no public IPs. You reach your apps through Kaja's secure channel.
- Built-in VPN (WireGuard) — Register your laptop or CI runner with Kaja and connect over the built-in VPN. Access exposed services as if you were on the cluster network—no separate VPN product to run.
- RBAC — Who can see which clusters and apps is governed by role-based access control, so access is consistent and auditable.
Why outbound-only matters
Traditional setups often require opening the Kubernetes API or an ingress controller to the internet (or a VPN). That expands your attack surface: every open port is a potential target. With an outbound-only agent, the cluster initiates the connection to Kaja. There's nothing for an external scanner to hit. No open inbound ports, no public IPs on the cluster. The control plane can still send commands and stream logs/metrics over that same tunnel—you get full functionality without exposing the cluster.
Using the built-in VPN
Once the cluster is connected via the agent, you need a way for developers (or CI) to reach apps running inside it. Instead of maintaining a separate VPN—OpenVPN, Tailscale, or a cloud VPN—we bundle WireGuard. You register your device (laptop, runner) with Kaja and get a VPN config. Connect once, and you can hit internal services, debug from your machine, or run integration tests from CI. Access is scoped by the same RBAC: if you can't see the app in the UI, you don't get network path to it either.
Keeping it auditable
RBAC doesn't just protect production. It makes it clear who can create environments, deploy apps, or view logs. When everything goes through the control plane, you have one place to define roles and one place to audit "who did what." That's especially important for compliance and for teams that want to give developers autonomy without giving them keys to everything. Private clusters plus tunneling plus RBAC give you lock-down without locking out your team. We'll go deeper on architecture in a future post.