Notifications
Clear all
Topic starter
10/06/2026 11:42 pm
TL;DR: Identity-aware access for Grafana, Argo CD, GitLab, and Prometheus replaces network-level VPN trust with per-application policy, identity claims, and audit logs, according to Pomerium. That shift reduces broad access and makes revocation, visibility, and compliance much easier for platform and IAM teams.
NHIMG editorial — based on content published by Pomerium: Secure internal access to Grafana, Argo, GitLab, and Prometheus without a VPN
Questions worth separating out
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.
Q: Why do VPNs create weak least-privilege controls for internal apps?
A: Because VPNs usually grant broad connectivity instead of application-specific permissions.
Q: What breaks when contractor access to internal tools is handled through VPNs?
A: Offboarding and scoping become too coarse.
Practitioner guidance
- 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.
- 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.
- Tie every access decision to identity metadata Require request-level logging that records the identity, policy outcome, and target service.
What's in the full article
Pomerium's full blog post covers the implementation detail this post intentionally leaves for the source:
- Step-by-step access proxy flow for internal Kubernetes tools such as Grafana, Argo CD, GitLab, and Prometheus
- Example policy structure for identity- and group-based access decisions across internal applications
- Operational guidance on reducing VPN dependence while preserving auditability and revocation
- Practical deployment considerations for platform teams moving from network trust to identity-aware access
👉 Read Pomerium's analysis of secure access to Grafana, Argo CD, GitLab, and Prometheus →
Kubernetes internal tools without VPNs: what changes for IAM teams?
Explore further
12/06/2026 6:00 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity-aware access for Kubernetes tools is replacing VPN trust
