Open mkilchhofer opened 3 years ago
Extend the CRD appprojects.argoproj.io
Curious, why do you propose we extend appprojects.argoproj.io
and not applications.argoproj.io
?
Oh, you are right, I picked the wrong one, when I executed kubectl get crd | grep argo
.
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.
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).
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 https://github.com/argoproj/argo-cd/issues/1786.
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:
(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 thevaluesFrom
array. ThisvaluesFrom
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:Proposal
applications.argoproj.io
helm template
command is executed, the controller needs to "download" the ConfigMap/Secret containing thevalues.yaml
.helm template -f
with the downloaded file(s). Helm supports multiple values files: