Whose credentials does Helm's lookup function use, and when does it return nothing?

## What lookup is `lookup` is a Helm-specific template function that reads live objects from the cluster while a chart is rendering. It takes an API version, a kind, a namespace and a name, and returns a map of that object or an empty value if it is not there. Passing an empty name returns a list object whose `items` you can range over; passing an empty namespace searches cluster-wide for cluster-scoped kinds. The canonical use is preserving generated state. A Redis chart that generates a password on first install would generate a *new* one on every upgrade, because templates are re-rendered from scratch each time. The usual fix is to look the existing Secret up first and reuse its value if it is there. ## Who is doing the reading This is the part interviewers are actually probing. Since Helm 3 there is no in-cluster server component. `helm` is a client: it renders templates locally, then talks to the API server using your kubeconfig - the same current context `kubectl` would use, honouring `--kube-context` and the namespace resolution that `-n` and `HELM_NAMESPACE` drive. `lookup` is just another request on that connection. So: - there is no Helm service account, and no way to give `lookup` a different identity from the one applying the release; - the read is bounded by whatever RBAC the caller has, not by anything the chart declares; - the chart cannot see anything you cannot see - but it *can* see everything you can. That asymmetry is the risk. A platform engineer with cluster-admin rights who runs `helm upgrade` on a chart authored elsewhere is lending that chart their whole read surface for the duration of the render. A template can look up a Secret in another namespace and print it into a ConfigMap the chart renders, and the render will succeed, because the operator was allowed to read it. Nothing about the chart declares an intent to do so - the only way to find out is to read the templates or diff the render. ## When lookup returns nothing `lookup` is inert whenever Helm renders without talking to a cluster. `helm template` renders locally and returns an empty value from every `lookup`. A client-side dry run does the same. A server-side dry run does reach the API server, so `lookup` behaves as it does during a real install. This matters more than it sounds, because the empty value is falsy and charts branch on it. The password example inverts: rendered offline, the `if` sees nothing, takes the generate branch, and shows a brand-new password. Engineers reading that output conclude the chart rotates the password on every upgrade, when in reality the install path finds the existing Secret and keeps it. The reverse bites too - a CI job that renders a chart and diffs the output against the last release will report churn on exactly the fields that come from `lookup`, forever. So `lookup` breaks the property that makes a chart reviewable: that the rendered manifest is a function of the chart plus the values. With `lookup` in play the manifest is a function of the chart, the values, the cluster's current contents, and who is looking. ## The failure modes worth naming **Ordering and first install.** On a first install nothing exists yet, so every `lookup` in the chart returns empty. A chart that depends on an object it also creates cannot see it during the same render - rendering happens entirely before anything is applied. **Hooks do not trigger a re-render.** Manifests are rendered once per operation, so a `lookup` does not run again after a hook creates the object it was looking for. **A failed read is not the same as an empty one.** An object that genuinely does not exist yields the empty value. A read that fails for another reason surfaces as a rendering error rather than quietly becoming empty - so a chart that renders for one engineer and fails for another usually means the second one lacks the read, not that the object is missing. **Values that came from a lookup are not in Git.** Whatever the template printed from the live object becomes part of the rendered manifest for that revision, which is what Helm applies. The chart source alone no longer tells you what was deployed. ## How to handle it As a chart *consumer*: before installing a chart you did not write, render it and read the output, and grep the templates for `lookup` - that grep is the difference between "this chart deploys these objects" and "this chart reads my cluster". Run the install with the narrowest identity that works rather than a personal admin credential, so the render's reach matches the deploy's reach. As a chart *author*: use `lookup` sparingly and only for state that genuinely cannot be supplied as a value. Guard every use so the chart still renders sensibly when it returns empty, and document that `helm template` output will differ from the installed manifest for those fields. Where the goal is only to avoid regenerating a credential, an external secret operator or a pre-created Secret referenced by name is a more honest design than a chart that reads the cluster to decide what to write. As a *platform owner*: decide whether charts running in your pipelines may call `lookup` at all. Because it executes with the deploy identity, a chart's read surface is your pipeline's read surface, and that is a property of the chart you installed rather than of Kubernetes.