Loading
All: rework additionalSecrets usage. #110
Until this commit, additional secrets had the following format:
```
additionalSecrets:
secret-volume-name:
secretName: suffix-of-the-secret-name
mountPath: /some/path.json
subPath: field_in_secret_to_be_mounted.json
```
This resulted in the following pod config:
```
spec:
volumes:
- name: secret-volume-name
secret:
secretName: helm-release-name-suffix-of-the-secret-name
containers:
- volumeMounts:
- name: secret-volume-name
mountPath: /some/path.json
subPath: field_in_secret_to_be_mounted.json
```
There are two main issues with this configuration:
- secretName is always prefixed with the helm release. There is no way
to refer to the same secret from multiple helm releases inside the same
namespace. Requiring the creation of duplicate secrets for each release.
- `secret-volume-name`, which is functionally a value, is put as a key in
the yaml, complicating some operations with the yaml object. For example:
path traversal inside the yaml.
Rework all helm charts to accept both the current format and a new format:
```
additionalSecrets:
- volumeName: secret-volume-name
secretFullName: full-name-of-the-secret
mountPath: /some/path.json
subPath: field_in_secret_to_be_mounted.json
```
This solves the two previously mentioned issues.
To implement compatibility with both the old and new format, we relly on
the fact that `range` also works on arrays, returning as keys the array
indexes.
The commit also implements a small quality of life improvement:
- default volumeName to secretName. In practice, in most cases, users set
both to the same value anyway.
In a future major release it may be worth getting rid of the old format,
but that will be a breaking change for everybody.