Secure Internal Access to Grafana, Argo, GitLab, and Prometheus Without a VPN

A Better Default for Modern Platforms

Securing internal tools without a VPN is no longer a fringe idea—it’s becoming the default for modern Kubernetes platforms.

Identity-aware access aligns with Zero Trust principles and reflects how teams actually work today: distributed, dynamic, and identity-driven.

For platform teams, the result is fewer moving parts and clearer architecture. For security teams, it’s stronger control with better visibility. And for engineers, it’s a smoother, more reliable experience.

A Simpler Approach to Securing Kubernetes

For many Kubernetes teams, tools like Grafana, Argo CD, GitLab, and Prometheus are the operational backbone of the platform. They expose powerful capabilities: deploying workloads, viewing metrics, modifying pipelines, and accessing sensitive configuration. Yet despite their importance, these tools are often protected by some of the weakest access controls in the environment.

Historically, the default approach has been to hide these services behind a VPN. If you can reach the network, you can reach the tool. In practice, this model creates more problems than it solves—especially as teams scale, distribute, and rely on external contributors.

A growing number of platform teams are moving away from VPNs entirely and adopting identity-aware access for internal Kubernetes tools. The result is a simpler, more secure, and more auditable access model.

Why VPNs Break Down for Internal Tools

VPNs were designed to extend a private network to remote users. They were not designed to provide fine-grained, identity-driven access to individual applications.

In Kubernetes environments, VPN-based access creates several challenges:

Overly broad access

Once connected, users often have access to far more than they need. Network-level trust makes least-privilege enforcement difficult.

Operational friction

VPN clients, configuration issues, and connectivity problems slow down engineers and create constant support burden.

Poor auditability

VPN logs tell you that someone connected to the network—not which tools they accessed or what actions they took.

Contractor and third-party risk

External users require VPN access that is difficult to scope and revoke cleanly.

For tools as powerful as Grafana, Argo CD, GitLab, and Prometheus, these weaknesses are unacceptable.

The Case for Identity-Aware Access

Identity-aware access flips the model. Instead of granting access based on network reachability, it enforces access based on verified identity and explicit policy.

With an identity-aware access proxy like Pomerium:

• Users authenticate via your existing identity provider

• Access is granted per application, not per network

• Policies reference groups, roles, and context

• Every request is logged with identity metadata

This allows teams to expose internal tools securely without exposing the underlying network.

Common Internal Tools and Their Access Challenges

Grafana and Prometheus

Grafana dashboards often expose sensitive operational data, while Prometheus endpoints can reveal internal metrics and labels.

Challenges:

• Shared dashboards

• Inconsistent auth configurations

• Read vs. write access ambiguity

Identity-aware access allows you to:

• Restrict dashboards by group

• Require SSO for all access

• Centralize audit logs

Argo CD

Argo CD can deploy and modify production workloads. Treating it like “just another internal app” is risky.

Challenges:

• High privilege actions

• Role complexity

• GitOps access paths

Placing Argo CD behind identity-aware access ensures:

• Only authorized identities can reach the UI or API

• Access can be revoked instantly

• No reliance on network trust

GitLab

GitLab often sits at the intersection of code, CI/CD, and secrets.

Challenges:

• Multiple authentication layers

• External contributors

• Broad access requirements

Using identity-aware access:

• Standardizes authentication

• Applies consistent policies

• Reduces configuration sprawl

How the Architecture Works

A typical identity-aware access architecture looks like this:

1. User requests access to an internal tool (e.g., Grafana)

2. Traffic is routed through an identity-aware proxy

3. User authenticates via SSO

4. Policy is evaluated using identity claims

5. Authorized traffic reaches the service

6. Audit logs record the decision

The application itself remains unaware of the authentication flow.

Example Policy Configuration

A simple Pomerium policy might look like:

This expresses intent clearly and avoids embedding auth logic inside each tool.

Eliminating the VPN

Once identity-aware access is in place, many teams find that VPNs are no longer necessary for internal tools.

Benefits include:

• Reduced attack surface

• Faster onboarding and offboarding

• Fewer support tickets

• Improved developer experience
  

VPNs may still be useful for certain network-level access, but they are no longer the default gate for application access.

Security and Compliance Benefits

Security teams gain:

• Centralized policy enforcement

• Clear audit trails

• Stronger access revocation

• Reduced lateral movement risk
  

Compliance becomes easier because access decisions are explicit, logged, and tied to identity.