Decide on a path for enabling GitHub auth to grafana for Community Reps of hubs on dedicated clusters

[sgibson91]

December 2023 Update

The default way to give access to communities is via invite links as documented at https://infrastructure.2i2c.org/sre-guide/support/grafana-account/.

Two follow-up issues were opened as a follow-up to this discussion on the path forward:

• Document Grafana access for communities docs#198

• [docs] Clarify infrastructure documentation around Grafana access #3505

October 2023 Update

We seem to have settled on an implementation method for this which is documented for engineers here: https://infrastructure.2i2c.org/howto/grafana-github-auth/ However, there's no Hub Champion-facing documentation stating that this is available.

---

Original Issue Content

Context

We have grafana dashboards that report a lot of metrics that not only make us feel confident that we have our infrastructure under control, but also give Comm. Reps. insight into the usage and costs of their infrastructure. For every dedicated cluster we deploy, we should make enabling access to these dashboards for the Comm. Reps. a default step in the setup process.

Currently, we provide access by enabling GitHub auth on the grafana login page. We only have this feature enabled on the LEAP and M2LiNES hubs right now. We restrict the GitHub OAuth App to only grant access to members of the 2i2c-org GitHub org and in the grafana config we set allow_sign_up: true. This approach has only worked so far because Ryan, as Comm Rep for these two hubs, is also a member of the 2i2c-org. We need to find a more generalisable path that we will work for all Comm Reps of dedicated clusters, regardless of status related to 2i2c.

Some other approaches have been suggested:

1. The Comm Rep creates a team in their org with those who are allowed to have access to the grafana dashboards, and we grant access to that team in the grafana auth config, in a similar way to how we grant access to the 2i2c org.
   • This might be a lot of overhead to setup
   • I think this path will be tested in the UWHackweeks issue Allow access to uwhackweeks grafana outside of 2i2c #1570
2. Grafana has an "Invite user" feature where we can invite the Comm Rep and give them the right to invite anyone else they see fit to the grafana dashboards
   • A little bit like how hub admins can add new users on hubs
   • I don't know how this invite method would work with GitHub auth though - would we need to send the invite to the same email the person has registered as their GitHub email?
   • ref: Enable GitHub auth for m2lines grafana #1830 (comment)
3. Longer-term solution: We use JupyterHub's internal authentication instead of GitHub. Anyone who is an admin on the hub gets access to the grafana dashboards
   • ref: Restructure infrastructure docs #1814 (comment)

Proposal

We should decide which of these paths we should take moving forward, scope the required technical work, and add it to the backlog.

Updates and actions

No response

[damianavila]

Longer-term solution: We use JupyterHub's internal authentication instead of GitHub. Anyone who is an admin on the hub gets access to the grafana dashboards

Sounds nice, but what happens if someone else from the community NOT interested to get access to the hub actually wants access to the dashboard? Should we decouple both actors?

[sgibson91]

but what happens if someone else from the community NOT interested to get access to the hub actually wants access to the dashboard? Should we decouple both actors?

I think we could make the same argument about GitHub auth tbh. What if someone in a finance department wants access to the grafana dashboards for reporting and doesn't have a GitHub account?

Having a service behind auth means someone needs some account somewhere. And I guess the only thing I can really see being a reasonable differentiator right now is comparing the amount of technical work/maintenance for us to provide that auth via the hub, or to provide it via one, or many, external services.

[damianavila]

I think we could make the same argument about GitHub auth tbh

Good point.

And I guess the only thing I can really see being a reasonable differentiator right now is comparing the amount of technical work/maintenance for us to provide that auth via the hub, or to provide it via one, or many, external services.

Another good one.

[consideRatio]

We have github auth enabled for all clusters now, but I wonder if its perhaps better if we could avoid doing it like this, and instead using a prod hub's JupyterHub as an identity provider to declare who has access --- anyone able to login to the hub.

[damianavila]

using a prod hub's JupyterHub as an identity provider to declare who has access --- anyone able to login to the hub.

Rethinking this one: sounds like a good idea since most (if not all) the community representatives are hubs users whereas it might not be GH users.

[sgibson91]

I think we have an implicit practice around this now to use GitHub auth. We have docs on how to enable this for engineers, but nothing (obvious to me) on docs.2i2c.org to advertise this to community champions

[GeorgianaElena]

@sgibson91, @jmunroe and I had a meeting about this and we concluded that the next steps are:

• Document Grafana access for communities docs#198
• [docs] Clarify infrastructure documentation around Grafana access #3505

Will update the top comment with the resolution and close this issue.