Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FEATURE: First-class support for secret decryption #928

Open
davejbax opened this issue Mar 31, 2024 · 2 comments
Open

FEATURE: First-class support for secret decryption #928

davejbax opened this issue Mar 31, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@davejbax
Copy link

Problem

Flux currently lacks first-class support for SOPS-encrypted secret decryption in Helm charts. If, for example, I wanted to load a Helm chart via a HelmRelease into my cluster and have it create some Kubernetes secrets from encrypted secrets stored in the Helm chart itself, the solutions available as I understand are:

  1. Use a Flux Kustomization which creates the HelmRelease and uses a secret generator to create the secrets, or
  2. Use an external secrets operator

Approach 1 ends up being slightly messy in a multi-cluster, multi-tenant scenario. Where Flux is used from a single centralised repo to pull application repos via HelmRelease resources and GitRepository sources, it becomes necessary to either:

  • Add the secret-generating Kustomization to the same repo storing the Helm chart code, which has the disadvantages of:
    • substantially increasing manifest boilerplate (e.g for each environment, kustomization.yaml, flux-ks.yaml, kustomizeconfig.yaml)
    • reducing local testability (since the Flux Kustomization is a CRD, it becomes cumbersome to use tools like Minikube without creating a local Flux installation)
  • Centralise all secret management in the centralised repo
    • e.g. apps/$app/overlays/$cluster/$env/{secret.enc,kustomization,kustomizeconfig,hr}.yaml
    • which is fairly untenable in a multi-cluster, multi-tenancy scenario in which we wish to decentralise as much workload-specific configuration as possible).

Approach 2 is feasible, but comes with its own disadvantages, which are covered fairly well in the Flux documentation on this topic.

Related issues

This issue has been raised in the past and discussed elsewhere online:

Proposal

I'd like to propose a cleaner solution for handling this case:

  1. Add an additional field to HelmRelease, named something such as valuesFilesEncrypted
  2. Decrypt these values files with SOPS when building the Helm chart

The ostensible benefits of this approach would be:

  • Removing the need to mix Flux Kustomizations and HelmReleases within a single repo
  • Secret management with SOPS in Helm charts becomes much more accessible
  • Simplicity
  • Backwards compatibility: the field would be optional, and no change in behaviour would occur if it is unset (which would be the default)

I'm happy to open a PR to implement the above, if the maintainers believe it is an acceptable idea to implement.

@davejbax davejbax changed the title First-class support for secret decryption FEATURE: First-class support for secret decryption Mar 31, 2024
@souleb
Copy link
Member

souleb commented Apr 17, 2024

This question has been partly answered in fluxcd/flux2#4075. We have no plan to implement it ourselves this year.

About the feature itself, I think it is an acceptable one, but the decryption and values merging should all be done by the helm-controller, as it should support all the sources types (we are adding ociRepository as a source).

@souleb souleb added the enhancement New feature or request label Apr 17, 2024
@Sebor
Copy link

Sebor commented Jul 11, 2024

As I understood @davejbax is ready to implement this feature ownself. And I completely agree with his arguments.
For our company, this is a big limitation for migrating to flux, because we have a lot of helm charts in monorepo and almost every chart has the following structure:

.
├── Chart.yaml
├── secrets-dev.yaml
├── secrets-prod.yaml
├── templates
│   ├── configmap.yaml
│   ├── deployment.yaml
│   ├── secret.yaml
│   ├── ...
├── values-dev.yaml
├── values-prod.yaml
└── values.yaml

The secret/configmap:

...
data:
  {{- range $key, $val := .Values.secrets }}    # or   {{- range $key, $val := .Values.config }}
  {{ $key }}: {{ $val | b64enc | quote }}
  {{- end }}

The container inside deployment:

...
envFrom:
  - configMapRef:
      name: {{ include "tempi-back.fullname" . }}
  - secretRef:
      name: {{ include "tempi-back.fullname" . }}

In that case it would be nice to have HelmRelease definition something like:

valuesFiles:
  - ./charts/chart1/values.yaml
  - ./charts/chart1/values-dev.yaml
valuesEncryptedFiles:
  - ./charts/chart1/secrets-dev.yaml

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants