Add `envFrom` and `env.valueFrom` to ApplicationSourcePlugin

[karlschriek]

Summary

Instead of only being able to explicitly declare variables in the env field when using a plugin source, I would like to be able to read those vars from a Secret instead, using the typical envFrom and/or valueFrom syntax.

i.e. instead of using this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  ...
spec:
  ...
  source:
    plugin:
      env:
      - name: MY_VAR1
        value: foo
      - name: MY_VAR2
        value: bar

I would like to have this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  ...
spec:
  ...
  source:
    plugin:
      envFrom:
        secretRef: 
          name: my-secret2
      env:          
      - name: MY_VAR1
        valueFrom:
          secretKeyRef:
            name: my-secret1
            key: MY_VAR1

Motivation

I am using the plugins interface (https://argo-cd.readthedocs.io/en/stable/user-guide/config-management-plugins/) to create custom deployment workflows that depend on (sometimes sensitive) environment variables. I initially thought I might simply inject the ENV vars directly into the argocd-repo-server instead of defining them in the Application source, but the problem with that approach is that those ENV vars are not used when calculating the cacheKey (see (https://github.com/argoproj/argo-cd/blob/502762acc0e55813030bf0c19452fedd5b1154dc/reposerver/cache/cache.go#L141), so if one of them changes, argocd doesn't know that it should invalidate the cache.

A hash of the Application spec is however included in the cacheKey, so changes to vars under the env field do invalidate the cache.

Proposal

My proposal is to add envFrom and env.valueFrom to the ApplicationSource spec and ensure that any changes to the referenced Secrets are taken into account when the cacheKey is calculated.

[jannfis]

Where do you envision should those secrets live, i.e. in which namespace?

How would we ensure that a user with permissions to create an Application is privileged enough to read from that secret?

[karlschriek]

Hmmm, yes that is a good point. We don't typically host ArgoCD for multiple users. We use it to underpin a single (but highly complicated) installation on a single cluster. All the Applications are rolled out in the same namespace as argocd.

So for us any such Secret would be within in the argocd namespace by default, but in the more general case this would not hold.

I don't really have a good solution for this.

[stephan242]

Where do you envision should those secrets live, i.e. in which namespace?

They might end up in any namespace realistically ...

How would we ensure that a user with permissions to create an Application is privileged enough to read from that secret?

Argo CD should probably delegate these permissions through its RBAC: https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/

This feature would help me with defining Helm parameters in an application. For me Terraform is building resources, and knows some values a helm chart needs to know to do its thing, so I could use Terraform to create the ConfigMap or Secret, and then declare that dynamically in Argo CD. Otherwise I would have to manually transfer all of this.