Manage Grafana Service Accounts from the Grafana CR

[ndk]

UPD: I see there's ongoing work in the main branch to move away from Chainsaw-based tests and to revamp the Grafana reconciliation cycle. Because these updates look quite significant, I'll wait until they've been merged and then revise my code accordingly. This will ensure that my changes align smoothly with the updated infrastructure.

---

#1469

See full de# proposal #003.

---

Summary

This PR adds declarative management of Grafana Service Accounts directly in the Grafana Custom Resource.
It removes the need to provision SAs and API tokens manually and lets the operator keep them in sync.

What's in this PR

• Adds spec.grafanaServiceAccounts to the Grafana CR.
• Reconcile stage provisions/updates service accounts and their API tokens.
• Tokens are stored as Secret objects owned by the parent Grafana.
• E2E tests (tests/e2e/grafanaserviceaccount) cover create / rename / role change / disable / delete.

Still to do

• Unit tests.
• Additional tests to verify partial‑progress handling. Status should capture successfully created accounts/tokens/secrets even when later steps fail.
• Automatic token rotation via the expires field.
• User docs and example manifests.
• permissions: subsection for fine-grained access control.
• Need to merge #115 in grafana-openapi-client-go to be able to enable disabled service accounts.

Open questions

1. Separate CRD vs. embedded spec
   Proposal embeds service-account config in the Grafana CR, but I have a working PoC of a standalone GrafanaServiceAccount CRD on a side branch (needs a quick rebase).
2. Same-namespace assumption
   The current reconciler creates/updates service accounts only in the namespace that hosts the parent Grafana.
3. Secret location & scope
   Tokens are written as Secrets in the same namespace. No support for cross-namespace references today. Any objection to keeping it that way?
4. Permissions sub-spec
   The proposal sketches a permissions: section, and I already have code for it on another branch. Validation is blocked because the required Grafana API endpoints are Enterprise/Cloud-only. So, it's not included to this PR.
5. Placement of the SA reconciler
   It currently runs in a new stage between deployment and complete. That stage can error a couple of times while Grafana is starting, and if it wedges we never reach complete. Options I see:
   a. Move SA reconciliation after complete (risk: stage-creep, users may key off complete, breaks compatibility).
   b. Rename current complete to something else and make SA the new complete (breaks compatibility also).
   c. Use Kubernetes-style Conditions, reconciling sub-resources independently. Cleaner, but hard to mix Conditions with the current sequential sub-reconcilers (they seem mutually exclusive).
6. Finalizers
   I didn't add any. Can you spot a case where we must guarantee cleanup via a finalizer?
7. orgId support
   All operations target the default organization at the moment. Do we need orgId in the spec?

[Baarsgaard]

Hi, thanks for the PR! :D
As this is WIP I have mostly commented on style rather than functionality or wording.

Since you diligent with adding logs, I would like to direct you to: https://github.com/grafana/grafana-operator/blob/master/controllers/contactpoint_controller.go#L209
It's one of the few examples of debug level logs in the project by adding the .V(1)
It could be useful to you if you've been wanting to add more logs but have been holding back.
In case you have questions, feel free to leave comments!

[theSuess]

Thank you for your continued investment in this feature - it's very appreciated!

We took some time to answer your questions

1. Separate CRD vs. embedded spec

If it doesn't singificantly simplify the implementation, we'd prefer for service accounts to be specified as part of the Grafana CR.
Having a seperate resource would mean allowing one SA to be matched to multiple grafana instances which complicates storage & retrieval of secrets

2. Same-namespace assumption

When keeping the service accounts as part of the Grafana CR, splitting across namespaces is not possible.

3. Secret location & scope

This is a good point and being able to specify the namespace for the secret is something that we definetly want

4. Permissions sub-spec

This isn't really a questions but more of a topic for a follow-up PR. For what
it's worth, we can get enterprise licenses in CI if we implement this
functionality.

5. Placement of the SA reconciler

We discussed this and came to the conclusion that conditions are probably the
cleanest solution. We'll draft up a PR which migrates from the stage based
reconciliation logic to one based on conditions which you can rebase this PR on.
I don't have a timeframe for this but we'll keep you updated.

6. Finalizers

The only situation in which a finalizer would be applicable would be with
external instances. However, I don't think we need to implement this for now as
I'm in favor of not deleting service accounts for external instances as this
might have unintended consequences. This also keeps consistent with other
resources as we don't delete dashboards/folders etc. when deleting the Grafana
instance.

7. orgId support

This is something we can explore in a follow up PR. Let's keep it to the default
orgId for now to reduce the scope and make it easier to review.

---

Again thanks for all the work! If you have more questions or want to chat about this PR, feel free to join our maintainer meeting every Monday at 11:00 CEST. If you prefer async communication, discussing this further in the PR is also always possible :)