Those values now are generated by the Charm and are handled as config options. We should move to using juju application-secrets for storing these secrets, to make their handling more secure.
We propose that we currently go with application secrets (and not user secrets) since we would not expect users for now to need to update the credential values of MinIO.
What needs to get done
Convert the secret-key and access-key from config options to application secrets
Keep the logic of autogenerating the values, so MinIO can generate secure ones
Context
Right now the
secret-key
config value of MinIO has a""
value as default. This then means that MinIO will create a random big password and use this value for thesecret-key
https://github.com/canonical/minio-operator/blob/track/ckf-1.8/src/charm.py#L219-L234Those values now are generated by the Charm and are handled as config options. We should move to using juju application-secrets for storing these secrets, to make their handling more secure.
We propose that we currently go with application secrets (and not user secrets) since we would not expect users for now to need to update the credential values of MinIO.
What needs to get done
secret-key
andaccess-key
from config options to application secretsFor this work though we might need to keep the effort of being compliant with
s3-interface
https://github.com/canonical/minio-operator/issues/160Definition of Done