Securing Kubernetes APIs Across Clouds Without a VPN

Kudelski Security, a managed security services provider, faced a familiar problem when migrating its internal infrastructure to multi-cloud environments: how to give developers secure, identity-based access to Kubernetes (K8s) control-plane APIs running across AWS, other public clouds, and on-premises clusters. Their solution, an internal tool called k8s-tunnels, wraps Cloudflare’s Identity-aware Proxy (IAP) and cloudflared daemon into an automated workflow that surfaces available clusters, authenticates users via SSO, and establishes a SOCKS5 proxy — all without exposing APIs to the public internet or requiring a VPN.

The Problem: Many Clusters, Many Credentials

Kudelski Security’s engineering teams rely heavily on GitOps for automated deployments. Still, they regularly need direct access to cluster APIs to pull logs or debug issues. As the number of clusters across cloud providers grew, so did the friction for developers: different credentials for each cluster, different configuration files, and no clear visibility into which clusters existed or which they were authorized to use.

Traditional access methods compounded the problem. Exposing cluster APIs to the public internet was ruled out as an unacceptable expansion of the attack surface. Broad internal network access would invite lateral movement. And VPNs, which would need to be deployed across a growing workforce and multiple clouds, presented expensive scaling and operational challenges. The team wanted a model with small, micro-segmented environments and a single, consistent way to reach each service.

A Proxy Per Cluster

Kudelski Security’s approach was to place an Identity-aware Proxy (IAP) in front of each K8s cluster. Each IAP enforces its own Zero Trust policies, checking user identity against corporate SSO and contextual signals like device posture. Critically, the IAP augments rather than replaces the cluster’s native authentication mechanism, layering an additional check on top via federation.

The user experience is straightforward for browser-based applications, but K8s engineers work with CLI clients like kubectl and k9s. CLI network flows cannot be redirected through a browser, so the IAP must instead act as a SOCKS5 proxy between the client and the cluster API. Cloudflare’s cloudflared daemon provides the encrypted connection from the user’s machine to the cluster, handled on Cloudflare’s network with Zero Trust policy inspection.

Without automation, however, each developer would need the daemon manually installed and configured for each cluster. The team would also lack a centralized view of what clusters exist and who should have access to them — a setup destined to become a maintenance burden.

k8s-tunnels: Automating Discovery and Access

The engineering team built k8s-tunnels to embed those complex configuration steps behind a simple interface. The tool bundles the cloudflared daemon and SDKs for the public cloud providers Kudelski Security uses. By reading existing resource tags, it automatically discovers all K8s clusters a given user is authorized to access, based on the Zero Trust policies already defined.

A typical session proceeds like this:

  • The user selects one or more clusters from a list the tool presents.
  • k8s-tunnels opens an encrypted connection to Cloudflare and exposes a local SOCKS5 proxy.
  • The tool updates the user’s local Kubernetes client configuration to route through that proxy, then switches the active context to the selected cluster.
  • The user launches kubectl, k9s, or any other CLI client as usual — the tunnel operates transparently in the background.

Discovery runs only once; the tool caches the cluster list in a local config file. When a new engineer joins the team, they simply launch k8s-tunnels, authenticate through the corporate identity provider, and the list of accessible clusters is populated automatically. Kudelski Security estimates this saves each new developer at least two hours of documentation reading, ticket submission, and manual tool configuration.

Extending Automation to On-Prem and Parallel Tunnels

Public cloud providers use resource tags to store cluster metadata, but on-premises deployments lack that mechanism. To replicate the same auto-discovery flow, Kudelski Security used HashiCorp Vault as a key-value store, allowing on-prem clusters to be labeled and discovered with the same process used for public cloud.

Another enhancement addresses a common developer workflow: comparing workloads running in production and staging. Instead of opening and closing tunnels when switching between clusters, k8s-tunnels supports opening multiple tunnels in parallel within a single instance. Developers can switch the destination cluster context on their laptop without re-establishing connections.

The team has also added support for favorites and notifications on new releases, leveraging Cloudflare Workers.

## Working With the Kubernetes Community

Building k8s-tunnels surfaced issues inside Kubernetes client libraries when used with SOCKS5 proxies. Kudelski Security is working with the Kubernetes community on patches aimed at fixing these issues.

While the tool remains too specific to Kudelski Security for general release, the team intends to share what they’ve built with the broader Kubernetes community so other organizations can apply a similar Zero Trust model to complex, multi-cloud workloads without sacrificing end-user experience.