Identity-aware access for Kubernetes tools is replacing VPN trust

At a glance

What this is: This is a vendor analysis of replacing VPN-based access to internal Kubernetes tools with identity-aware access, with the key finding that application-level policy improves control and auditability.

Why it matters: It matters because platform teams, IAM leads, and security architects need a cleaner way to govern privileged internal tools without turning network reachability into implicit trust.

👉 Read Pomerium's analysis of secure access to Grafana, Argo CD, GitLab, and Prometheus

Context

VPN-based access for internal tools is a network control, not an identity control, and that mismatch becomes obvious in Kubernetes environments where Grafana, Argo CD, GitLab, and Prometheus carry high operational privilege. When the network becomes the gate, least privilege is coarse, audit trails are weak, and offboarding is slower than the access it is meant to remove.

Identity-aware access changes the control point from network reachability to verified identity and explicit policy. For IAM and NHI programmes, that means the same access model can be applied more cleanly to users, contractors, service access patterns, and future machine-driven workflows, with clearer logging and revocation boundaries.

Key questions

Q: How should security teams govern internal Kubernetes tools without a VPN?

A: Use identity-aware access at the application layer, not network-level trust. Grant access by identity, group, role, and context so each internal tool has its own policy boundary. That gives platform teams tighter scoping, better revocation, and audit records that show which service was accessed rather than only that a network connection existed.

Q: Why do VPNs create weak least-privilege controls for internal apps?

A: Because VPNs usually grant broad connectivity instead of application-specific permissions. Once a user connects, the network layer often cannot distinguish between low-risk browsing and high-risk administrative actions. That makes least privilege hard to enforce and easier to bypass through inherited network reach.

Q: What breaks when contractor access to internal tools is handled through VPNs?

A: Offboarding and scoping become too coarse. External users often receive the same network path as employees, which makes it difficult to limit access to only the tools they need and hard to revoke cleanly when the engagement ends. That creates unnecessary exposure across operational platforms.

Q: How do teams know if identity-aware access is actually improving security?

A: Look for narrower access scopes, clearer revocation, and request logs that identify the user, policy decision, and specific application. If teams can answer who accessed which tool and why, and can remove access without touching the broader network, the control is doing real work.

Technical breakdown

Why VPN trust breaks down for Kubernetes tools

A VPN extends a network, but it does not express which application, action, or role is being used. In Kubernetes environments, that creates a broad trust zone where a user who can connect can often reach multiple internal tools, including systems that expose deployment controls, configuration data, and operational telemetry. The weakness is architectural: the control is location-based, while the risk is application-specific. This becomes especially problematic when contractor access, shared environments, and fast-changing platform roles need tight scoping. The result is not just larger access, but weaker accountability for what happened after connection.

Practical implication: move privileged internal tools out of network-level trust and into application-specific access policy.

How identity-aware access proxies enforce per-application control

An identity-aware proxy sits in front of the application and evaluates each request against identity claims, group membership, and contextual policy. Instead of trusting the network path, it checks who the user is and whether that identity should reach a specific service at that moment. The application can remain unchanged because the proxy handles authentication and authorisation outside the app. This model is useful for internal tools because it preserves user experience while making access decisions visible and auditable. It also creates a better separation between application function and access governance, which matters in platform environments where many tools are operationally sensitive.

Practical implication: centralise identity and policy at the access layer rather than embedding auth logic in each tool.

Why auditability improves when access is tied to identity

VPN logs typically show network connection, not meaningful application use. Identity-aware access creates a request-level record that links access decisions to user identity, policy outcome, and target application. That matters because audit and incident response depend on reconstructing who accessed what, not just who connected to the perimeter. It also improves revocation and offboarding because access is expressed as policy against identity attributes rather than as a lingering network entitlement. In practice, this narrows lateral movement opportunities and gives security teams a cleaner record for reviews, investigations, and compliance evidence.

Practical implication: use identity-linked logs as the audit source of record for internal administrative tools.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

VPN replacement is really an identity governance problem, not a network modernisation exercise. The vendor’s point about internal tools is accurate, but the deeper issue is that network trust cannot express least privilege at the application level. For IAM teams, the real shift is from perimeter access to identity-scoped access decisions, which is the boundary that matters for privileged platform tooling. That makes the programme change one of governance design, not just infrastructure preference.

