camptocamp / helm-sops Goto Github PK

License: GNU General Public License v3.0

Go 100.00%

helm-sops's Introduction

Helm Sops

Helm Sops is a Helm wrapper which decrypts Sops encrypted value files before invoking Helm. It does so by using named pipes to pass cleartext value files to Helm in order to avoid secrets being written to disk in clear.

Installation

Prerequisites

Helm is needed for Helm Sops to work. Follow the instructions here to install it.

Getting Helm Sops binary

Helm Sops releases

Helm Sops released binaries can be downloaded from GitHub.

Building from sources

Helm Sops can be built using the go build command.

Deploying Helm Sops

Deploy Helm Sops executable (helm-sops) in a directory present in the PATH. When invoking Helm Sops, it will look for a Helm executable named helm in the PATH.

Alternatively, Helm Sops executable can be renamed helm before deploying it. When invoked as helm, Helm Sops will look for a Helm executable named _helm in the PATH.

Usage

Create encrypted value files using Sops

To pass these encrypted value files to Helm, just invoke Helm Sops with the same arguments which would be used for the Helm invocation (for example
helm-sops template . --values secrets.yaml --values secrets-production.yaml or
helm template . --values secrets.yaml --values secrets-production.yaml
depending on how Helm Sops was deployed).

Example application

An example application as well as an example Argo CD setup to deploy it can be found here.

Git diff helper

The following script (sops-git-diff-helper) can be placed in the PATH to be used as a Git diff helper for Sops encrypted value files:

#! /bin/sh

if [ $# -ne 1 ]
then
	exit 1
fi

if [ -n "${SOPS_ENCRYPTED_DIFF}" ]
then
	cat "$1"
else
	sops -d "$1" 2>&1 || cat "$1"
fi

To enable it, run git config --global diff.sops.textconv sops-git-diff-helper and add the following lines to the .gitattributes file in your Git repository:

*.yaml diff=sops

helm-sops's People

Contributors

Stargazers

Watchers

Forkers

victorboissiere biyanisuraj taxibeat debayande faja teejaded tanandy sudoblockio demacr gui iq-scm alfred030

helm-sops's Issues

Extend helm-sops to support pass-through of exit codes returned by plugins.

helm-sops summarily returns an exit code of 1 irrespective of the error encountered (and hence, exit code generated) upstream by helm (please cf. https://git.lystit.com/lyst/helm-sops/blob/f6776ac5af1ac0b2e49b67aa6b7f1401b0c44425/main.go#L223). As a result, it breaks workflows where other tools rely on the various exit codes generated by helm to perform further actions. As an example, please consider our workflow for deploying Helm charts.

We use Helmfile to deploy Helm charts. Helmfile's USP is that it allows one to maintain declarative manifests of customisations to a chart and provides the facility to conditionally update them in a cluster. In order for the conditional part to work, Helmfile relies on helm-diff under the hood to check for deltas.

Post-execution, helm returns:

the exit code of the plugin if a plugin was executed or,
an exit code of 1 if there was an issue or of 0 if everything worked

If the plugin in question is helm-diff, then one of the following exit codes gets returned:

0, if there's no error and no diff,
1, if there's an error, or,
2, if there no error but a diff

To tie this back to our workflow, an exit code of 2 is used by Helmfile to determine whether to (re)install a chart or not.

Now, introducing helm-sops into our workflow breaks it instantly since it gobbles up the exit code of 2 returned by helm and passes the exit code of 1 to Helmfile instead, causing it to exit with an error.

May I, therefore, request that helm-sops be extended to support pass-through of exit codes returned by plugins?

Thanks.

References

Release a pre-compiled binary for Windows

I saw that you now also release a pre-compiled binary for darwin.
May I request you to kindly release also a pre-compiled binary for Windows?

Thanks.

Optionally toggle `secretFilenameRegexp`

Use case

Restricting the decryption of files to those with the word "secrets" in the filename enforces a regex that can also be included as part of the .sops.yaml configuration file as a path_regex. This can produce a strange user-experience, in which the .sops.yaml is inclusive a given set of files, but the regex in helm-sops excludes it.

https://github.com/mozilla/sops#210using-sopsyaml-conf-to-select-kmspgp-for-new-files

Limitation on secrets filenames is a poor UX

The secrets*.yaml type naming restriction is a bit awkward - it's a bad user experience that has tripped me up a few times even when I knew it existed. It misses out on matching .yml files or secret-things.yaml, and at least some more recent forks of the plugin (e.g. https://github.com/jkroepke/helm-secrets that I use) have no such restriction - so helm secrets xxx works and helm-sops doesn't.

Can you not peek at every values-file in the argument list, and see if they contain a valid-looking sops/version key so its likely it's a sops file?

This was also requested on the original futuresimple version, see zendesk/helm-secrets#155.