Provide authentication support for general Oauth *or* Anonymous access

[mthaddon]

Enhancement Proposal

In some cases we'd like to be able to enable anonymous read-only access to grafana in K8s, similar to how we currently can do with the machine version of the grafana charm.

Typically we'd put a proxy in front of this with SSO authentication tied to a particular team, but taking this approach means that we don't have to create specific users (and share/manage those credentials) for those who just want to browse existing graphs. That SSO proxy would happen outside of this charm, fwiw.

[rbarry82]

There is an existing grafana_auth library, which is destructured enough that adding another method (such as anonymous auth) would be easy to add.

Note, however, that globally allowing anonymous auth in the charm was considered and rejected, whether or not the reactive charm does it (there are many things the reactive charm does which we do not intend to support without a "proper" design, rather than just putting them into the charm). We're happy to add support here, but would expect that, in a case where anonymous auth is needed, that an application which 'needs' it would need to provide those options via a relation.

[mthaddon]

Ok, so to clarify here a bit, we don't actually need anonymous access, but we do need some kind of authentication scheme that works for an organisation that doesn't involve manually creating/managing users and passwords. Possibly https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-authentication/google/ is the way to go here.

Possibly this issue isn't the best place to discuss this - let me know if it's better to close this out and discuss via other means.

[rbarry82]

Actually, we were discussion adding generic OAuth to the grafana_auth library for the OSM team (to bridge to Keystone) for the same reason. The library is explicitly written to make extending it with the rest of the provider suite as easy as possible.

Are you sure Google is what you're looking for, or are there others also?

[mthaddon]

I'm not tied to anything specific here if there's a better way of ensuring we can authenticate users. As I say, the main goal is to avoid needing to create user accounts/passwords manually.

[rbarry82]

I guess let me rephrase -- OSM has a need for generic oauth, so we're definitely doing that, but we can implement other mechanisms also. AFAIK, there isn't a google-auth-integrator charm or anything, and providing "raw" configs to the library from the commandline wouldn't be that nice. We'd need that to tie into the ecosystem in a good way.

We're able to provide a better way of authenticating users, but do you have any more specific requirements than that?

[simskij]

I'll close this one with reference to #167 , to make it easier to track.