Your Helm chart splices a values string into a container's sh -c command. What is the risk?

## Two parsers, two quoting problems Every interpolation in a Helm chart has to survive the parser that reads it. `quote` handles exactly one of them - the YAML parser that turns rendered text into an object. The moment the rendered value is handed to something else that parses it again, YAML quoting is irrelevant, because YAML already did its job: it delivered the string faithfully, metacharacters and all, to the next consumer. The common case is a container command. A chart for a media-transcoding pipeline writes something like: ```yaml command: - /bin/sh - -c - transcode --input {{ .Values.inputUrl | quote }} --out /data ``` This renders valid YAML. It also renders a shell script whose text the caller partly controls. A value ending in a semicolon followed by another command produces a command line the container's shell splits and runs as two commands. The manifest is well-formed, `helm lint` is happy, a structural check sees nothing wrong, and the payload runs with that pod's ServiceAccount token, its mounted Secrets, and its network position inside the cluster. Note that `quote` here is not merely insufficient - it is a false comfort. It puts double quotes around the value in the *YAML*, which the YAML parser then removes, delivering the bare string into the shell argument. Nothing in Helm knows the string is destined for a shell. ## Why this is a chart-design problem, not a values problem It is tempting to answer "then do not pass hostile values". But the entire premise of a shared platform chart is that the chart author and the values author are different people. Values arrive from a tenant's repository, a pipeline variable, an application manifest a reconciler applies, or a colleague's `-f` file. A chart that turns any of those into shell text has made an input executable, and the trust boundary now sits inside the chart rather than at its edge. The structural fixes are the ones that hold: - **Do not run a shell.** `command: ["transcode"]` with `args:` as a list means each element is passed as one argv entry; nothing splits on spaces or semicolons because no shell is involved. Metacharacters in a value become literal characters in an argument, which is the correct outcome. - **Pass data as environment or a mounted file.** An `env` entry, or a config file the program reads, keeps the value off any command line, and a program reading its own config is not parsing shell. - **Constrain the field.** `values.schema.json` can require a pattern for a URL-shaped field or an enum for a mode flag. Helm validates supplied values against the schema on install, upgrade, lint and template, so an out-of-shape value fails before rendering rather than after applying. - **Keep a shell out of the image where you can.** If the container has no shell, an `sh -c` entrypoint fails loudly instead of running a payload - a useful side effect of minimal images. ## The annotation variant of the same bug The other place a value crosses into another interpreter is a metadata block a chart splices wholesale: ```yaml metadata: annotations: {{- toYaml .Values.extraAnnotations | nindent 4 }} ``` `toYaml` is doing the right thing structurally - it re-serialises the map, so there is no YAML break-out. The problem is the *key space*: the caller may set **any** annotation on that object, and annotations are an instruction channel that several readers act on. The sharpest examples belong to Helm itself. A caller who can set `helm.sh/hook` on a rendered resource converts that object into a hook - Helm then treats it as part of a hook phase rather than part of the release's manifest, so it is no longer tracked with the release. A caller who sets `helm.sh/resource-policy: keep` makes the object survive `helm uninstall`. Neither requires touching the chart. Beyond Helm, an annotation on a workload or a Service is how many in-cluster controllers are configured, so an unbounded annotations map is an unbounded configuration surface for whatever controllers happen to be installed. The fix mirrors the command case: do not splice an unbounded map into a place where keys carry semantics. Either accept a fixed set of fields the chart writes into named annotations, or filter the map to a documented key prefix, and declare the shape in the schema. ## How to find these in a chart you did not write Render it and read it. `helm template` with realistic values shows the exact shell string and the exact annotation set. Then grep the templates for `sh -c`, for a `command:` containing an interpolation, and for `toYaml` landing under `annotations:` or `labels:`. A 3.4 MB chart tarball is far too big to read line by line, but those three greps cover most of the surface, and they are worth writing down as the checklist for anyone on the team who installs charts from outside. ## The framing to keep Quoting is not a security control on its own - it is a per-parser encoding step. The question to ask at every interpolation is who parses this next. If the answer is YAML, `quote` is right. If the answer is a shell, a URL parser, a log processor or a controller reading an annotation key, then the correct control belongs to that consumer: an argv list, a validated field, a bounded key set. A chart that never builds a command line out of caller input has removed the class rather than escaping its way around it.