Kubectl now works through Cloudflare Access and Argo Tunnel
Cloudflare Access now supports kubectl, giving teams an alternative to VPNs when managing Kubernetes clusters. The company built the integration to address a specific gap that kept Cloudflare itself—and many of its customers—from retiring the VPN entirely.
The setup pairs Cloudflare Access for identity-based, per-request checks with Argo Tunnel for secure connectivity. Administrators can add SSO requirements and a zero-trust access model to Kubernetes management without changing how developers interact with the cluster through kubectl.
Where kubectl normally sits
A Kubernetes deployment is split between nodes that run containers and a control plane that manages them. The Kubernetes API server is the central component of that control plane, and kubectl is the command-line tool users run to talk to it—starting and stopping nodes, modifying control plane elements, and so on.
In typical setups, users connect through a VPN to reach the API server on the local network. That architecture backhauls all management traffic through a physical or virtual VPN appliance. It also tends to grant the user broad access to other addresses and ports on the private network where the cluster runs, rather than limiting them to the API server.
The Access model for non-HTTP traffic
Cloudflare Access already secures web applications and non-HTTP connections such as SSH and RDP; kubectl commands now fit the same pattern. Cloudflare's network sits in front of the protected resource, checking identity on every request. If no identity is present, the user is redirected to the team's SSO provider—Okta, AzureAD, G Suite, etc.—and, once logged in, checked against an allowlist before the request is passed through.
That per-request check usually carries a performance cost, but Access keeps it low by doing the work on Cloudflare Workers in every one of its 200+ data centers globally. Authentication completes in milliseconds no matter where the user sits relative to the cluster.
Two tunnels to replace the VPN
Deploying Access for kubectl requires two connections to Cloudflare's network:
- Connect the cluster to Cloudflare with Argo Tunnel
- Connect the client machine to the cluster, also via Argo Tunnel
Connecting the cluster
On the cluster side, Argo Tunnel runs the cloudflared daemon, which creates a secure outbound tunnel to Cloudflare. The daemon can run anywhere with TCP access to the kubectl API server.
An administrator first authenticates the cloudflared instance by logging in with a Cloudflare account in a browser and picking a hostname. Cloudflare then issues a certificate to the daemon for creating a subdomain for the cluster. After that, the tunnel is started, with hostname set to any subdomain of the chosen hostname and url pointing to the cluster's API server.
cloudflared tunnel --hostname cluster.site.com --url tcp://kubernetes.docker.internal:6443 --socks5=true Cloudflare recommends running cloudflared as a systemd service so the tunnel automatically reconnects if the resource restarts.
Connecting from a client
For web apps, end users just authenticate in a browser, no client software needed. Non-HTTP protocols require something else, and kubectl has an extra constraint: users cannot modify kubeconfig to proxy requests through cloudflared. Upstream pull requests to add that functionality exist, but until they land, an alias gets the job done.
The user installs the same cloudflared binary that runs on the cluster. Launching it opens a browser window for SSO login, and once the user is authorized for that hostname, cloudflared serves as a local SOCKS5 proxy. The proxy sits between the local kubectl and the API server, avoiding TLS handshake complications while still letting TLS verification happen normally between the client and the cluster.
$ cloudflared access tcp --hostname cluster.site.com url --127.0.0.1:1234To avoid repeating the connection steps each session, users can add an alias that chains all the required commands into one. Putting the alias in the bash profile keeps it available across restarts.
$ alias kubeone="env HTTPS_PROXY=socks5://127.0.0.1:1234 kubectl"Dogfooding caught the rough edges
Cloudflare ships new products to its own organization first, and the kubectl release followed that pattern. When the team managing Cloudflare's own Kubernetes deployments reviewed the prototype, the response was not a light suggestion for polish—they told the Access team to stop.
The flow was technically sound but required a small certificate-handling change that would be a daily annoyance for engineers who spend their working hours in kubectl. What looked like a minor step in testing was a real friction point in practice. The Access team shelved the release, reworked that part of the flow with input from the Kubernetes team, and held it until the internal group agreed the result was better than the status quo.
Availability and next steps
Support for kubectl is live in the latest cloudflared release and available on any Cloudflare plan. Detailed setup instructions are published on Cloudflare's developer documentation site. Cloudflare is asking for community feedback on the ease of use as it continues developing the feature.
