Would you let Helm charts render Secret objects from values across a 12-namespace fleet?

### The decision, stated precisely Every chart that handles a credential sits on one side of a line: either the material passes through `.Values` on its way into a rendered `Secret`, or the chart only ever names a Secret that something else created. This is a *values-contract* decision, and across a fleet — say 12 namespaces holding a few dozen releases — it is the single choice that determines how many places plaintext credentials exist. ### What "the chart renders it" really commits you to Take the self-contained form first, because it is the default that upstream charts ship and the one teams reach for: ```yaml signing: passphrase: "" # required ``` The appeal is real. One command installs a working PDF-signing service. `helm template` reproduces the entire release. `helm get values` reconstructs the install. The chart can put a checksum annotation over the rendered credential so pods roll automatically when it changes, which is a genuine operational nicety. The cost is the trail. The value exists in whatever values file or `--set` supplied it, in the job that ran the command, and — twice — in the release record Secret Helm writes for the revision, which holds both the supplied values and the rendered manifest. Retention makes that durable: Helm keeps the last `--history-max` revisions, default 10, so a rotation leaves the old credential sitting in the namespace for another ten upgrades. Multiply by 12 namespaces and every release in them, and the honest description of the estate is: **anyone who can read Secrets in a namespace can recover every credential ever passed to any release in it**. That is usually a bigger grant than the one people think they are making when they hand a team namespace access, and it is what makes this a leadership decision rather than a chart-authoring preference. ### What the reference form costs ```yaml signing: existingSecret: pdfsign-signing passphraseKey: passphrase ``` Now the release record holds a name. `helm get values` is safe to paste into a ticket. Rotation stops being a Helm operation entirely — whoever owns the Secret updates it, with no upgrade and no new revision. And the chart cannot clobber the credential, which retires the whole regeneration failure mode. You pay for it in three places, and a principal answer names them rather than pretending the choice is free: * **The chart no longer installs itself.** There is a prerequisite step, which has to exist in every environment including ephemeral test namespaces and disaster recovery. Teams that skip designing that step end up with a chart that fails on first install in a way that reads like a chart bug. * **You lose the automatic roll on rotation.** The chart cannot checksum content it never sees, so when the Secret changes, pods keep the old value until something restarts them. You need an explicit answer for that — the workload re-reading its credential, or a deliberate restart in the rotation procedure. * **Reproducibility weakens.** The rendered manifest no longer fully describes the running system, because part of the input lives outside the release. That is exactly the property that made it safe, but it does mean a rendered diff is no longer the whole story. ### Where I would land, and how I would say it For a fleet, mandate the reference form for anything long-lived and shared — signing material, database credentials, anything whose compromise is not contained by the namespace. Allow the generate-or-pass form only where the credential's blast radius is the release itself and the environment is disposable, which usually means development and per-branch test namespaces. Write the rule as a values-contract convention every internal chart follows: an `existingSecret` field that, when set, wins, with the self-contained path kept only for the disposable case. Two implementation points make the mandate stick. First, enforcement belongs where charts are reviewed and rendered, not in a document — a render-time check that no rendered `Secret` in a production path carries a value sourced from `.Values`. Second, migration is the hard half: the credentials are already in existing release records, so switching the chart does not clean up history. The migration is *rotate, then move* — the old material stays recoverable in old revisions until it ages out, so it has to stop being valid, not merely stop being passed. Third-party charts complicate this and it is worth conceding: many upstream charts accept only a value, and the practical answer is to use whichever `existingSecret`-style field the chart already offers, and to treat a chart with no such field as a fact to weigh when adopting it — not something to fork over. The trap to avoid is declaring victory on the wrong boundary. Encoding the value, moving it from `--set` to a values file, or reading it with `--set-file` changes who can see it in a terminal and nothing about what Helm stores. The only change that empties the release record is the credential never entering `.Values` in the first place.