You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
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-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-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
#160Definition of Done
The text was updated successfully, but these errors were encountered: