Support helm values also via Secret and ConfigMap

[mkilchhofer]

Summary

Add the ability to use existing Kubernetes Resources (i.e. ConfigMaps and Secrets) as a source for helm values.
Somehow related to #5826.

Motivation

As I also use flux (currently the "new" v2/toolkit, but also used v1) I miss the feature to use a Kubernetes Secret or ConfigMap as a source for the values.yaml.

Look at the flux example here:

---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: argocd
  namespace: argocd
spec:
  interval: 5m
  chart:
    spec:
      chart: argo-cd
      version: "2.14.7"
      sourceRef:
        kind: HelmRepository
        name: argo
        namespace: flux-system
  values:
    installCRDs: false

    controller:
      enableStatefulSet: true

    server:
      extraArgs:
        - --insecure
  # (..)
  valuesFrom:
  - kind: Secret
    name: "argocd-values"
    optional: false

(Full example: https://github.com/mkilchhofer/k8s-gitops/blob/main/clusters/k3s/argocd/argocd.yaml)

What you can see here is a resource that looks very similar to the applications.argoproj.io object, except the valuesFrom array. This valuesFrom feature enables me to separate the sensitive values from the non-sensitive ones.

And this is the decoded Secret used in this valuesFrom section above:

$ kubectl get secret argocd-values -o jsonpath='{.data.values\.yaml}' | base64 -d
configs:
  secret:
    argocdServerAdminPassword: <REDACTED>

Proposal

1. Extend the CRD applications.argoproj.io
2. Before the helm template command is executed, the controller needs to "download" the ConfigMap/Secret containing the values.yaml.
3. Extend the "utility" that calls helm template -f with the downloaded file(s). Helm supports multiple values files:

$ helm template -h
  (..)
  -f, --values strings               specify values in a YAML file or a URL (can specify multiple)

[sbose78]

Extend the CRD appprojects.argoproj.io

Curious, why do you propose we extend appprojects.argoproj.io and not applications.argoproj.io ?

[mkilchhofer]

Oh, you are right, I picked the wrong one, when I executed kubectl get crd | grep argo.

[juliohm1978]

This would be a great addition to argocd. The ability to add multiple values sources to the helm release, including an independent ConfigMap, is the turning point that made me decide towards FluxCD.

That way, the source code repository can independently trigger the deployment of a new version by just committing a ConfigMap into itself. Meanwhile, all other values used in the helm release can be kept in a different repository.

[crenshaw-dev]

Having secrets on the repo-server means that secrets will be stored (somewhat) long-term in plaintext on 1) the repo-server disk space and 2) the Redis manifest cache. They'll also be visible in UI diffs (and therefore available via the Argo CD UI) unless either they are injected into Secrets (which we already redact) or we build some new mechanism to track where a secret was injected and then redact it in API responses.

Pulling from Secrets and/or ConfigMaps would also mean that the repo-server would be granted Kubernetes API access. I consider the repo-server the most likely place for someone to achieve remote code execution, just because of the sheer amount of code running on that Pod. RCE + k8s access is bad.

The final issue I'd point out is that Argo CD would have to track changes to the ConfigMaps and Secrets and bust the manifest cache whenever there are updates. The code change would be fairly complex, and it would be a step away from the gitops model.

All that said, I wouldn't consider these issues complete blockers, as this is a feature a lot of folks would find useful/convenient. I'd be interested to see a solution that starts as opt-in only and pulls only ConfigMaps (no Secrets).

[joaocc]

Not sure if this ticket is still being watched, but valuesFrom can also be used for non-secret information, but rather as a form of allowing more dynamic scenarios as described in #1786.

[Shaked]

@crenshaw-dev any idea if there's a plan to support this? FluxCD's valuesFrom is very useful since, I'd say the same is relevant for ArgoCD