Secrets and Supply-Chain Security

Secrets do not belong in values.yaml

Anything in values ends up in the release record (a Secret, but readable by anyone with access to Secrets in the namespace), in helm get values output, and often in Git. Keep real secrets out of values. Common patterns: reference an existing Secret by name (existingSecret: shop-db-credentials) created by another process; use the External Secrets Operator to sync secrets from AWS Secrets Manager, Azure Key Vault, Google Secret Manager or Vault; use Sealed Secrets (encrypted Secrets safe to commit); or encrypt values files with SOPS, for example through the helm-secrets plugin. For supply-chain safety, pin chart versions and dependency versions, prefer charts from the software's own maintainers, and verify integrity: Helm supports provenance files (helm package --sign, helm verify, --verify on install), and charts stored in OCI registries can be signed and verified with cosign. Review a third-party chart's rendered RBAC and security contexts before installing.

Referencing a secret instead of embedding it

The chart only knows the Secret's name; the value is managed elsewhere.

# values.yaml
database:
  existingSecret: shop-db-credentials   # created by External Secrets / Sealed Secrets
  passwordKey: password

# templates/deployment.yaml (container env)
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: {{ .Values.database.existingSecret }}
        key: {{ .Values.database.passwordKey }}

A safe deposit box number, not the jewels

The values file should contain the number of the safe deposit box, not the jewels themselves. Anyone can read the number; only the bank (the secret store) can open the box.

त्वरित जाँच: Why is putting a database password directly in a values file risky?

• Helm cannot render passwords
• It is stored in the release record and often committed to Git, visible to many people
• Kubernetes rejects plain-text values
• It makes the chart larger than the limit