launchdarkly / ld-relay-helm

A helm chart to ease deployment of the LaunchDarkly Relay Proxy
Other
6 stars 12 forks source link

Dynamic EnvFrom existing K8s Secrets #45

Closed LiamStorkey closed 1 year ago

LiamStorkey commented 1 year ago

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 files

Describe 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.

keelerm84 commented 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.

LiamStorkey commented 1 year ago

That is completely fine @keelerm84 Thanks for letting me know!

keelerm84 commented 1 year ago

@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?

LiamStorkey commented 1 year ago

@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.

keelerm84 commented 1 year ago

Thank you for the clarification, and again for the contribution. This change is available in v2.3.0.