Application-level access control is the right baseline for high-value internal tools. Grafana, Argo CD, GitLab, and Prometheus are not generic internal apps because they expose telemetry, pipelines, and deployment control. A network gate treats them as equivalent to low-risk services, which collapses the distinction between reachability and authority. The practitioner conclusion is simple: if the tool can change production state or reveal sensitive operational data, the access model must be explicit enough to reflect that.

Named concept: identity perimeter collapse. The old assumption was that a private network boundary could stand in for trust decisions across internal applications. That assumption fails once teams are distributed, contractors are common, and platform tools carry privileged actions that need per-request governance. The implication is that security architecture has to stop equating internal location with low risk, especially where identity, role, and context are the real control variables.

Contractor and third-party access exposes the weakest part of VPN-based governance. The article correctly highlights that external users are difficult to scope and revoke cleanly once network access is the primary control. That is a governance failure mode, not just an operational nuisance, because it blurs offboarding, auditability, and accountability. Practitioners should treat third-party access to internal tools as a lifecycle problem with explicit identity boundaries, not as a connectivity exception.

Identity-aware access aligns internal tool governance with Zero Trust principles. The shift matters across human IAM and NHI programmes because the same idea applies whenever access should be granted to a specific identity for a specific purpose. Pomerium’s example is about people today, but the pattern is relevant to machine and agent access models as well. The field is moving toward explicit, application-scoped trust, and teams that still rely on network reachability are already behind the operating model.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how limited many identity programmes remain once non-human access is in scope.
• That visibility gap is why 52 NHI Breaches Analysis is a useful next resource for seeing how weak identity boundaries turn into real incidents.

What this signals

Identity-aware access is becoming the default pattern for platform teams that need to retire VPN trust without losing control. The next governance question is not whether internal tools stay accessible, but whether access is expressed in a way that can survive distributed work, third-party use, and higher privilege application paths. Teams that keep network reachability as the primary gate will continue to accumulate audit debt.

Identity perimeter collapse: once internal applications are treated as if network location were a trust signal, the organisation loses the ability to distinguish harmless connectivity from privileged authority. That matters for human users today and becomes even more relevant as NHI and agent-driven workflows start to touch the same platform surfaces.

The practical signal to watch is whether access reviews and offboarding can be performed at the application level without touching the underlying network. If not, the programme still depends on a perimeter model that is too blunt for modern platform governance.

For practitioners

• Replace network trust with application-scoped policy Put Grafana, Argo CD, GitLab, and Prometheus behind identity-aware controls so access is decided per application, not by VPN reachability. Start with the tools that can modify production state or expose sensitive telemetry.
• Separate read-only and privileged access paths Treat dashboards, deployment consoles, and APIs as different access tiers, even when they sit in the same platform. This makes role design clearer and prevents one network grant from covering unrelated functions.
• Tie every access decision to identity metadata Require request-level logging that records the identity, policy outcome, and target service. That gives IAM and security teams a usable trail for investigations, reviews, and offboarding.
• Review third-party access as a lifecycle control Scope contractor access by identity attributes and revoke it through the same offboarding process used for other privileged access. Do not leave external users dependent on long-lived VPN entitlement for internal tools.

Key takeaways

• VPNs are a network control, but internal Kubernetes tools need identity controls that can express application-specific privilege.
• Auditability improves when access decisions are tied to identity metadata and specific services, not just a network connection.
• Platform teams should treat contractor access, offboarding, and revocation as lifecycle controls, not connectivity exceptions.

Key terms

• Identity-aware access: An access model that authorises each request using identity, role, and context rather than network location. It shifts the control point from the perimeter to the application boundary, which is essential when internal tools carry privileged functions or expose sensitive operational data.
• Application-scoped policy: A policy model that grants access to a specific service or function instead of to an entire network segment. It reduces over-broad access and makes revocation more precise, especially in environments where internal tools are operationally sensitive and widely distributed.
• Identity perimeter collapse: The failure of a network boundary to serve as a meaningful trust boundary for modern access decisions. When internal tools are reachable through broad connectivity, the organisation loses the ability to distinguish routine access from privileged use, and governance becomes too coarse to enforce least privilege.
• Audit trail linkage: The ability to connect an access decision to a specific identity, application, and policy outcome. It gives investigators and reviewers evidence that is stronger than network logs alone, because it shows who accessed what and under which rule.

Deepen your knowledge

Identity-aware access for internal tools is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your platform team is moving away from VPN trust, this is a relevant place to build the governance baseline.

This post draws on content published by Pomerium: Secure internal access to Grafana, Argo, GitLab, and Prometheus without a VPN. Read the original.