Add support for secrets in Application parameters

It would be nice to have direct support for native secrets in the Application definition. In the following use case, when referencing a public chart, it would be very handy to have the possibility to reference a secret directly. ```yaml # external-dns.yaml --- apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: external-dns spec: project: kube-do source: repoURL: https://github.com/helm/charts.git path: stable/external-dns helm: parameters: - name: provider value: digitalocean - name: digitalocean.apiToken value: $(DIGITAL_OCEAN_TOKEN) - name: domainFilters value: $(EXTERNAL_DNS_DOMAIN) # suggested implementation secrets: - name: secrets-do destination: server: https://kubernetes.default.svc namespace: kube-do # secrets-do.yaml --- apiVersion: v1 kind: Secret metadata: name: secrets-do type: Opaque stringData: config.yaml: |- # this could be overridden for example during bootstrap using # helm template . --values values.yaml --set digitalOceanToken=abc DIGITAL_OCEAN_TOKEN: {{ digitalOceanToken }} EXTERNAL_DNS_DOMAIN: {{ externalDnsDomain }} ``` Resources related to `external-dns` to have more details * [docs](https://github.com/kubernetes-incubator/external-dns/blob/master/docs/tutorials/digitalocean.md) see `Deployment` env * helm chart [values.yaml](https://github.com/helm/charts/blob/master/stable/external-dns/values.yaml#L57) *

Posted by niqdev on Jun 19, 2019, 7:52 PM

Tags

• support (Network)

Related issues

• That Reddit post is feeding more conspiracy thinking than helping.
• Support BYOK/Custom Models for Inline Code Completions
• DNS-PERSIST-01 challenge support (planned for late Q1 2026)
• Yeah I can't really blame people for not realising they have shitty mics and shitty internet because it's really hard for them to tell!
• Onboarding guide for FluentAssertions
• Add WebTransport support