Helm 3 stores release records in Secrets by default, in the same namespace as the release. That means anyone who can read Secrets in that namespace can reach the release records. Treat release data like other Secret data, and check what your records contain in a test namespace before deciding how sensitive they are.
What changed from Helm 2
The Helm docs say that Helm 2 used ConfigMaps by default and Helm 3 uses Secrets as the default storage driver. They also say information about a particular release is stored in the same namespace as the release itself.
Why this matters for access control
Release records are Kubernetes Secrets. The RBAC docs say reading Secrets can expose service account credentials, and that the view role leaves Secrets out for this reason. By the same logic, a role that can list Secrets in a namespace can list its release records too.
| Question | Answer |
|---|---|
| Where are release records? | Secrets, in the release namespace |
| Who can read them? | Anyone with Secret read access there |
| Are they encrypted? | Only if encryption at rest is enabled for Secrets |
For the third row, see Kubernetes Secrets encryption at rest: what it covers.
What to do
- List the release Secrets in a test namespace and look at their type and labels.
- Inspect what your own releases store. Do not assume. Chart values you pass at install can be part of what is kept, so check before you decide.
- Keep credentials out of chart values. Reference an existing Secret or an external secrets tool instead.
- Limit who can read Secrets in application namespaces, including CI service accounts that run Helm.
- Include release Secrets in your backup and retention thinking, since they hold install history.
A note on CI accounts
The account that runs helm install needs enough rights to create and read these Secrets in the target namespace. Scope that account to the namespaces it deploys to. A cluster wide account that can read all Secrets is a high value target, so see who can read Kubernetes Secrets.
Quick check
Do I need to turn anything on for Helm to use Secrets?
No. The Helm docs describe Secrets as the default storage driver in Helm 3.
Are release Secrets the same as my application Secrets?
They are Secret objects in the same namespace, so the same access rules apply, even though they serve a different purpose.
Safeguard compliance and evidence automation can help document who has access to sensitive resources.
Sources
Last reviewed: 19 October 2026.
