Is your feature request related to a problem? Please describe.
The current helm architecture for handling the various secrets needed to deploy and manage Renku is uneven.
- Some have dynamic names
- Some have static names
- Some are generated in a template file
- Some are generated in manifests
- Some parts can make use of existing secrets while others don't
All of this means that if administrators would like to have full control over the passwords used in the application and where they come from, they have to:
- dig into the chart to find them all
- create the secrets manually ensuring the correct name is used
- ensure all other generated fields have the correct content
Besides that, the chart is currently not ArgoCD friendly from that point of view. All long lived objects such as secrets created as part of helm hooks will be ignored by default by ArgoCD. This means that typically, you will only see 2 out of 10 secrets managed which is not ideal.
Describe the solution you'd like
A more unified way to handle secrets.
Define what is expected from existing secrets VS what is provided through the chart. For example, at the database level, should the secret provide the db name, user name and password or just the two last while the db name is given through the values file ?
When an existing secret is used, don't do any special handling in the chart.
For pre-hook jobs requiring a secret, create a temporary one that will be nuked once the job is done so all ephemeral objects stays ephemeral. This will allow better integration with ArgoCD without requiring special handling.
Describe alternatives you've considered
As mean of unifying the handling, there's no options.
Providing values in a secure manner can be achieved using tools such as ksops or the helm secrets plugin however neither really helps on the handling cleanup side.
Is your feature request related to a problem? Please describe.
The current helm architecture for handling the various secrets needed to deploy and manage Renku is uneven.
All of this means that if administrators would like to have full control over the passwords used in the application and where they come from, they have to:
Besides that, the chart is currently not ArgoCD friendly from that point of view. All long lived objects such as secrets created as part of helm hooks will be ignored by default by ArgoCD. This means that typically, you will only see 2 out of 10 secrets managed which is not ideal.
Describe the solution you'd like
A more unified way to handle secrets.
Define what is expected from existing secrets VS what is provided through the chart. For example, at the database level, should the secret provide the db name, user name and password or just the two last while the db name is given through the values file ?
When an existing secret is used, don't do any special handling in the chart.
For pre-hook jobs requiring a secret, create a temporary one that will be nuked once the job is done so all ephemeral objects stays ephemeral. This will allow better integration with ArgoCD without requiring special handling.
Describe alternatives you've considered
As mean of unifying the handling, there's no options.
Providing values in a secure manner can be achieved using tools such as ksops or the helm secrets plugin however neither really helps on the handling cleanup side.