Chart metadata exposed due to permissive RBAC on Helm release ConfigMaps and Secrets

Apply a namespaced Role in the release namespace granting get, list, and watch on secrets (plus configmaps only if you run Helm with HELM_DRIVER=configmap), bound via a RoleBinding to the single service account or user that executes Helm. No other principal needs read access to release metadata.

First, a correction to the premise: namespaces do not inherit RBAC or NetworkPolicies. --create-namespace produces an empty namespace whose default ServiceAccount has no permissions until something binds them. The realistic exposure path is cluster-scoped: the built-in view ClusterRole includes get/list/watch on Secrets, and edit/admin grant more. Any cluster-scope binding of those roles to a group or broad service account reaches every namespace, including freshly created ones. The question is not what the new namespace inherited, but which cluster-level bindings reach into it.

Confirmed behavior (Helm 3.x, secret driver)

• Each revision is stored as a Secret named sh.helm.release.v1.<release>.v<N> in the release namespace, labeled owner=helm.
• The payload is base64-encoded, gzipped JSON containing chart templates, computed manifests, and user-supplied values — everything helm get values and helm get manifest return. Base64 is encoding, not encryption.
• With HELM_DRIVER=configmap, the same data lands in ConfigMaps, which clusters often guard even more loosely.

These behaviors are stable across Helm 3.x and modern Kubernetes (assume v1.20+); verify role contents against your specific cluster version.

The Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: helm-release-reader
  namespace: <release-ns>
rules:
- apiGroups: [""]
  resources: ["secrets"]   # add "configmaps" if HELM_DRIVER=configmap
  verbs: ["get", "list", "watch"]

Bind it only to the Helm operator identity. Three constraints shape this:

• RBAC cannot select by label. No rule can be scoped to owner=helm resources, and resourceNames supports no wildcards. If the namespace is dedicated to the release, granting on all Secrets there is acceptable. Exact-name get grants work for narrow automation but break as revisions increment (v1, v2, …), and list is required for helm list and rollback discovery.
• Write access is as dangerous as read. A principal that can patch or update a release Secret can alter stored manifests, which Helm applies on the next upgrade — secret write becomes cluster-level resource injection. Restrict create/update/patch/delete to the operator identity.
• Never satisfy this with ClusterRoles. Binding CI identities to view, edit, or admin recreates the exposure cluster-wide.

Verifying the namespace has no permissive defaults

1. Test effective access per identity: kubectl auth can-i get secrets -n <ns> --as=system:serviceaccount:<ns>:<sa>, repeating for list and watch; kubectl auth can-i --list --as=... dumps everything granted.
2. Audit cluster-scope bindings: kubectl get clusterrolebindings -o wide, looking for view/edit/admin bound to groups like system:authenticated or to default service accounts. Confirm the exact contents of these roles against your cluster — aggregation and addons vary by version.
3. Enumerate every principal with Secret read using kubectl-who-can get secrets -n <ns> or rbac-lookup.
4. Confirm nothing was pre-applied: kubectl get sa,rolebindings,networkpolicy -n <ns>.
5. Prove the exposure: kubectl get secrets -n <ns> -l owner=helm, then decode one payload to see exactly what a reader obtains.

NetworkPolicies: not the control for this

No — not for this exposure. NetworkPolicies filter pod-to-pod traffic; reading release Secrets happens through the Kubernetes API server and is governed solely by RBAC and admission policy. A default-deny ingress policy at namespace creation is reasonable defense-in-depth for the workloads themselves, but it cannot block any principal that can reach the API server from reading metadata. Deploy it for workload isolation if you want it; do not count it as metadata protection.

One detail changes the recommendation above: is this namespace dedicated to one release or team, or do other workloads keep their own Secrets there? If it is shared, list on all Secrets is too broad — move the release to its own namespace, or fall back to exact-name get grants and accept the revision-increment limitation.