Identity-aware access for Kubernetes tools is replacing VPN trust

At a glance

What this is: This is a practitioner analysis of replacing VPN-based access to Kubernetes internal tools with identity-aware access, where the key finding is that access control becomes app-specific, identity-driven, and auditable.

Why it matters: It matters because platform, IAM, and security teams gain a clearer way to govern powerful internal tools without granting broad network reach that is hard to scope, revoke, or audit.

Context

In Kubernetes environments, internal tools often inherit access from the network rather than from the user’s identity. That creates a governance gap because VPN reachability is broader than application need, while the tools themselves can expose metrics, deployment controls, and secrets-adjacent operations.

Identity-aware access changes the control point from network membership to application-level policy. For IAM and platform teams, the practical question is no longer how to extend the private network, but how to verify identity, enforce least privilege, and keep an audit trail at the tool boundary.

Key questions

Q: What breaks when Kubernetes internal tools are protected only by VPN access?

A: VPN-only protection breaks least privilege because the user reaches the network, not just the one tool they need. That creates broad access to internal systems such as Grafana or Argo CD, makes revocation coarse, and leaves audit logs unable to show which application was actually used.

Q: Why does per-application access reduce risk for internal engineering tools?

A: Per-application access reduces risk because it ties reachability to identity claims and explicit policy instead of raw network presence. That narrows the blast radius for high-value tools, improves offboarding, and makes third-party access easier to scope than a shared VPN corridor.

Q: How do teams know whether identity-aware access is working for internal tools?

A: It is working when logs show who accessed which application, under what policy, and whether the request was approved or denied. If the only visible evidence is VPN connectivity, the control is still too coarse for meaningful review or incident reconstruction.

Q: When should organisations replace VPN access with identity-aware access for Kubernetes tools?

A: They should do it when internal tools expose deployment, observability, or secrets-adjacent functions and network trust is broader than each user’s actual role. That is especially true for mixed internal and third-party access where rapid revocation and clear audit trails matter.

Technical breakdown

Why VPN trust fails for Kubernetes internal tools

VPNs extend network reach, not application authorization. In a Kubernetes platform, that means anyone who connects can often reach Grafana, Argo CD, GitLab, or Prometheus even when their actual job needs only one tool and a narrow function. This breaks least privilege because the control is attached to the network layer instead of the application or the request. It also weakens auditability because logs show connectivity, not which tool was used or what action was taken. In practice, a VPN creates a coarse trust zone that is too broad for internal operational systems.

Practical implication: Treat VPN access as a transport mechanism, not as the authorization layer for internal tools.

How identity-aware proxying changes the access decision

Identity-aware access inserts a policy decision point in front of the application. The user authenticates through the identity provider, policy evaluates claims such as group membership and context, and only then is the request forwarded to the service. The application remains focused on its own function instead of handling access logic. That separation matters because authorization becomes explicit, per application, and revocable without redesigning the service. It also makes access decisions easier to review during audits because the decision is tied to identity metadata rather than a network session.

Practical implication: Place access policy at the proxy layer so identity, group membership, and context determine reachability.

Why audit logs become materially better than VPN logs

VPN logs normally answer a narrow question: who connected to the network. Identity-aware access logs answer a more useful one: which identity requested which application, under what policy, and whether the request was allowed. For tools like Argo CD or GitLab, that distinction is crucial because access is not the only event that matters. Read/write separation, role-based scope, and support for external contributors all depend on whether the access record captures the application and the user together. Without that linkage, compliance and incident review stay indirect.

Practical implication: Use per-application logging to make access review and incident reconstruction materially more precise.

Breaches seen in the wild

• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Network trust is the wrong abstraction for internal Kubernetes access. VPNs were built to extend reach, not to express per-application authorization. In environments where Grafana, Argo CD, GitLab, and Prometheus all expose different levels of operational power, a network-level gate creates an identity governance mismatch. The practical conclusion is that authorization has to move closer to the application boundary.

Identity-aware access turns auditability from indirect to actionable. A VPN can tell you that a session existed, but not which internal tool was used or which policy was applied. That is a weak foundation for access review, especially where platform operations, CI/CD, and observability all converge. The practitioner consequence is that access records become useful only when identity and application are logged together.

Identity-aware proxying creates a clearer control plane for third-party access. Contractors and external contributors are the hardest users to govern with VPN trust because scope and revocation are usually too coarse. Per-application policy reduces that friction by making access narrower and easier to revoke without dismantling the broader network model. Teams should treat this as a governance change, not just an infrastructure one.

Context-aware access is becoming the default control model for internal tools. The article reflects a broader shift in which distributed engineering teams no longer fit the assumptions behind perimeter access. The named concept here is identity-aware internal access: application entry governed by verified identity and policy rather than network membership. Practitioners should expect internal-tool governance to move toward that model because the old trust boundary no longer matches how teams work.

What this signals

Identity-aware internal access: internal tools are moving toward a model where identity claims and policy determine entry, while the network becomes transport rather than trust. That matters because platform teams can no longer assume that a private network boundary is a meaningful access boundary for Grafana, Argo CD, GitLab, or Prometheus.

For IAM and security teams, the practical signal is that access reviews should begin to focus on per-application authorization evidence instead of VPN presence. That shift aligns better with zero trust thinking and with the reality of distributed engineering teams using shared operational platforms.

The governance win is not simply fewer VPNs. It is the ability to make access decisions visible, reviewable, and revocable at the point where the risk actually exists, which is the application itself.

For practitioners

• Define application-scoped access policies Map Grafana, Argo CD, GitLab, and Prometheus to distinct policies so access reflects job function rather than network membership.
• Require identity provider authentication Force all internal-tool access through SSO and identity claims so the proxy can make a consistent allow or deny decision.
• Separate read and write entitlements Distinguish dashboard viewing from deployment, pipeline modification, and administrative actions, especially for tools with operational side effects.
• Tighten third-party access revocation Review contractor and partner access paths so you can remove tool access without depending on broad VPN account retirement.
• Centralise request logging by identity Record the user identity, target tool, and policy outcome for every request so audits and incident reviews can trace real access decisions.

Key takeaways

• VPN access is too coarse for Kubernetes internal tools because it grants network reach without expressing application-level need.
• The main governance improvement comes from tying each request to identity, policy, and the specific tool being accessed.
• Teams that move this control point gain better revocation, better auditability, and a smaller blast radius for privileged internal systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.