search

grafana / oncall

Developer-friendly incident response with brilliant Slack integration
GNU Affero General Public License v3.0
3.52k stars 291 forks source link

Allow specifying database user from a Kubernetes secret #4804

Open ubajze opened 3 months ago

ubajze commented 3 months ago

What would you like to see!

We use an external PostgreSQL database for our deployment of Grafana on-call. Database credentials are generated on request. We use HashiCorp Vault to generate dynamic database credentials (PostgreSQL), meaning a unique username and password are generated whenever requested.

We can save credentials to a K8s secret. The current version of HelmCharts only allows for specifying a database password from a K8s secret, but not a username: https://github.com/grafana/oncall/blob/e2bc9d784b8d5e14eb963de78cbd31365389d515/helm/oncall/values.yaml#L564

This is a problem for us because the externalPostgresql.user field is mandatory and we cannot set it dynamically.

We would like to have a feature where we specify a username in a similar way to a password. So, instead of adding a username directly to values, we would like to reference a secret where our username is stored.

Product Area

Other

Anything else to add?

No response

github-actions[bot] commented 3 months ago

The current version of Grafana OnCall, at the time this issue was opened, is v1.8.10. If your issue pertains to an older version of Grafana OnCall, please be sure to list it in the PR description. Thank you :smile:!

ChristianCiach commented 2 months ago

We use cloudnative-pg which creates a Secret that contains the username, password, host, port and database-name, so I would like to retrieve all of these attributes by referencing a secret.

Funnily enough, the helm chart already supports configuring a usernameKey for all database types except for postgresql. But I would like to see a configurable hostKey, portKey and databaseNameKey in addition to that, to reference the keys of the Secret generated by Cloudnative-PG operator.

We currently workaround this issue by specifying dummy-values for externalPostgresql.user, externalPostgresql.host, externalPostgresql.port and externalPostgresql.db_name, and then patch these dummy values via Kustomize to reference the Secret instead.