Allow username to be specified in persistence secrets

[dcaputo-harmoni]

What was changed

This commit allows the username to be specified alongside the password in persistence credentials secrets.

Why?

Many dynamic database creds generation / rotation systems (such as Hashicorp Vault) generate both the username and password dynamically, which is more secure than just generating / rotating passwords. The functionality has been updated to allow either or both of these to be optionally set via a secret with any or both of username and password keys.

[robholland]

This is a backwards incompatible change. While we can consider optionally storing the username in a secret, I don't want to force that.

[dcaputo-harmoni]

@robholland There are two commits that are part of this PR, in the second one I added username to server-secret.yaml (in the same manner as password) - does that not make it backwards compatible such that if password is specified directly it will be included in the secret? If not, let me know what you're looking for here and I'd be happy to revise it.

[4FunAndProfit]

I can confirm that it would be great to have this! It blocks me too so it must block quite a few :)

[robholland]

I mean I'm not sure everyone wants their username in a secret. While I can see a use case for that when credentials are being rotated, I think it's unusual to put usernames into a secret. Is their prior art for this in other charts?

[dcaputo-harmoni]

@robholland the necessity for the username to be part of the secret is that in systems that make use of advanced security / identity and access management, database creds are automatically and frequently rotated, with usernames rotating as well. Rotating usernames greatly increases security, because a threat would not know the username to be able to try passwords, and if they did gain access to a username it would only be valid for a limited time.

The best-in-class security frameworks such as Hashicorp Vault use this principle, here is a reference to vault's database creds rotation engine.

And here is a reference that shows how creds (both usernames and passwords) are automatically rotated in a kubernetes environment using VaultDynamciSecrets, which generate kubernetes secrets with the credentials.

There are plenty of other enterprise apps with helm deployments that support this architecture, a couple that come to mind which we use are grafana and jenkins, the latter actually has a pretty unique way of doing it where you annotate the secrets to specify which field contains the username and which contains the password, but that's likely overkill for this application as in their case they built it to manage a large number of credentials, whereas here we only have a couple to manage.