Every deploy pipeline in your estate runs helm upgrade with a cluster-admin credential. How would you cut that back?

## Why this is an identity problem and not a Helm problem Helm has no in-cluster component and no privilege model of its own. A release is created by whoever ran the command, so "what can this pipeline break?" and "what does this credential permit?" are the same question. There is no mode to turn on, no policy file inside Helm, no per-chart sandbox. That is clarifying: every lever is either the identity you hand the runner, or the shape of the charts you install. ## Measure before you legislate The common failure is to announce least privilege and then spend a quarter debugging pipelines. Start by rendering: `helm template` every chart the estate installs, collect the distinct kinds, and split them into namespaced and cluster-scoped. Typically you find something like 40 charts of which 34 render nothing cluster-scoped, 4 carry only CRDs, and 2 are genuinely cluster-level software with webhooks and cluster-scoped identity objects. That inventory turns an intimidating programme into a small list of real exceptions, and it is derived from artefacts rather than from what teams believe their charts contain. Also measure the writes Helm makes on its own behalf — release records in each release namespace, plus `--create-namespace` where pipelines provision their own environments — because those are the requirements that make a carefully scoped identity fail on its first run. ## Tier the install paths The target shape is two or three paths, not one: - **Application path.** One deploy identity per team-namespace, permitted only what that team's charts render plus release storage in that namespace. A compromised runner reaches one namespace. This is where the overwhelming majority of installs live and it should be entirely self-service. - **Platform path.** Cluster-scoped charts — operators, CRD bundles, cluster-wide controllers — installed by a deliberately rare, reviewed path. Rare is the security property: a privileged capability used twice a month with change review is a different risk from the same power sitting in every pipeline. - **Bootstrap path.** The one-time installs of CRDs and cluster singletons, ideally retired to `--skip-crds` afterwards so the requirement does not recur. Where an in-cluster reconciler such as Argo CD or Flux already owns a chart, the pipeline should not be installing it at all; who that reconciler applies as is a separate design question, but the estate-level point is that a chart should have exactly one installer. ## Make chart shape a rule The long-term fix is authoring policy. In-house charts must be installable by a namespace-scoped identity: cluster-scoped objects either live in a separate platform chart or sit behind a values toggle that is off by default and can be pointed at a pre-existing identity by name. Names for any cluster-scoped object must include the namespace, because those objects share one namespace-free name space across the cluster and truncation to 63 characters makes collisions between similar release names entirely possible. Third-party charts are the hard case: many bundle CRDs, cluster-scoped identity objects and webhook configuration in one chart, and the only honest choices are to install them through the platform path, or to render them and split the output yourself — at the cost of owning that split at every version bump. ## Sequence the migration and be honest about cost Run both paths in parallel before switching. Give one team a scoped identity, let their pipeline fail in a non-production namespace, and fix the gaps — release storage, namespace creation, a CRD they had forgotten — before you touch anyone else. Expect to hit failures that appear weeks later rather than at cutover: the eleventh upgrade that must prune a release record at the default `--history-max` of 10, or the chart version that adds a CRD Helm will never install on upgrade. The costs are real and you should name them rather than discover them. Splitting charts means two-step installs with ordering to think about; upgrades to CRD schemas need the privileged path again; the platform team becomes a dependency for the exceptions; and a team that previously shipped anything now has a request queue for the rare cluster-scoped change. Weigh that against the alternative you have today, which is that any job on any runner can do anything to any cluster. ## Know when you are done Pick measurable statements rather than a feeling: how many identities can create cluster-scoped identity objects, how many pipelines can write outside their own namespace, how often the privileged path is used and whether each use has a reviewed change behind it. If the answer to the first two is a small, named, reviewed set and the third is a handful of audited runs a month, the programme has landed — even though a residual privileged path still exists, because it always will.