Description
At the moment, values.yaml provides 2 options for defining the config: a configmap and/or a kubernetes secret. However, it should be possible to refer to an already existing configmap or secret.
Motivation
We use external-secrets-manager where we store sensitive config values like OIDC info, and create a secret using it's templating functionality. We can create the exact same created as the one the helm-chart creates, but we can't reference it anywhere in the helm chart.
Work-around (with issues)
We can have a work-around by letting the helm chart create an empty secret, and let external-secrets-manager fill it. However, this has some serious drawbacks:
- deployment of the controller can already launch while the secret has not been populated yet
- The secret will always appear out-of-sync in ArgoCD which we use as our CD tool
Proposed solution
Allow us to specify additional volume mounts, so we can map our secret to the /etc/neuvector path ourselves.
Description
At the moment, values.yaml provides 2 options for defining the config: a configmap and/or a kubernetes secret. However, it should be possible to refer to an already existing configmap or secret.
Motivation
We use external-secrets-manager where we store sensitive config values like OIDC info, and create a secret using it's templating functionality. We can create the exact same created as the one the helm-chart creates, but we can't reference it anywhere in the helm chart.
Work-around (with issues)
We can have a work-around by letting the helm chart create an empty secret, and let external-secrets-manager fill it. However, this has some serious drawbacks:
Proposed solution
Allow us to specify additional volume mounts, so we can map our secret to the /etc/neuvector path ourselves.