hunting-helm-template-and-values-injection

Hunting Helm template and values injection: when a value becomes a manifest

Kubernetes packaging templates turn a values file into manifests, and that rendering is a text transformation with the same injection hazards as any templating: a value spliced in without quoting can break out of its intended field and inject new YAML structure, and a value that flows into a sensitive field can grant more than the author intended. When the values come from a place a tenant, a pipeline, or a user can influence, an override that self-service platforms and multi-tenant chart deployments commonly allow, the rendered manifest can gain a privileged security context, a host mount, an extra RBAC rule, or an altered container command. The manifest looks authored by the chart, but part of it was supplied by the caller. You hunt this by tracing untrusted values into the template and finding where they become structure or reach a sensitive field.

When to use

• Charts render Kubernetes manifests from values that a tenant, pipeline, or user can influence or override.
• A values field is rendered into a manifest without quoting, or into a command, annotation, or RBAC rule.
• A self-service platform lets callers supply overrides that reach a chart's templates.

Scope check

Test chart rendering only against charts and clusters you own or are authorized to assess, on non-production namespaces. A confirming override can create a privileged workload, so render and inspect manifests rather than applying them where possible, and stay inside the authorized cluster. If you can't name the authorization, stop.

The loop

1. Establish which values are untrusted first. Determine which values a caller (tenant, pipeline, user) can set or override versus which are fixed by the chart author. This is the false-positive killer: a value hardcoded by the author and never overridable is not an injection source no matter how it is rendered. Name the untrusted values, then trace them.