[feature request] Random password when spec.users.passwordSecretRef is not provided?

[tamis-laan]

It would be nice if the operator by default could generate a random secure password for a user when no secret is provided (spec.users.passwordSecretRef).

It would also be nice if one could specify a list of namespaces in which these secrets will be copied as secrets can only be referenced within namespaces, something like spec.users.secretNamespaces.

[benruland]

We are also looking for the functionality to have to Operator create a random password!

When using Argo CD for rollout of a MongoDB as part of a Helm chart it is otherwise hard to create a random password as part of rollout (without using Secret Management tools), because Argo CD does not support Helm lookup yet.

[siegenthalerroger]

The second feature in the list is honestly more interesting to us, though auto-generation would just be better aswell.

[tamis-laan]

We are also looking for the functionality to have to Operator create a random password!

When using Argo CD for rollout of a MongoDB as part of a Helm chart it is otherwise hard to create a random password as part of rollout (without using Secret Management tools), because Argo CD does not support Helm lookup yet.

@benruland I'm using the following to generate a random secret:
https://github.com/mittwald/kubernetes-secret-generator

[benruland]

@benruland I'm using the following to generate a random secret: https://github.com/mittwald/kubernetes-secret-generator

Good idea, @tamis-laan! Just realized that ExternalSecrets Operator (which we already use) can also create random secrets: https://external-secrets.io/main/api/generator/password/

So this is another workaround.

[laurivosandi]

In any case the MongoDBCommunity CRD should stay imho in Pending state until secret is created. Without secret it ends in terminal Failed state

[SGStino]

@benruland I'm using the following to generate a random secret: https://github.com/mittwald/kubernetes-secret-generator

Good idea, @tamis-laan! Just realized that ExternalSecrets Operator (which we already use) can also create random secrets: https://external-secrets.io/main/api/generator/password/

So this is another workaround.

For those not using the ExternalSecrets operator, and using the mittwalt one ..

Just be carefull on larger clusters, the operator might watch all secrets, including helm charts with all versions values, which might be a considerable load on the kubernetes API.

[marcolongol]

IMHO, in order to "enable" the generated secrets to be copied to additional namespaces, simply enabling additional secret annotations in the CRD or inheriting annotations from the CRD/StatefulSet would be enough, that way either reflector or replicator could be used to copy the generated secrets to the additional target namespaces, this would be useful not only for the randomly generated passwordSecretRef but also for the generated connectionStringSecretName.

I'm happy to help with a PR if someone likes the idea and briefs me through the files needing to be modified😅