Closed LiamStorkey closed 1 year ago
I was hoping I would have time this week to review this, but unfortunately I haven't had the chance to get back to this.
I will try to review, merge, and release this early next week.
Thank you for your contribution, and again, my apologies for the delay in resolution.
That is completely fine @keelerm84 Thanks for letting me know!
@LiamStorkey I'm looking at this this morning and I had a question. On the issue, you mentioned:
Currently, the helm chart supports envfrom the configMapRef but this does not support secure string secrets (like sdk keys) as it would require them to be in plain text in the values files.
The existing secrets
configuration doesn't require the plaintext value of the secret to be in your value file. It requires configuration for the environment name, the secret name and key; however, that doesn't expose the actual secret VALUE.
Does that negate the need for this change?
@keelerm84 no - Another key feature of this change is how it is dynamic in nature. The method you have mentioned requires the values file for this chart to know the secret's Key
in order to get its value. This change will dynamically grab all the key-value pairs in the secret, whether it's 1 or 15.
Thank you for the clarification, and again for the contribution. This change is available in v2.3.0.
Requirements
Related issues
https://github.com/launchdarkly/ld-relay-helm/issues/44
Describe the solution you've provided
Added a new value that creates a new
envFrom
secretRef
from a pre-existing k8s secret (managed by the user in their own desired way - like external secrets operator). This allows users to create environment variables from secure strings without needing to have them in the plain text of the values filesDescribe alternatives you've considered
I did not want to add to the helm chart the ability to create the secrets from an external value source (like AWS SSM) because that would force users to have specific tools already deployed into their clusters. Let them create the secret and manage it in their own way.
Additional context The secret would be a key-value pair and would create the environment variables in the same way the current
configMapRef
does.