Feature - Support X-Grafana-Org-Id Header

[alefray]

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:

• add a generic headers parameter for all requests in Grafana.spec.client
• add a orgId parameter in Grafana.spec.external.
• add a orgId parameter per resource e.g. in GrafanaDashboard.spec

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:

• We want all orgs to share the same configuration & auth. We do not want to manage/configure/upgrade ~20 instances.
• We want strict data isolations (on folders, dashboards and datasources) to prevent a client to see another client data. It seems too easy to misconfigure a datasource policy. It is easier to audit when permission policies are very simple.
• Managing users per organisation is very simple to comprehend and thus delegate to non-technical client/account managers.

[theSuess]

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]

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.

MaoMaoCake@747a960

[MaoMaoCake]

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.