change to load custom certs through a secret rather than configmap

[STollenaar]

• [X] Documentation written ℹ︎
• [X] Commit history is tidy ℹ︎

What this does

Currently if you need to install a custom CA cert for the monitor to work, it is installed through a ConfigMap. The standard for handling certs in Kubernetes is by putting these in a Secret. By instead putting it in a Secret you can also rely on other automated sources that handle these certificates (think of cert-manager, external-secrets).

Notes for the reviewer

Create the Secret for the certs instead of a configmap. Then install the helmchart following steps and set the certsSecret to the name of the Secret

[bgardiner]

@STollenaar Thanks for the PR!

Since the ssl-certs config map is defined outside of the chart, I think the current version of this PR is backwards incompatible with prior installs (i.e., it will break customers that have already installed the chart previously and are just running helm upgrade). How would you feel about migrating the ssl-certs to a projected volume that mounts both the config map and the new secret (both optional). With this refactor, I think whichever resource a user has created (old config map or new secret) will be mounted in.

[STollenaar]

@STollenaar Thanks for the PR!

Since the ssl-certs config map is defined outside of the chart, I think the current version of this PR is backwards incompatible with prior installs (i.e., it will break customers that have already installed the chart previously and are just running helm upgrade). How would you feel about migrating the ssl-certs to a projected volume that mounts both the config map and the new secret (both optional). With this refactor, I think whichever resource a user has created (old config map or new secret) will be mounted in.

that's good suggestion. I changed it to use the projected-volume instead and re-added the configmap value to the values.yaml. With the comment that it's deprecated.

[CLAassistant]

All committers have signed the CLA.