Security and Supply Chain

Hardening charts and their distribution path: chart signing and provenance, RBAC scoping, secrets management with helm-secrets and External Secrets, and scanning charts and images.

Overview

Three areas of Helm security

Helm security covers three distinct areas. Each one fails differently, so each needs its own controls.

Supply chain — The chart that reaches production is the one that was tested and signed
Runtime — RBAC scoping and least privilege for Helm operators and deployed workloads
Secrets management — Sensitive configuration stays out of plaintext YAML and Git

Supply chain: sign and verify

Charts should be signed at build time and verified at install or pull time, mirroring the broader container supply chain model. For OCI distribution, provenance files are uploaded as additional OCI layers.

GPG/PGP (helm package --sign) — Keys to generate, distribute and protect — Traditional
Sigstore via helm-sigstore — Keyless, OIDC-based, published to Rekor — Increasingly preferred: no key management

Runtime: RBAC scoping

Helm stores release metadata in Kubernetes Secrets, so Helm operators need Secret CRUD access, which is powerful. Every CI service account should be namespace-scoped to its target environment with the minimum permissions the chart requires.

> [!WARNING] Cluster-admin for a CI deploy account is a critical security misconfiguration.

Secrets management

Secrets in values files are the most common Helm security mistake. values-prod.yaml is committed to Git, so a password there leaves a permanent record in version control history.

External Secrets Operator — Reads from Secrets Manager or Vault and creates Kubernetes Secrets; the chart only references the Secret by name
SOPS + helm-secrets — Values are encrypted in the file, committed to Git and decrypted by CI
Sealed Secrets — Encrypted Kubernetes Secret CRDs that are safe to commit to Git

Key concepts

Provenance file (.prov): Generated by helm package --sign. Contains Chart.yaml, SHA256 checksum of the .tgz, and an OpenPGP signature. Proves integrity (not tampered) and authenticity (signed by the expected key). Uploaded automatically by helm push as an additional OCI layer.
Sigstore / helm-sigstore: Keyless signing alternative to GPG. The signer's OIDC identity (GitHub Actions JWT) is the key. Signatures are published to Rekor transparency log. No key management, no key rotation, public audit trail. Increasingly the preferred supply chain signing approach in 2026.
RBAC minimum for Helm CI: Namespace-scoped Role (not ClusterRole) with: Secrets get/list/create/update/delete (release tracking), plus verbs on each resource type the chart creates. Bound via RoleBinding to the CI ServiceAccount. Never cluster-admin; never cluster-wide Secret access.
External Secrets Operator (ESO): Kubernetes controller that syncs secrets from AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, or HashiCorp Vault into Kubernetes Secrets. The chart references the Kubernetes Secret by name; the secret value never appears in Helm values or Git. Cloud-native, GitOps-compatible.
helm-secrets + SOPS: Helm plugin that integrates with Mozilla SOPS. SOPS encrypts specific values in a YAML file using AWS KMS, GCP KMS, Azure Key Vault, or age/GPG keys. The encrypted file is committed to Git. At deploy time, the CI IAM role decrypts transparently: helm secrets upgrade ... -f secrets.yaml.
Trivy for Helm: trivy config ./mychart scans rendered Helm templates for security misconfigurations: root containers, missing securityContext, privileged containers, missing resource limits. trivy image scans the referenced container images for CVEs. Both modes integrate into CI as blocking checks.

When to use it

Signing charts: any chart distributed to external users or across organizational boundaries
RBAC review: before granting CI deploy permissions — always verify namespace-scope, never cluster-admin
Secrets audit: when onboarding a chart to production — check every values.yaml for plaintext secrets
CVE scanning: gate every chart/image on Trivy or Snyk scan results in the CI pipeline before push and before deploy

Interview questions

How do you sign a Helm chart and verify it at install time?
Describe three approaches to secrets management in Helm and their trade-offs.
What RBAC configuration does a Helm CI service account require, and why?
How do you scan a Helm chart for security misconfigurations in CI?
What are the supply chain security risks specific to using public Helm charts?
How does Helm 4's server-side apply affect security posture?