Hi everyone. I've noticed several members asking about securing internal dashboards, specifically Grafana, without the overhead of running a separate auth proxy or modifying the application itself. If that's you, this guide is for your use case.
The core idea is to use Cloudflare Access as a wrapper around your Grafana instance. Grafana's own login remains disabled, and Access becomes the sole gatekeeper. This shifts authentication to your identity provider (like Google, GitHub, or Okta) and authorization to Access policies.
Here’s a typical workflow:
1. You deploy Grafana internally (e.g., on a private network, a VM, or a container) and disable its built-in login in the configuration.
2. You create a Cloudflare Tunnel from that instance to Cloudflare's edge, making it reachable without opening any inbound firewall ports.
3. In your Cloudflare Zero Trust dashboard, you create an Access application for the subdomain you'll use (e.g., `grafana.yourdomain.com`). You then define policies, such as allowing only users from your company email domain or specific GitHub teams.
When a user visits your Grafana URL, they hit the Access login page, authenticate with your chosen IdP, and—if permitted—are passed through to the dashboard seamlessly. All requests are logged in your Zero Trust audit trail.
The main pitfall to avoid is ensuring Grafana itself isn't also exposed publicly or via another route. The Tunnel should be the only path in. Also, remember that this secures *access to* Grafana, not actions within it. For multi-user dashboards, you'd still need Grafana's internal user/org roles if different permission levels are required inside the app.
This pattern has been a game-changer for many teams I've spoken to, simplifying security for a wide range of internal tools. Has anyone else set this up? I'm curious about your experiences with specific IdPs or if you've encountered any quirks with the Grafana configuration.
~L
Be kind, stay curious.
This approach works well for internal teams, but one caveat on the analytics side. Since Grafana's own auth is disabled, all user activity in its logs will show as a single service account (from the Tunnel) or the generic 'admin' user. You lose individual user attribution within Grafana's audit trail.
For us, that meant we had to rely solely on Cloudflare Access logs for user-level dashboard access reporting. It's doable, but you need to stitch two data sources together if you need to connect a specific user to their queries or dashboard edits.
You skipped the most critical cost angle here. Using Cloudflare Access for this shifts a recurring operational cost (maintaining an auth proxy) to a direct SaaS expense based on monthly active users.
If you have 50 engineers accessing it, that's fine. But if you're securing a dashboard for 500 contractors or partners, you're looking at a real monthly bill that often gets overlooked during the "just use Access" decision. That monthly active user count can creep up.
Also, don't forget you're now locked into their pricing model for the lifetime of the dashboard. You lose the option to scale down the auth costs independently of your infra.
Your cloud bill is 30% too high