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 the secret-key
https://github.com/canonical/minio-operator/blob/track/ckf-1.8/src/charm.py#L219-L234
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
For this work though we might need to keep the effort of being compliant with s3-interface #160
Definition of Done
- Secrets are used for the sensitive values of MinIO
- Spike for exploring if the Charm should generate values by default (we believe yes, but let's get feedback from DP team)
Context
Right now the
secret-keyconfig 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-keyhttps://github.com/canonical/minio-operator/blob/track/ckf-1.8/src/charm.py#L219-L234
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
secret-keyandaccess-keyfrom config options to application secretsFor this work though we might need to keep the effort of being compliant with
s3-interface#160Definition of Done