What must a Helm deploy identity be able to write beyond the objects its chart renders?

## The chart is not the whole write set People scope a deploy identity by reading the chart: it renders a Deployment, a Service and a ConfigMap, so the identity gets those three kinds and the install is expected to work. It does not, because a Helm release is not only the rendered objects. Helm keeps its own state, in the cluster, in the release's namespace, written with the same credentials. ## Release storage Every revision of a release is persisted as one record. With the default storage driver that record is a **Secret named `sh.helm.release.v1.<name>.v<rev>`** — `sh.helm.release.v1.tiles.v3` for revision 3 of a release called `tiles` — living in the release namespace, holding the chart, the values it was rendered with, the rendered manifest and the release status. Helm touches it constantly: - **list** the records in the namespace, to discover the release and its latest revision — this is also exactly what `helm list` reads; - **read** the newest record on upgrade, because the previous rendered manifest is the input to the diff Helm applies; - **create** a new record for the new revision; - **update** records as status moves through pending, deployed, failed and superseded; - **delete** records when history exceeds `--history-max` (default 10), and delete them all on `helm uninstall` unless `--keep-history` is used. An identity that may write Deployments but not Secrets in that namespace therefore cannot install anything there at all, and the failure looks nothing like a chart problem. The reverse is also worth stating: because the record holds the values, anyone who can read Secrets in the release namespace can read every stored revision's values, whether or not they can install. `HELM_DRIVER` changes where this lands: `configmap` stores the same records as ConfigMaps, `memory` keeps them only for the life of the process, and `sql` puts them in an external database — the last of which removes the in-cluster storage requirement but adds a connection string to manage. ## Reading before writing An upgrade is not a blind write. Helm compares three things — the previously stored manifest, the newly rendered one, and the live object — so the identity must be able to read the objects it manages, not just create them. In Helm 4 the write itself is a server-side apply by default (`--server-side` is a boolean defaulting to true on install, and a string defaulting to `auto` on upgrade and rollback, which inherits whatever the previous revision used). That matters here because the write reaches the API server as a patch rather than as the Helm 3 client-side create-or-update, so an identity scoped tightly around one write verb can behave differently on a Helm 4 release than on one first installed by Helm 3. ## The cluster-scoped edges Two very ordinary flags quietly leave the namespace: - `--create-namespace` creates a Namespace, and Namespaces are cluster-scoped objects. A pipeline that provisions its own environment therefore needs a cluster-scoped write that a per-namespace identity does not have. - Anything under the chart's `crds/` directory is installed on first install if the CRD is not already present. CustomResourceDefinitions are cluster-scoped. They are never templated, never upgraded and never deleted by Helm, which means the requirement is a one-time one and is a good candidate for pre-installing under a different identity. ## Worked example A geospatial tile-server chart is installed by a pipeline into `geo-staging`. The chart renders 14 namespaced objects. The pipeline's identity was scoped to exactly those kinds, and the first `helm upgrade --install` fails before creating any of them, because Helm could not list release records in the namespace. Adding Secret access in `geo-staging` fixes it; nothing about the chart changed. After 11 upgrades the pipeline also starts deleting records, because the default history cap of 10 has been reached — a delete permission that nobody predicted from reading the chart. ``` $ kubectl get secret -n geo-staging | grep sh.helm.release sh.helm.release.v1.tiles.v2 helm.sh/release.v1 1 6d sh.helm.release.v1.tiles.v3 helm.sh/release.v1 1 2d ``` ## How to derive the write set honestly Render the chart offline with `helm template` and list the distinct `kind` values — that gives you the chart's contribution. Then add release storage in the target namespace, plus a namespace create if the pipeline uses `--create-namespace`, plus the `crds/` contents if this is a first install. Anything left over — a hook Job, a test Pod — will show up in the render too, because hooks are ordinary manifests with an annotation.