Is your feature request related to a problem? Please describe.

Secret generation and management is inherently tricky in a fully declarative paradigm. One way to solve this is to have secrets generated server side, as opposed to generating/declaring sensitive information on the client side and submitting that to the cluster.

Describe the solution you'd like

Currently the Redis and RedisCluster APIs support referencing an existing secret via the spec.kubernetesConfig.redisSecret field. It would be nice to give users the option to offload secret generation to the operator. One possible way this could be invoked:

spec:
    kubernetesConfig:
        generatePasswordSecret:
            name: the-secrets-name
            namespaces: 
                - ns-1
                - ns-2

Where the namespaces list is optional, and would default to only the namespace of the resource.

The operator would only allow for spec.kubernetesConfig.generatePasswordSecret or spec.kubernetesConfig.redisSecret to be supplied.

When generatePasswordSecret is supplied the operator would handle generating a sufficiently secure password and writing that to secret objects with the specified name in the set of namespaces. After creating this secret, the operator would use the secret when intializing the redis server similar to how it does so with the existing redisSecret field.

RBAC changes may be required to allow the operator to create secrets.

Having the operator generate secrets is a pattern seen elsewhere, for example the Zalando Postgres operator will generate and use user passwords in secret objects