Random root password generation

[mnaser]

Hi there.

I'm looking at a case where I would like to completely eliminate the password generation for a use case when doing something like GitOps.

Ideally, we would avoid specifying a root password when creating a cluster, it then generates a secret with random password inside of it. We can then pick that up and add it into Vault and let Vault take care of generating users and dynamic credentials from then.

Right now, we can do most of that work but the only problem is that the root password must still be bootstrapped, and ideally, that's not a necessity for this.

Is this something that we can push a patch for?

[AMecea]

Hi @mnaser,

So you propose to let the operator fill the ROOT_PASSWORD (also to create the secret if does not exists), am I right? If this is the case then it sounds good, please open a PR and I will review it and merge it!

Thank you!

[tanordheim]

Having the operator generate the password if the secret its configured with does not contain a ROOT_PASSWORD would be great; we use Kustomize to deploy our workloads (including MySQL clusters) and we have no really clean way of injecting external configuration into our Kustomizations in a non-hacky way so for now we're relying on storing the cluster root passwords in the Kustomizations themselves which we'd really like to avoid. Having the operator create it and update the secret - or maybe generate a separate credentials-secret that contains username/password/database that it can keep up to date whenever it needs to change - would be great for us.

I'd also be happy to contribute a PR for this if needed - though I guess we have to agree on an upgrade path for it. If we assume the operator gets support for auto-generating root passwords, how would we ideally handle;

1. I want to get rid of the root passwords from my Kustomize configuration, so I remove the ROOT_PASSWORD from my cluster secret and redeploy the cluster. Should the operator then:

• a) Update the secret with the ROOT_PASSWORD that was previously set and is currently used in the cluster.
• b) Generate a new random password, update the secret and also update the auth settings in the MySQL cluster.

2. I have a cluster secret without a ROOT_PASSWORD, and deploy an update with a ROOT_PASSWORD set. Should the operator then:

• a) Ignore the change and keep the auth settings in the MySQL cluster as-is? Where would clients in that case get the correct password to use when connecting?
• b) Update the auth settings in the MySQL cluster.

For 2. there might be some support for this already - does the operator change the MySQL root password if the information in the secret changes already? I quickly glanced through the code here but couldn't really pinpoint which component does this and where/when it happens. A few pointers in the right direction would be great. Thanks.

[sgavrylenko]

Hi there, I found this function in https://github.com/bitpoke/mysql-operator/blob/52a868d7ed381269bd276ef3a7a2466f0d1bb2ad/pkg/controller/mysqlcluster/internal/syncer/secret_operated.go#L81

Does it mean that this issue can be closed?