Add support for helm-secrets helm plugin

[cognifloyd]

Is your feature request related to a problem? Please describe. Helm deployments (introduced in #15882) often need secrets. Those secrets should not be stored unencrypted in scm systems like git.

Describe the solution you'd like I use helm-secrets (https://github.com/jkroepke/helm-secrets) helm plugin to manage this for me.

Important implementation notes:

• pass values files with secrets://path to trigger it
• secrets get pulled from vault
• make sure the pants cache won't inadvertently reveal the secrets from vault

I use the vault backend for this, but it looks like that is about to be deprecated in favor of vals: https://github.com/jkroepke/helm-secrets/pull/246. I'll have to look into what that means later.

Describe alternatives you've considered I guess some people might use a post processor of some kind. But helm-secrets is the defacto standard.

Additional context @alonsodomin asked me to file this based on my comment: https://github.com/pantsbuild/pants/pull/15882#pullrequestreview-1062356484 https://github.com/pantsbuild/pants/pull/15882#issuecomment-1206775764

[alonsodomin]

I've been studying the possible way in which we can support this. The Helm Secrets plugin has two main usages:

• Override the Helm command line to make Helm charts aware of the secret value references and perform encryption/decryption of the values.
• As a downloader plugin that decrypt a Helm chart

At this point I'm not 100% sure we are after the possibility of uploading entire Helm charts into secret stores so the most general use case would be to resolve references to secret values in the rendered manifests right before deploying. In this regard, it looks like Helm Secrets is just a Helm post-processor since it delegates this secret resolution to vals.

That makes me believe that, instead of going to straight to support Helm Secrets, and implementation that is solely based on using vals in the current post-renderer will suffice for most use cases because this gives the liberty to end users to manage their secrets their own way and the Pants Helm backend will only make use of vals during the post-rendering.

This could be implemented in two different ways:

• Define a new subsystem for the vals tool and hard-code its usage in the internal post-renderer wrapper script.
• Add support in the helm_deployment target for arbitrary, user-level post-renderer by adding a post_renderer field to the target. This field should be a reference to another target that has a RunFieldSet associated with it. In this implementation, users would have the freedom of defining their own post-renderers in any of the languages supported by Pants and, in the case of supporting vals (or any other tool) they could define a experimental_shell_command that invokes vals eval ....

I feel more in favor of the latter option as it it seems like a more general solution and has a broader range of possibilities without adding more subsystems to Pants. My only concern with that one is that it will require good documentation in our side to showcase how this feature can be leveraged to resolve secrets using vals.

Any thoughts?

[cognifloyd]

I currently use the vault backend in the helm-secrets plugin, so I will play with their updated vals backend to see how that might change things.

I do not use the helm secrets ... wrappers. For example, I do helm upgrade -f secrets://relative/path/to/values/file/with/secrets.yaml instead of helm secrets upgrade -f relative/path/to/values/file/with/secrets.yaml.

Then in the secrets file I have something like this:

env:
  VELA_SECRET: !vault secretv2/helm/vela/cluster/vela-server#VELA_SECRET

Using it like this, the values file gets pre-processed before helm sees it vs a post-processor which has to parse through all the templated resources to deal with injecting changes.

I will play with vals to see how that changes my setup.

[cognifloyd]

Let me clarify further.

As a downloader plugin that decrypt a Helm chart

That's not right. It doesn't decrypt an entire chart. It only decrypts values files (or certain parts of values files) before helm uses those values to template the resource templates. It "downloads" any values files with the secrets:// scheme, not the whole chart.

It is an implementation detail that it uses vals or something else to handle decrypting the file... though I still need to test some of my assumptions about that backend. I'll report back.

[alonsodomin]

Thanks for the clarifications, i never used that plugin and now I understand better the use case.

The support I implemented so far is more general, not specific to secrets or vals and something I wanted to support anyway.

May not be the best approach for dealing with secrets so I may still look for an implementation of this.

El jue, 13 oct, 2022 a las 17:59, Jacob Floyd @.***> escribió:

Let me clarify further.

As a downloader plugin that decrypt a Helm chart

That's not right. It doesn't decrypt an entire chart. It only decrypts values files (or certain parts of values files) before helm uses those values to template the resource templates. It "downloads" any values files with the secrets:// scheme, not the whole chart.

It is an implementation detail that it uses vals or something else to do handle decrypting the file... though I still need to test some of my assumptions about that backend. I'll report back.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>