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
908 stars 396 forks source link

Feature - Support X-Grafana-Org-Id Header #1726

Open alefray opened 1 week ago

alefray commented 1 week ago

Is your feature request related to a problem? Please describe.

On our self-hosted Grafana Enterprise instance, we use Organisations to isolate our clients dashboards and Teams to structure internal teams permissions (viewer/editor) and client teams permissions (mostly viewer).

We want to be able to specify for each dashboard and/or datasource the organisation id where to provision them on our Grafana instance.

Note: we use grafana-operator with external grafana configuration (grafana is provisioned using the helm chart, not the operator)

Describe the solution you'd like

Allow to pass the X-Grafana-Org-Id header when the operator requests Grafana HTTP API for any resource type e.g. folder, dashboards or datasources.

This could be done in multiple ways:

With the first 2 solutions, we would declare multiple Grafana instances with different X-Grafana-Org-Id values and rely on InstanceSelector in GrafanaDashboard spec to select the correct instance/orgid url. With the latest, we would have a single Grafana resource and rely on the new orgId parameter in GrafanaDashboard spec to select the correct organisation.

Describe alternatives you've considered

We plan to build a solution using a proxy to set the header attribute depending on the url e.g. curl -X GET grafana.org-1.example.com/api = curl -X GET -H "X-Grafana-Org-Id: 1" grafana.example.com But this feels a bit hackish, a proper build-in solution would be much more simpler.

Additional context

We are aware that Organisations are not a feature Grafana plans to invest in according to https://grafana.com/blog/2022/03/14/how-to-best-organize-your-teams-and-resources-in-grafana/.

However, we pay a licence which allow us to propose a single instance for our team and our client instead of the cumbersome management of multiple instances (that we already have experienced and don't want to go back to).

We do use organisations for the very reasons detailed as limitations here:

theSuess commented 4 days ago

Thanks for the feature request! As you mentioned, organizations are not something we're likely to support directly based off the complexity they introduce and edge cases that need to be considered.

That being said, adding a generic header field to the client is something we can add, as it's also useful for some other configurations.

If you're up to implementing this, we're happy to merge a PR with a generic header field. Otherwise, you'll have to wait some time for us to implement this

MaoMaoCake commented 1 day ago

I've started some work on my fork today but I'm not a golang dev I can't seem to figure out why this is not working. I'll update if I get it to work or some kind soul can help me figure it out.

https://github.com/MaoMaoCake/grafana-operator/commit/747a96014c1c891ec9864e68a3c0674aebdc7b97

MaoMaoCake commented 1 day ago

After some more digging around the client has OrgID already built in, it is just a matter of adding a configuration for in the external client, while it would not be a generic header implementation, it would satisfy the current feature request.

please check out the implementation here https://github.com/MaoMaoCake/grafana-operator/tree/add-x-grafana-orgid. If you are open to merging it I'll open a PR.