WIP: feat: allow passing postgresql username and password from operator secret

[danielr1996]

Addresses #92

I invested a couple of hours how to solve this issue and want to share my findings:

In a kubernetes environment it's common to share credentials and connection information with secrets, e.g. from an external secrets operator, sealed secrets, or as mentioned in the issue postgres-operator. Generally there is no agreed standard, some might only include the password and other also the username. Therefore it's generally necessary to specifiy each connection parameter (host, port, username, password, database) separately so we can map it to the corresponding secret key instead of passing the whole connection to the container. Fortunately the vaultwarden image (or more correctly underlying pgsql library) supports this (https://github.com/dani-garcia/vaultwarden/wiki/Using-the-PostgreSQL-Backendm https://www.postgresql.org/docs/current/libpq-envars.html) . Unfortunately for mysql there seems to be no such support, so the solution I propose is postgresql only.

To specify the connection parameters separately instead of

DATABASE_URL=postgresql://username:password@host:5432/database

use

DATABASE_URL=postgresql://host
PGUSER=username
PGPASSWORD=username
PGPORT=5432
PGDATABASE=database

Note that DATABASE_URL must still be specified but must only contain the host, all parameters must be specified as the corresponding PG variables, otherwise vaultwarden tries to use the ones from DATABASE_URL.

The correcting handling of the environment is enabled specifying

database:
   existingSecret: postgresql-credentials
   existingSecretKey: "" # default to "" but if you set it to a non empty string this will override the following parameters
  existingSecretPasswordKey: password # defaults to password set to "" to use .Values.database.password
  existingSecretUserKey: username # defaults to username, set to "" to use .Values.database.username

This trigger on the condition {{- if and ( eq .Values.database.type "postgresql") .Values.database.existingSecret (not .Values.database.existingSecretKey)}} so it is backwards compatible with setups specifying already specifying existingSecretKey.

Please let me know what you think about this.

If you want to try this out you can use oci://ghcr.io/danielr1996/vaultwarden:0.24.3