Restricting routes to local Grafana public dashboard
Am trying to sort through the Applications/Policies/Tokens needed to set it up so I can share a Grafana dashboard in a Pi (via a Tunnel/route) without sharing all of Grafana. Feels like I'm missing something obvious; normally I'd think I could just block based on URL, but that doesn't seem to be an option.
Anyone have experience with this?
43 Replies
The most specific application applies, which is the trick to use here. Make one self-hosted app on grafana.example.com/*, w/ an
Allow rule just for you, and then another self-hosted app like this:
then on the public self-hosted app, just need one Bypass action policy allowing
Everyone. Just make sure not to select Protect with Access on the tunnel public hostname, won't work w/ bypassHmm, will go back and try that. Thank you!
I ended up with a route to grafana.example.com/d/* and then set a service auth requirement for /login and that seems to have worked, but it’s inelegant. Was trying a route to /public-dashboards/* but Grafana kept throwing errors.
I ended up with a route to grafana.example.com/d/* and then set a service auth requirement for /login and that seems to have worked, but it’s inelegant. Was trying a route to /public-dashboards/* but Grafana kept throwing errors.
If you're using /d/ it sounds like you're trying to share the dashboard without using the public dashboards feature
in the grafana dashboard, top right, under Share -> Public Dashboard is how you can enable publicily viewable dashboards and get /public-dashboard/ links
https://grafana.com/docs/grafana/latest/dashboards/dashboard-public/
Grafana Labs
Public dashboards | Grafana documentation
Make your Grafana dashboards public and share them with anyone
I was having problems with using /public-dashboards. When I put that in and tried to set an allow policy for it I’d get a broken link. Definitely operator error. I’ll try your first suggestion when I get back to my desk. Thanks again!
The allow policy should be on the base wildcard
self-hosted app on grafana.example.com/*, w/ an Allow rule just for you,then you have a more precise self-hosted app w/ a bypass action allowing everyone, matching
public* public-dashboards* and api/public*Ah, because those dirs are what Grafana needs access to? (/public, /public-dashboards, and /api/public?
for public dashboards yea
Hmm, I'm not getting something.
Ok, 2 Applications.
First:
Second
If I set that up, when I go to the public dashboard link I get "Get a login code emailed to you"
If I enter that code, I get to see the dashboard, but I also see a "Failed to Fetch" message and there's the friction of mucking about with an email code.
Whereas if I just set up a route to
grafana.domain.com/d/* and then one Application for grafana.domain.com/login and use an Allow Policy tied to any Service Auth Token, I can share either the Public Dashboard link or the /d link, but people can't access anything else in Grafana.
***
Sorry, I think I solved it inelegantly about 24 hours after asking the question. 🙂The action on the second one should be
Bypass, shouldn't get any login at all if it's setup right.
Just protecting /login should prevent any login attempts since they just POST to /login but wouldn't protect Grafana's full api and such, eh, still exposing it to a degree anyway with public dashboards, just means you're trusting exposing their non-public api a bit moreOk, tried it again with
Bypass (which I'd missed before) and that worked well, thanks!
I think the other key aspect for me was setting the Route to go to grafana.domain.com/d*, so there's no way to get to grafana.domain.com
Am I missing something important there?hmm, what do you mean by setting the route to that?
Essentially what you're doing is:
Bypass:
/public*, /public-dashboards*, /api/public*
Redirect to auth, Allow: grafana.domain.com/*
/d*, wouldn't match any of the bypass ones, so it'd match the less specific general wildcard which requires authLet me double check, maybe I did something wrong. When I set the Route to
grafana.domain.com/* before I'm pretty sure anyone could just go there and see the Grafana basic (pre-login) page.hmmm, I'd make sure you're testing that from incognito mode/another browser too, you might be already logged in
http://grafana.gristleking.dev/public-dashboards/de67142e871c4d2da807ee1086979b20
Word. Been testing in Incognito.
I can't get the set up you've recommended to work the way I want it to. It's got to be operator error on my side, but I'm not sure what it is I'm doing wrong.
So you should be able to see the dashboard but not access
grafana.gristleking.dev or anything other than that public dash link
OR
you could paste in the de6... after gristleking.dev/d/ and you'll see an error page in Grafana but as far as I can tell you can't do anything with it.
It's currently set up with the Route pointing to grafana.domain.com/d* and then just one rule set to allow access to grafana.domain.com/login to a Service Auth token.
That appears to be working, but I think you'd said that exposes more than I should?hmm, the way you word that is interesting, what do you mean "Route"? None of the access app's terminology is route
I'm pretty new to this, so may be using the wrong term then. I mean the public hostname in the Tunnel; I thought that was a "Route".
hmm, those are public hostnames. You'd just have something a wildcard for the specific subdomain, like this for example
Ok, I was using the wrong term then.
That's what I have set up.
hmm, you have another public hostname (what you call Routes) on that tunnel for this subdomain?
Yes, for Node-RED.
that's different subdomain though, right?
Yes.
Remove the path on that public hostname (route), it's not doing anything other then making some things fail, should just show as
(optional) path once you remove it fullyKk.
what are the access apps you have currently? just one for
/login?Yep. 2 for the Node-RED part, but just the one for Grafana.
and that Grafana one just uses a
Service Auth.and so if you took the current one, and modified it to be
* for path, and then made another self hosted app w/ https://discord.com/channels/595317990191398933/1330066393764331580/1330291419751125063 and a single Bypass Everyone policy, and give it a second to propagateAh, I was testing immediately, which seemed to work for everything. Maybe I just need to wait an extra few seconds?
yea it can take a bit, maybe ~60s or so? Plus I believe there's some browser caching on the access redirects
Ha! Working now!
I was just too impatient before.
Thank you!
Access is powered by Workers KV, so some understandable propagation/cache delay
Got it. Ok, this is awesome, thanks again!
(part of a tutorial I'm writing, so this helps lots of other people get this right the first time). 🙂
The action types are the most confusing aspect to people I think
Allow = Always go through Identity Provider. Even if you set it to include:
Everyone, they still need to go through something providing them an identity to proceed
Bypass = Bypass all Zero Trust stuff, go back to zone/website level security (waf, etc)
Service Auth = Go through Zero Trust w/ no identity
If you enable "Protect with Access" on the tunnel, only Allow and Service Auth provide the JWT/magic stuff for it to work. If you enable "Protect with Access" and have a bypass rule, they'll just be blocked by the tunnelYeah, it definitely confused me!
Ok to put ya in there?
Sure
https://www.meteoscientific.com/docs/tutorial-extras/metsci-demo-dash
Thanks again!
Not totally relevant to this, but doesn't
Service Auth require that you have an identity in the form of a Service Auth token?I more meant no identity provider login, but you can have Service Auth rule including Everyone