Add additional authentication methods

[cjohnston1158]

Enhancement Proposal

The current grafana charm supports additional authentication methods, which is a requirement for some customers (i.e. ldap). This should be added to the new charms.

[sed-i]

Hi @cjohnston1158,

• Would this satisfy your requirements?
• Would it be possible for you to use OIDC or oauth instead?

[cjohnston1158]

Yes, that would satisfy it. TBH the charm should support all supported Auth mechanisms.

[simskij]

Alright, we'll start with OIDC in that case. This means you'll have to set up an integrator somewhere to go from LDAP to OIDC, but it also means we gain better compatibility with the rest of the charms developed internally.

We're not looking to add all possible auth mechanisms just because they're available, but will go back and reevaluate as the need for a certain one arises.

[cjohnston1158]

Another, and possibly better alternative would be for ingress to handle auth.

[rbarry82]

Ingress does not handle auth outside of being able to forward to some external service for IdM if there's no auth headers. No implementation of basic auth or other will be added to Traefik. Ingress is more or less a reverse proxy, and isn't suitable for handling auth (at least from a scope point of view)

OIDC is the de-facto implementation (though the grafana_auth library is abstracted enough that we could theoretically support any auth backend) because there are many, many full-scope OIDC proxies which know how to talk to/forward to various LDAP/OAuth/SAML/whatever backends rather than having Grafana (and any other service) re-invent the wheel over and over again.

Currently, we only have support for auth proxy, but OIDC is easy enough to add. Not to put too fine a point on it, but there's an entire charming team working on ORY/Hydra which may provide "better" solutions for LDAP backends (forwarded, again, through OIDC or other), and there are charms for Dex and Gatekeeper (neither of which seems to handle LDAP at present, admittedly).

The skeleton to implement LDAP is present in grafana_auth, but validating that any given config actually works (bind_dn, filters, search_dn(s), whether or not to use LDAPS, etc) is a massive scope for the Grafana charm which is better suited for some OIDC proxy.

What options do you currently have available?

[cjohnston1158]

Currently only LDAP. The reason I mentioned doing it in ingress is because the ceph dashboard requires grafana to have anonymous viewing. Obviously we can’t require users to login via LDAP and have anonymous = True to satisfy both requirements.

[rbarry82]

Let's go back to the beginning. Can you explain your use case?

Ceph does not require Grafana to have anonymous viewing. The Grafana bundled with Ceph (which is not this charm in any case) is configured with anonymous access by default, but it's equally possible to have the Prometheus Operator (charm) scrape the Ceph endpoints and just use the Ceph dashboards there without anonymous auth in the ceph-bundled Grafana. Or to just edit the grafana.ini for that bundled one and disable anonymous auth.

Following that, ingress does not "do" LDAP. We use Traefik. LDAP is only in Traefik Enterprise anyway (there's a community middleware for other LDAP sources), but it's the same mess there. For Traefik (with a 3rd party middleware or otherwise) to configure LDAP, all of the same questions as Grafana LDAP (bind_dn, search_dn(s), filters, LDAPS, whether or not to validate certs, etc) would need to be added there, validated, and so on, and there's a whole mess of complication there if the "LDAP" is actually AD or something with completely different DNs or which needs an LDIF applied.

That kind of "validate that the LDAP config works from Python code in a charm, or write a broken configuration" is way above and beyond what any charm which isn't explicitly about auth should be doing.

For ingress to "handle" LDAP, forwarding requests without an auth header to somewhere else (gatekeeper, dex, authelia, authentik, keycloak, you name it) is best practice, and a ForwardAuth middleware gets added to all routes which need authentication, where an appropriate application handles it. That's the scope of another team/project, and it's not ready yet.

So I'm wondering what workarounds are available for you. Currently only LDAP... ok. What's the LDAP backend? Is Keystone available (and talking to LDAP)? We're happy to help with a workaround/stepping-stone until ORY/Hydra charms are ready, but not to do a from-scratch LDAP auth for Grafana/Traefik which will be (correctly) thrown away later.

Additionally, you can have users log in via whatever mechanism you want and have anonymous = True for some dashboards, as long as they're in a different org. At present, the Grafana charm isn't doing multi-org, but that's frankly a more achievable ask (provision some dashboards into a different org with viewer rights only -- we already have predictable dashboard URIs -- and find another mechanism for 'other' auth).

But it's not clear to me whether you're using the Grafana charm at all. It sounds like the Ceph-deployed Grafana, and the "right way" in that case is to connect Ceph to an external Prometheus, which is connected to the Grafana charm, and shuttle the dashboards into this charm over a relation. From there, auth can be via whatever mechanism (auth proxy is already done, or we can do OIDC via keystone in the roadmap).

[simskij]

@mthaddon expresses similar requirements in issue #139.