search

grafana / grafana-operator

An operator for Grafana that installs and manages Grafana instances, Dashboards and Datasources through Kubernetes/OpenShift CRs
https://grafana.github.io/grafana-operator/
Apache License 2.0
913 stars 397 forks source link

Set dashboards permissions through GrafanaDashboard CRD #451

Open DeanBrunt opened 3 years ago

DeanBrunt commented 3 years ago

Is your feature request related to a problem? Please describe. Currently, I don't believe it's possible to set dashboard permissions using the GrafanaDashboard CRD. This would be a welcome enhancement for cases where users wish to provision dashboards with more granular permissions without having to set these up manually.

Describe the solution you'd like An addition to the GrafanaDashboard CRD that allows users to set permissions for a given team, role or user on the GrafanaDashboard.

Describe alternatives you've considered Manual permissions setup. It's a fine workaround but doesn't marry well with the model the operator strives for.

Additional context HTTP API does exist for managing this: https://grafana.com/docs/grafana/latest/http_api/dashboard_permissions/

NissesSenap commented 3 years ago

Would love to see this feature, there have also been talk about it on slack so I think other people would like it as well.

I do think we first need to start to support users & teams https://grafana.com/docs/grafana/latest/http_api/team/ and from there we can add this feature. Does that make sense?

DeanBrunt commented 3 years ago

I do think we first need to start to support users & teams https://grafana.com/docs/grafana/latest/http_api/team/ and from there we can add this feature. Does that make sense?

I'm somewhat torn on this as it then gets complicated with some of the SSO models. I think you can get some good value by just implementing the dashboard permission modelling first (granted, yes, you have to effectively hardcode the users and teams) and leave manual/SSO sync for actual user and team provisioning. At least this way, if you need to roll out a new Grafana, you can hook up your SSO/LDAP/whatever and don't need to worry about provisioning dashboard perms.

pb82 commented 3 years ago

@DeanBrunt are the permissions necessarily tied to teams/organizations or can they work with only users? Also, do you know what the exact difference between organizations and users is?

DeanBrunt commented 3 years ago

@DeanBrunt are the permissions necessarily tied to teams/organizations or can they work with only users? Also, do you know what the exact difference between organizations and users is?

Permissions can be assigned to either roles (e.g: for 1 dashboard, a "Viewer" could have Edit access 🤯 ), teams or individual users.

In terms of organizations vs teams, I couldn't tell you the exact purpose of each, but I believe that teams exist within organizations.

NissesSenap commented 3 years ago

So i have read up on grafana rbac https://grafana.com/docs/grafana/latest/manage-users/

In short a user exist in grafana. That user can be a part of one or multiple organizations.

In a organization you can also have teams. A user can be part of one or multiple teams. You can assign access to teams.

A dashboard and a datasource exist within a organization.

In the operator when we create anything we just assume it's in organization Id 1, aka the default org.

Without creating any issues for us now or in the future i think we can implement access to specific dashboards by adding the feature to the grafan dashboard controller.

If we start support multiple organizations or teams in the future we shouldn't need to change much in this crd or even any.

We can even start to support setting team access on the dashboards if people add teams manually to there grafana insurances.

One of the painful things we need to solve is how to inform the users of the crd if the access is added to a user that actually exist. I think we can do this using the status field in the dashboard crd. Or we can just be lazy and say it's up to the user to provide the correct user uid and if you don't nothing will happen and they need to read about it in the operator logs. But that doesn't sound so user friendly.

Does this sound reasonable?

pb82 commented 3 years ago

@DeanBrunt this would require rewriting some of the dashboard management logic: you can't set the organization directly when creating / updating a dashboard. Instead you have to use a separate API to assign an organization to a dashboard. Additionally this API requires you to ontain and use the org's token. More details can be found here: https://grafana.com/docs/grafana/latest/http_api/dashboard/#create--update-dashboard

pb82 commented 3 years ago

Our suggestion would be to close this issue in favor of a number of specific ones to address the rewrite of the account management. @DeanBrunt would you be available to join a triage call to discuss this further? We have a weekly one on Tuesdays at 1:30 CEST, but I'm also happy to find a time that works better for you.

DeanBrunt commented 3 years ago

Our suggestion would be to close this issue in favor of a number of specific ones to address the rewrite of the account management. @DeanBrunt would you be available to join a triage call to discuss this further? We have a weekly one on Tuesdays at 1:30 CEST, but I'm also happy to find a time that works better for you.

Yep that works for me. Just let me know the details of how to join etc

pb82 commented 3 years ago

@DeanBrunt would you still benefit from allowing to specify user and team IDs? The concern is that we make it user specific and later discover that supporting teams scales better.

NissesSenap commented 1 year ago

This is very similar to other org config stuff. For this issue to move forward, we would need a design document first. From there, an implementation could possibly happen.