"Connect to the VPN, then run kubectl" Is Already a Broken Assumption
When teams manage a K3s cluster, most still treat "connect to the VPN first, then access kubectl or the Rancher dashboard" as the obvious workflow. K3s zero trust management access design starts by questioning that exact assumption: that anyone who gets onto the corporate network should be trusted.
Now that remote work is the norm and cluster operations teams span multiple sites and multiple clouds, perimeter-based security — which grants trust based on whether you're "inside the VPN" — has a structural weakness. NIST's Special Publication 800-207 on Zero Trust Architecture frames this shift as moving "from a network-centric perimeter defense to a defense that protects individual resources." Now that remote users and cloud assets routinely sit outside the corporate network boundary, the very idea of splitting trust levels by "inside vs. outside the perimeter" has broken down at its foundation.
K3s cluster management access is no exception. A single kubectl command, a single login to the Rancher dashboard, can become a gateway to the entire cluster. If that gateway is protected only by a single line of defense — the VPN — the biggest risk is that once that line is breached even once, there's no mechanism left to stop lateral movement. If you'd rather not build this design from scratch, there are managed K3s options where the management access model comes visualized out of the box (Kubo's Captain UI, for example, is one such option). But first, let's work through the underlying principles.
Zero Trust Isn't About "Removing the Perimeter" — It's About "Always Verifying"
A common misunderstanding is treating zero trust as "removing the perimeter" or "getting rid of firewalls." In reality it's the opposite: zero trust is a design philosophy that stops relying on a single line of defense and instead adds layers of verification to every access request.
Teleport's explainer on Zero Trust Network Access (ZTNA) defines ZTNA as "a security model that grants access based on verified identity and context rather than network location." The core principle is "Never Trust, Always Verify" — every access request is authenticated and authorized each time, granting only the minimum access scoped to that session. Unlike a VPN, where connecting once exposes the entire internal network, ZTNA is designed so that resources remain invisible until access is authorized.
CNCF's (Cloud Native Computing Foundation) article "Seven Zero Trust Rules for Kubernetes" translates this thinking into practical guidance for Kubernetes operations. The key points: leverage existing OSS and API management mechanisms rather than bolting on complex new dedicated tools, automate certificate rotation so it's invisible to developers, and apply the same principles to both the data plane and the control plane — and to both east-west and north-south traffic. Many teams stop at securing management access alone (control plane, north-south traffic) and call it done, but that's only half the job — a point that matters just as much when designing K3s management access.
Kubernetes' own authorization mechanism, RBAC (Role-Based Access Control), is the foundation for this verification. According to Kubernetes' official RBAC documentation, permissions are defined by combining four objects — Role, ClusterRole, RoleBinding, and ClusterRoleBinding — and permissions are purely additive; there is no "deny" rule. In other words, how far zero trust's "least privilege" principle can be expressed using Kubernetes' native features is the actual starting point for the design.
Three Steps to Making K3s Management Access Zero Trust
Translating these abstract principles into actual K3s operations breaks down into three broad steps.
Step 1: Integrate an Identity Provider So You Can Prove "Who"
Most VPNs tend to rely on shared credentials or long-lived passwords, but the foundation of zero trust is identity itself. You need to connect an SSO-based identity provider to Kubernetes RBAC so every individual gets a verifiable identity. For K3s management platforms like Rancher, SUSE's official Rancher documentation shows the standard setup: an authentication proxy integrates with local auth, Active Directory, GitHub, and other external identity providers, and mediates every API call to downstream K3s/RKE2 clusters. Routing everything through this authentication proxy layer lets you centrally track who accessed which cluster and when.
Step 2: Aggregate Access Through a Proxy — Without Opening Firewall Ports
The next essential piece is consolidating access to kubectl and the Rancher dashboard through an outbound tunnel connection, instead of opening firewall ports or relying on a fixed-IP VPN. Cloudflare's technical writeup on "kubectl with zero trust" describes routing traffic to the Kubernetes API server through Cloudflare Tunnel, disabling HTTP inspection to support mTLS (mutual TLS), and applying gateway policies such as device posture checks and session management. Engineers simply enable a zero trust agent instead of launching a VPN client, and standard kubectl commands work exactly as before. The decisive difference from the VPN approach is that you secure a path to the cluster without opening a single firewall hole.
Step 3: Track "What Was Executed" with Session-Level Audit Logs
The last essential piece is an audit log mechanism that lets you trace not just who accessed the cluster and when, but what they actually executed. Once you consolidate the zero trust access path through a proxy, that proxy layer can record session-level operation logs. Whether you can reconstruct "exactly what commands were run and in what sequence" rarely shows up in day-to-day operational overhead, but it dramatically affects how fast you can respond during an incident or postmortem. Building this audit logging foundation from scratch — alongside a monitoring stack like Prometheus and Grafana — is quietly a lot of engineering effort, and with a managed K3s offering like Kubo that ships monitoring built in, this part of the build simply isn't needed.
The Common Pitfall — Securing Management Access Alone Is "Only Half the Job"
All three steps above address management access coming "from outside the cluster into it." But as CNCF's seven rules pointed out, zero trust means nothing if it only applies to the control plane and not the data plane.
In other words, no matter how strictly you zero-trust-secure access to kubectl, if a pod that's been compromised inside the cluster can freely communicate with any other pod, your defense ends right there. What's needed here is a mechanism that cryptographically verifies workload-to-workload identity. SPIFFE (Secure Production Identity Framework For Everyone), a CNCF Graduated project, is a standard that issues a unified identity to workloads across different platforms — virtual machines, cloud, and data centers — enabling mutually authenticated service-to-service communication without passwords or API keys.
Linkerd is tackling this problem from the service mesh side. According to an explainer published by Buoyant (Linkerd's creator), a service mesh transparently applies mTLS to pod-to-pod communication, delivering three guarantees: authentication, confidentiality, and integrity. On top of that, you can operate zero trust's two core principles — "verify every access to every resource, every time" and "enforce least privilege" — as a unified authorization policy. If you only lock down the front door of management access and leave pod-to-pod communication inside the cluster wide open, the three steps described in this article are no different from "changing the front door lock while leaving every door inside the house unlocked."
Conclusion — From Perimeter-Dependent Design to Identity-Dependent Design
Making K3s management access zero trust isn't really about "getting rid of the VPN." What matters is replacing a design that splits trust levels by inside vs. outside the perimeter with one that verifies every request based on identity and context. Only by stacking identity provider integration, proxy-based access aggregation, and session-level audit logging — and by extending that thinking to workload identity inside the cluster — does a truly "boundary-free" management access design come together.
That said, building this design from scratch is no small undertaking. Identity provider integration, building a proxy layer, standing up audit log infrastructure, rolling out a service mesh and operating mTLS — the burden of building each of these yourself, piece by piece, is exactly the kind of work a managed K3s service should take off your plate. Kubo provides a production-grade K3s-based Kubernetes environment together with a visualized management console, "Captain UI," offering a governed access model out of the box instead of requiring you to piece together kubectl- or Rancher-style management access on your own.
If you're considering moving away from VPN-dependent access, start by taking stock of how much your current cluster management access still depends on "the perimeter." If you'd like to rethink that design from the ground up, you can get in touch for a free consultation.