Where does a password passed to helm upgrade --set end up besides the rendered Secret?

### Helm does not forget what you passed it `helm install` and `helm upgrade` do two things: they apply the rendered objects to the cluster, and they write a **release record** describing what they just did. That record is a Kubernetes Secret in the release namespace, named `sh.helm.release.v1.<release>.v<revision>` — one per revision. Inside it, Helm stores a JSON document that has been gzipped and base64-encoded, and that document contains, among other things: * **the values the caller supplied** — exactly the merge of `values.yaml` overrides that produced this revision, however they arrived: `-f`, `--set`, `--set-string`, `--set-file`; * **the fully rendered manifest**, which is every object the chart produced, including the `Secret` object with the credential in it; * the chart itself, its metadata and the revision's status. So a credential passed on the command line is not written once. It is written into the live Secret object, and it is written twice more into the release record — once as an input value and once inside the rendered manifest. Helm hands both back without ceremony: ```bash helm get values pdfsign -n payments # the values the release was installed with helm get manifest pdfsign -n payments # every rendered object, Secret included ``` Neither command needs a special privilege beyond being able to read Secrets in that namespace, because that is where the record lives. The practical consequence is worth saying out loud in an interview: **anyone who can read Secrets in a namespace can read every credential ever passed to any release in it**, not just the ones currently live. That is a wider blast radius than people expect, and it is a Helm property rather than a Kubernetes one. ### History makes it durable Rotation does not erase the old value. `helm upgrade` writes a *new* revision record and leaves the previous ones in place; Helm keeps the last `--history-max` revisions, which defaults to 10. If you rotate a PDF-signing service's passphrase at revision 47, revisions 38 through 46 still carry the previous passphrase, in the clear, in the same namespace — and they stay there until enough further upgrades push them past the retention window, or the release is uninstalled. That is also precisely why `helm rollback` can restore the old credential: the material is still there, by design. ### Reading it directly You do not need the Helm CLI at all. The record is an ordinary Secret, so: ```bash kubectl get secret sh.helm.release.v1.pdfsign.v47 -n payments \ -o jsonpath='{.data.release}' | base64 -d | base64 -d | gunzip ``` The double decode is not a typo: `kubectl` returns the Secret's own base64 field, and the value inside is itself base64 wrapping the gzipped JSON. Being able to describe that pipeline is a good signal that a candidate has actually looked at a release record rather than repeating a rule. ### Which mitigations actually move the needle * **`--set-file signing.passphrase=./passphrase.txt`** reads the value from a file rather than an argv string. That genuinely helps with shell history and with a process list on a shared host, and it is the right way to pass multi-line material such as a key. It changes nothing at all about the release record: the file's *content* becomes the value, and the value is stored. * **`.Files.Get`** is worse, not better. It reads a file that is packaged *inside the chart*, so putting a credential there ships it to everyone who pulls the chart, plus into the release record when the chart is stored with the release. (A `.helmignore` entry would keep the file out of the package — and then `.Files.Get` cannot read it either.) * **A values file in a repository** is not an improvement over `--set`; it moves the plaintext from shell history into Git history, where deleting the line later does not remove it. * **Referencing an existing Secret by name** is the one that works. If the chart takes `existingSecret: pdfsign-signing` and a key name, the credential never enters `.Values`, so the release record contains a name and nothing else, and `helm get values` is safe to share. ### What this is not Whether your CI platform masks the value in a job log, and how the cluster stores Secret objects on disk, are separate questions with separate owners. This one is specifically about Helm's own retention: the tool keeps a copy of everything you passed it, for ten revisions by default, in a namespace-readable object, and it will happily print it back to anyone who asks. The one-line version to say in an interview: *a secret passed to Helm is not a secret you handed to a running pod, it is a secret you filed.*