Replies: 4 comments
-
|
I have exactly the same problem. We have a GitHub actions that adds grafana annotation for each deployment. Whenever we re-deploy grafana or restart pods in k8s our API key disappears and we need to use horrible hacks to generate a new API KEY and update it in GitHub. We need a way to provision service accounts with predefined API KEY to make our lives much easier. |
Beta Was this translation helpful? Give feedback.
-
|
Same here, very needed feature. Grafana already allow to provision password for admin so we need same for service account. |
Beta Was this translation helpful? Give feedback.
-
|
Hey there! We want to let you all know that we are moving to Github Issues for feature requests. You can read more about the move here. I will be closing this discussion, but if you’re still interested in this request being implemented please don’t hesitate to open a feature request. Sorry for the inconvenience, and thanks for your contributions! cc @grafana/identity-access-team |
Beta Was this translation helpful? Give feedback.
-
|
#82987 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Service Accounts offer a nice method of integrating external tooling with Grafana without relying on authentication as a particular user, however the story for automated deployment is problematic.
Currently to create a service account via automation, it appears that the only method is via API calls, which requires authentication via an existing user/key, which defeats the purpose of service accounts - we're back to relying on a particular user's credentials being available for the action.
It also requires some not-insignificant plumbing - writing a client that does a multi-stage dance through the API to:
If I was doing this in Kubernetes, for example, I'd probably have to resort to writing a whole operator or something, backed by user credentials, to make this work with GitOps.
I propose that there should be a filesystem-backed method to provision service accounts, and associated pre-defined API keys, so that user accounts and API round-trips do not need to be involved in the process.
Beta Was this translation helpful? Give feedback.
All reactions