Which parts of a third-party Helm chart run code you never asked for?

### The value table is not the attack surface A chart's `values.yaml` describes what the author expects you to configure. It does not describe what the chart runs. Three constructs execute images at times you did not choose, and all three are visible in the rendered output if you know to look for them. ### 1. Hooks Any manifest carrying the `helm.sh/hook` annotation is pulled out of the normal release and applied at a lifecycle event instead. Helm defines nine events — pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback and test. `helm.sh/hook-weight` orders them (lower first, as strings sorted numerically), and Helm waits for each hook to reach a ready/complete state before applying the next weight and, eventually, the release's own manifests. The consequences for a chart you did not write are concrete. A `pre-install` Job runs **before** any of the workloads you reviewed exist, so "it only starts the order-checkout API" is not what happens first. The Job runs an image the chart names, with args the chart chose, under a serviceAccountName the chart may also have created — which is why the same render pass that finds the hook should follow the ServiceAccount it references. `helm.sh/hook-delete-policy` decides the Job object's fate: `before-hook-creation` (the default behaviour) deletes a previous one before creating the new one, `hook-succeeded` deletes it on success, `hook-failed` on failure. With no policy that succeeds silently, the Job and its completed pod stick around — annoying, but also the only place its logs still exist. Hook resources are not tracked like ordinary release members: Helm does not manage them across upgrades the way it manages a Deployment, and `helm uninstall` does not necessarily clean them up. `helm get hooks <release>` lists them for an installed release. ### 2. initContainers and sidecars These hide in plain sight because the enclosing object is an ordinary Deployment or StatefulSet. An initContainer runs to completion before the main container starts, frequently as root, frequently with a volume mount the main container does not have — chown-ing a data directory, tuning a sysctl, fetching config. A sidecar runs for the pod's whole life and shares its network namespace. Both are images the chart picked, and neither appears in a kind inventory: `grep '^kind:'` shows one Deployment whether it holds one container or five. ### 3. `helm test` `helm test <release>` runs the manifests annotated `helm.sh/hook: test` as pods in the cluster, against the live release. It is a command an operator runs deliberately, but the pod specs come from the chart, so they belong in the same review. ### Isolating them in the render `helm template` includes hook manifests in its output, which is good, but they arrive mixed into a thousand lines of YAML and are distinguished only by an annotation. The clean trick is to render twice and diff: render once normally, once with `--no-hooks`, and the difference is exactly the chart's hook set. Then grep the whole render for `initContainers:` and read each pod spec's full container list. ### Why dry-running does not help here Neither `helm install --dry-run=client` nor `--dry-run=server` executes hooks. A dry run tells you a `pre-upgrade` Job exists and shows you its spec; it never tells you what the image inside it does. That gap is the whole reason the review is a reading exercise: you are judging an image reference and a command line, not observing behaviour. ### The failure mode this prevents Consider an umbrella chart bundling an order-checkout API and a worker subchart, installed with `--timeout 96s`. Its `pre-upgrade` hook Job runs a schema migration against the production database and takes longer than that. Helm's wait expires, the upgrade fails, and the migration is still running — half-applied, with a release now in a failed state and an already-mutated database that no rollback of Kubernetes objects can undo. Nothing in the value table said an upgrade would touch the database; the hook manifest did. Knowing a chart's hooks before you run it is what turns that from an incident into a decision: give the migration its own review, run it deliberately, or set a timeout that matches reality. The general rule: in a third-party chart, ask which images run, when, as whom, and whether their effects are reversible. Hooks answer "when", initContainers answer "which images you missed", and the serviceAccount reference answers "as whom".