By default Helm keeps release information in Kubernetes Secrets in the namespace of the release. Because Helm can return a release's values on request, anyone who can read those Secrets, or who can run Helm against that namespace, may be able to see values you passed at install time, including any secrets you put in them.
What Helm records
Every install or upgrade creates a release record. The Helm documentation says release information is stored in Secrets in the release namespace by default, and that you can change the backend with the HELM_DRIVER environment variable to configmap, secret or sql. The command helm get values downloads the values for a given release, so values are part of what is stored and retrievable.
Who can read it
| Backend | Who can read | Note |
|---|---|---|
| Secret (default) | Anyone with get on Secrets in that namespace | Can be encrypted at rest if the cluster is configured for it |
| ConfigMap | Anyone with get on ConfigMaps | Docs warn this could expose sensitive data |
| SQL (beta) | Anyone with database access | Suited to releases over 1 MB |
The documentation makes the ConfigMap point directly: broader access is often granted to ConfigMaps than to Secrets. It notes, for example, that the default view role grants access to most resources but not Secrets. Switching to the ConfigMap backend could therefore expose your application's sensitive data.
What this means in practice
- A password passed with a values file or the set option ends up in the release record.
- A role that can read Secrets in the namespace can read every release there.
- Shell history and CI logs may also hold the command line you used.
How to reduce the exposure
- Keep secret values out of Helm values. Have the chart reference an existing Secret by name, and create that Secret from an external secret store.
- Limit who can read Secrets in each namespace. Review roles with get, list or watch on Secrets.
- Enable encryption at rest for Secrets in the cluster. See Kubernetes Secrets encryption at rest.
- Avoid the ConfigMap driver unless you have thought through who can read ConfigMaps.
- Keep CI logs clean. Use dry runs with the flag that hides Secrets in output.
- Rotate any secret that has been passed in values in the past.
For a role audit, see who can read Kubernetes Secrets.
Quick check
Does Helm encrypt release records itself?
The documentation says release information is stored in Secrets by default and that Secret data can be configured for encrypted storage in the cluster. Encryption at rest is a cluster setting.
Is it safe to put a database password in values.yaml?
It is better not to. The value becomes part of the release record. Reference an existing Secret instead.
Safeguard runs policies and gates on pull requests, so a failed rule can hold a merge, and its dependency and SBOM scanning covers the packages your infrastructure code pulls in. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
