After moving CI to Helm 4, why does helm plugin install now fail for a plugin that installed fine under Helm 3?

## The symptom A team moves its CI image from Helm 3 to Helm 4. Chart rendering is fine, the release history reads fine, the invoice-rendering worker deploys fine — and the image build fails at the step that installs the team's helper plugin. Nothing about the plugin changed. Meanwhile, every engineer's laptop still works, because their plugin directory was populated months ago and is simply carried forward. That split — installs fail, already-installed plugins keep working — is the signature of this class of migration issue, and it is worth recognising it in an interview because it explains why the failure appears late, in the pipeline, rather than during a local trial. ## What changed Helm 4 rebuilt the plugin system. The part relevant to a migration is the **verification default**: `helm plugin install --verify` defaults to **true**. Helm 4 also gained `helm plugin package --sign` and `helm plugin verify`, so plugins have a first-class signing story. If the plugin you are installing has no valid provenance to check, the install fails rather than proceeding. The opt-out is `--verify=false`. That precision matters more than it sounds: there is no `--allow-insecure-plugins` flag, no `HELM_ALLOW_UNSIGNED` environment variable, and no config file toggle to reach for. A candidate who confidently names one of those has pattern-matched from other tools rather than from Helm. ## What did not change An installed plugin is a directory under Helm's plugin path (`HELM_PLUGINS` still points at it, and `helm env` still prints it). Helm 4 reads a `plugin.yaml` that predates the new metadata format and treats it as a legacy CLI plugin, which is why plugins installed under Helm 3 keep appearing in `helm plugin list` and keep running after the client is replaced. That backward compatibility is the reason the problem is invisible on developer machines and visible only where the install step actually runs. ## The asymmetry worth carrying Helm's two signing stories have opposite defaults, and conflating them is a real error: - **Charts.** Provenance is OpenPGP-based: `helm package --sign` writes a clear-signed `.prov` file beside the `.tgz`, and it is **opt-in**. Nothing forces a chart consumer to verify, and most repositories serve unsigned charts. - **Plugins.** Verification on install is **on by default**, and you must opt out. The reasoning is about blast radius rather than about signing being newly fashionable. A chart renders into manifests that the API server then evaluates, and whatever it creates is still subject to RBAC, admission and the namespace's constraints. A CLI plugin is an executable that runs on the operator's workstation or CI runner with that operator's credentials, kubeconfig and environment. The trust decision is simply larger, so Helm made the safe posture the default there and only there. ## Handling it in a migration The options, roughly in order of preference: 1. **Get a signed plugin.** If the plugin is yours, `helm plugin package --sign` is now part of its release process, and `helm plugin verify` is how you check the artefact before it ever reaches an image build. This is the option that makes the pipeline both green and better than it was. 2. **Opt out explicitly, in one place.** If the plugin is a third-party one with no signature, `--verify=false` in the image build is a deliberate, greppable exception rather than a silent one. Write it once, with a comment naming what it trusts and why. 3. **Remove the dependency.** Migration is a good moment to notice that a plugin installed for one command three years ago is a standing execution-trust decision in every pipeline that uses the image. ## Where this sits in the wider move It is a small, sharp instance of the general shape of the Helm 3 to Helm 4 move: **charts and releases are adopted in place, and what breaks is automation**. Releases keep their `sh.helm.release.v1.<name>.v<rev>` records, `apiVersion: v2` charts install untouched, and the command set is identical — so the work is a sweep of everything around Helm, of which plugin installation is one line in a Dockerfile. It also happens to be the only place in Helm where a signature check is on by default, which makes it a good differentiator question: knowing it signals someone who read the release notes rather than someone who upgraded and hoped. ## What a good answer sounds like "Plugin installs verify by default in Helm 4, so an unsigned plugin fails; the flag is `--verify=false`, and I would rather sign the plugin than pass it. It only shows up when the image is rebuilt, because an existing plugin directory — even one whose `plugin.yaml` predates the new format — still loads. And it is not a general Helm rule: chart signing with `helm package --sign` is still opt-in."