secretConfiguration deprecation points to ESO, but ESO doesn't cover its actual use case

[shcherbak]

Summary

charts/external-dns/values.yaml marks secretConfiguration as (DEPRECATED), and the stated recommendation (see #6586) is to manage secrets outside Helm via External Secrets Operator instead. ESO and secretConfiguration solve different problems, though, and ESO doesn't give existing secretConfiguration users a real migration path.

The gap

secretConfiguration takes a literal value already present in the Helm values (data: {}) and renders it into a Secret. In practice that value usually comes from a CI/CD masked variable or a sops/helm-secrets-encrypted values file. ESO solves a different problem: syncing a Secret from an external backend (Vault, AWS SM, GCP SM, etc.) via an ExternalSecret CR - requiring ESO installed and a backend already holding the value. If your secret's only home is a CI variable or an encrypted values file, ESO isn't a drop-in replacement; it means standing up a whole secret-management backend for one token.

Ask

Not proposing a specific mechanism (discussed/closed in #6586) - just flagging the deprecation notice points at a solution that doesn't fit the actual use case. Either a real migration path, or an amended note that's upfront about ESO only fitting when a backend is already in place.

References

• feat(chart): add extraManifests support to helm chart #6586 (closed)
• secretConfiguration in charts/external-dns/values.yaml

[stevehipwell]

Not proposing a specific mechanism (discussed/closed in #6586) - just flagging the deprecation notice points at a solution that doesn't fit the actual use case. Either a real migration path, or an amended note that's upfront about ESO only fitting when a backend is already in place.

@shcherbak ESO was an example of a solution; the actual position is that provisioning and managing secrets is completely outside the scope of the chart.

[shcherbak]

@stevehipwell Thanks for clarifying - that's a more defensible position than "use ESO," so let me respond to that directly instead.

I'd push back on drawing the scope line at "secrets" specifically. secretConfiguration never did any secret management - no rotation, no external sync, no generation logic. It did exactly one thing: render a Secret object from literal values already in the values file, the same way the chart already renders a Deployment, ServiceAccount, ConfigMap, PodDisruptionBudget, or RBAC objects from values. There's no lifecycle behavior attached to any of those either - they're all just templated resources.

If the position is "the chart shouldn't provision anything beyond running the external-dns workload itself," that's an internally consistent scope, but it's a much narrower one than what the chart currently does - and it would mean secretConfiguration being deprecated is really about removing an existing capability, not about redirecting users to an equivalent one. If the scope line is instead "no problem templating plain resources, just not Secret specifically," I'd genuinely like to understand what makes a Secret different in kind from the other resource types already in scope, since as implemented it carries the same amount of "management" as any of them: none.

Not trying to relitigate extraManifests here - just trying to pin down where the actual scope boundary is, since "provisioning secrets is out of scope" doesn't obviously follow from what the chart does today.

[stevehipwell]

@shcherbak the secret value shouldn't be inside the Helm chart values as it directly ties the security boundary and lifecycle of the secret to the chart.

[shcherbak]

@stevehipwell That's a much more concrete concern than "out of scope," and for the specific case of helm install/helm upgrade I think it's right: values get folded into the release manifest, which Helm persists as its own Secret, so a literal value in secretConfiguration genuinely gets duplicated into a second store with its own RBAC surface and its own retention (release history), independent of the app Secret's lifecycle. That's a real difference from Deployment/ConfigMap/PDB - those don't carry anything sensitive to duplicate.

But that argument is about the release storage mechanism specifically, not about the chart touching Secret objects at all - and it doesn't hold universally. A large share of this chart's users deploy it through GitOps controllers, Argo CD being the obvious one, which render Helm charts via helm template and apply the resulting manifests through their own reconciliation loop rather than via helm install/upgrade. There's no Helm release object and no sh.helm.release.v1.* Secret in that path, so there's no second exposure surface being created - the rendered Secret is just a Secret, with the same boundary as if it had been applied directly. For that deployment path the security-boundary objection doesn't apply at all.

Worth flagging too: the same caveat applies to extraManifests. If someone uses it to paste a literal secret value into a Secret manifest under values, that hits exactly the same release-storage duplication for native Helm users - extraManifests isn't inherently safer here, it just moves where the literal value is templated from. The security-relevant variable isn't which mechanism renders the Secret, it's whether values.yaml holds a literal value at all versus a reference to a Secret managed outside the chart.

So "values shouldn't hold secret material" isn't a universal rule - it's true for native Helm release storage and false for GitOps-driven rendering, and it's a property of how the value gets in, not of secretConfiguration specifically. Given that, would you be open to a narrower fix instead: keep an existingSecretName-style option that references a Secret the user creates and manages entirely outside the chart (CI/CD, sops-applied manifest, whatever), so the value never has to sit in values.yaml for anyone, regardless of how Helm is invoked or which mechanism renders the object? That closes the gap from the original issue without reintroducing the literal-value pattern you're objecting to.