Helm runs entirely client-side — which identity actually creates a release's Kubernetes objects?

## No server, no proxy, no escalation Helm is a command-line client and nothing else. `helm install`, `helm upgrade`, `helm rollback` and `helm uninstall` all run in your terminal or your CI runner: the CLI loads the chart, renders its templates locally into a set of manifests, opens a connection to the Kubernetes API server, and writes those objects itself. Nothing that belongs to Helm runs on the cluster — no Deployment, no controller, no webhook, no ServiceAccount of Helm's own. That was not always true. Helm 2 shipped a cluster-side component called Tiller that received a release from the client and applied it. Because Tiller usually ran with a very broad identity, being able to talk to Tiller was effectively being able to do whatever Tiller could do, and the client's own permissions barely mattered. Helm 3 deleted Tiller, and Helm 4 has not brought anything like it back. The sentence to say in an interview is therefore: **a release is created with exactly the credentials of whoever ran the command, and Helm can never do anything in a cluster that those credentials cannot do.** ## Where the identity comes from Helm loads client configuration the same way other Kubernetes clients do: - the `KUBECONFIG` file (or `--kubeconfig`), using the current context unless `--kube-context` names another; - `-n`/`--namespace`, or the `HELM_NAMESPACE` environment variable, or the namespace baked into the context, otherwise `default` — this is what lands in `.Release.Namespace`; - when Helm runs inside a pod and no kubeconfig is present, the pod's mounted ServiceAccount token, which is why a `helm upgrade` inside a Kubernetes Job authenticates as that Job's ServiceAccount; - optionally `--kube-as-user`/`--kube-as-group`, which ask the API server to impersonate someone else — and impersonation itself is a permission the caller must already hold. None of these grant anything. They only select which existing identity is used. ## What this changes in practice **Your access is the blast radius.** A CI runner that holds a broad cluster credential so that `helm upgrade` "just works" is a runner that can do everything that credential can do, from any job, chart or not. Reducing what a Helm pipeline can break is entirely a matter of narrowing the identity it runs as; there is no Helm-side switch for it. **Helm does not pre-flight your permissions.** It renders, sorts the manifests into its install order, and applies them one at a time. If the identity may create a Deployment but not a cluster-scoped object, the Deployment is created and the run then fails partway through, leaving the release recorded as `failed` with some objects present and some missing. Rerunning after the permission is granted is the normal fix, but the intermediate state is real and you should expect it. **The release record is written by you too.** With the default storage driver, each revision is a Secret named `sh.helm.release.v1.<name>.v<rev>` in the release namespace, created by the same identity as the rest of the release. Two consequences follow: an identity that cannot write Secrets in that namespace cannot install anything there at all, however permissive it is about Deployments; and anyone who can read Secrets in that namespace can read every stored revision, including the values that produced it. `HELM_DRIVER` can move that storage to ConfigMaps, to memory, or to an external SQL database, but the write is still the caller's. **Rendering is offline.** `helm template` does not contact a cluster at all: it renders with default capabilities and produces YAML on stdout. That makes it the safe way to look at a chart you were handed before any credential is involved — and the reason a render succeeding tells you nothing about whether the install will be permitted. ## A worked example A team ships a geospatial tile server as a chart that a GitOps controller pins elsewhere, but during development they install it by hand: ``` helm upgrade --install tiles ./tile-server -n geo-staging ``` Everything the chart contains — Deployment, Service, ConfigMap — plus the Secret `sh.helm.release.v1.tiles.v1` is created as the engineer's own user. Move the same command into a Job in the cluster and every one of those writes is attributed to that Job's ServiceAccount instead. Nothing about the chart changed; the identity did, and that is the only thing that decides whether the install is allowed.