Question
Helm v3 release history retention without configurable revision cap or pruning permissions
Zo Dey
0 reputation · 01 Aug 2025, 10:37 UTC
33.3K views
Loading…
0 reputation · 01 Aug 2025, 10:37 UTC
Helm v3 persists each release revision as a separate object in the configured storage backend, typically a Kubernetes Secret in the release namespace, and retains that history indefinitely by default with no built-in maximum revision enforcement. The helm uninstall command preserves revision history unless --no-keep-history is specified, yet the client does not provide a configurable revision cap or automatic pruning policy. Over time, long-lived clusters accumulate revision metadata that consumes storage quota and complicates audit trails.
Removing stale revision objects requires direct access to the storage namespace, which is frequently broader than the permissions intended for routine release operators. This leaves an unresolved boundary between managing live releases and cleaning up their historical metadata. The same ambiguity applies to automatic rollback during helm upgrade --atomic, where the initiating principal performs the rollback without a separate approval gate or permission check. Because storage backend limits and secret size constraints vary across Kubernetes distributions and Helm versions, the effective retention boundary should be confirmed against the target environment.
Which documented mechanism or external controller should enforce a revision retention limit for Helm v3 releases, and how can storage namespace access be scoped so that release operators may prune only their own release history without gaining broader cluster permissions? Should automatic rollback and hook execution privileges be separated from normal workload privileges through an admission policy or service account boundary?
34775 reputation · 01 Aug 2025, 15:46 UTC
Helm v3 does not include a built‑in revision cap or automatic pruning; it stores every release as a separate Secret (or ConfigMap) in the release namespace until manually removed.
No official Helm controller provides retention limits. The recommended approach is to run an external controller (e.g., a custom CronJob, a Helm Operator, or a third‑party Helm management service) that scans the release namespace, identifies old release objects by label or name, and deletes them only when they are not the currently active revision.
Create a dedicated ServiceAccount for release‑management tasks and bind it to a Role that permits delete on Secrets (or ConfigMaps) with a label such as owner=helm-release. Operators who run helm commands use their normal ServiceAccount and therefore cannot delete other releases. An admission webhook (Gatekeeper or Kyverno) can further restrict delete operations to resources whose labels match the operator’s release namespace, preventing broader cluster‑wide deletions.
Helm’s upgrade --atomic and hook pods inherit the caller’s identity, so rollback authority cannot be isolated with Helm alone. To enforce a boundary, run rollback and hook workloads in a separate pod that uses a dedicated ServiceAccount with a Role limited to the hook resources, and enforce the separation via a pod‑security‑admission policy or a namespace‑level admission webhook that only allows those pods to create or modify hook‑related resources.
helm
kuberneteshelm history <release> and list the Secrets in the release namespace to confirm unbounded growth.Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.