search

grafana / grizzly

A utility for managing Jsonnet dashboards against the Grafana API
https://grafana.github.io/grizzly/
Apache License 2.0
514 stars 66 forks source link

[Feature Request]: Better support for credentials. #468

Closed lomori closed 2 months ago

lomori commented 2 months ago

Feature Request

We find the handling of credentials described here a bit lacking. Nobody should handle secrets manually. I certainly agree that Grizzly should not export secrets however there are some ways it could help during deployments. One such way is to use placeholders for credentials, and perhaps for other configurations too, and replace them with contents from environment variables at runtime during pushes. A common workflow within K8s is to mount secrets as environment variables and use things like ExternalSecrets to decouple the client from the actual secret backend. This would work very well for CI/CDs where grr is used for dashboards, datasources, and datafolders deployment. Or at least like jsonnet, have an indirect support to it using "--ext-str" and "std.extVar" (not our preferred way). Yes, this could be accomplished using standard Linux source command to create environment variables from a file (secret mount) and then piping the output of envsubst to grr, nevertheless native Grizzly support would be cleaner, IMHO.

malcolmholmes commented 2 months ago

You can provide credentials to Grizzly via environment variables as well as context configs. This should solve your problem. See lower down on the page here.

I'm closing this issue now. Please feel free to re-open if this doesn't work for you.

lomori commented 2 months ago

Sorry, maybe my request was not well written. We are not talking the context for Grizzly itself, as your reference appears to indicate. We want an enhancement to better handle secrets. The other reference to your documentation that I sent touches the core point. I'm not sure if I can re-open this ticket. Could you do it for me?

malcolmholmes commented 2 months ago

Are you saying you want the migration guide to be updated to reference environment variables? But isn't the migration process a one-off that we wouldn't necessarily want to automate?

If we can identify a clear ask, I can forward that to the authors of the migration guide.

lomori commented 2 months ago

This question is applicable for both migration and when creating new datasources. In the case of migration, the applicability of this "ask" is the target of the migration. How are datasources credentials handled? Is Grafana suggesting we manually handle those, as it's described in the link I sent? Remember that it's quite common for companies to have multiple environments, e.g. dev/uat/production, each using different credentials as they should. Who at this day and age handles credentials (datasources) manually? Just look at how jsonnet handles "--ext-str" and "std.extVar". Is this the same thing as you are suggesting?

I hope the ask has been clarified. On Friday, July 26, 2024 at 11:12:19 AM EDT, malcolmholmes @.***> wrote:

Are you saying you want the migration guide to be updated to reference environment variables? But isn't the migration process a one-off that we wouldn't necessarily want to automate?

If we can identify a clear ask, I can forward that to the authors of the migration guide.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

malcolmholmes commented 2 months ago

You can manage your datasources as YAML or JSON, but as you say, because they can contain credentials, this isn't the best idea. However, these credentials DO need to be included in the resources pushed to the API.

Therefore, the best approach is to generate these datasources. Have code that pulls them from a secret store or such. Yes, --ext-str in jsonnet can handle this. So either use Jsonnet, or try the new Grafana Foundation SDK if Jsonnet doesn't work for you.