Enable helm controller to detect and pick up hashed configmaps and secrets

[casibbald]

relates to #1163

@tbondarchuk @hiddeco

I have this working with static secret names (no hashing).

secretGenerator:
  - name: my-sops-secrets
    namespace: myapp
    envs:
      - files/application.secrets.env
configMapGenerator:
  - name: my-configmap
    namespace: myapp
    envs:
      - files/application.properties

  - name:my-helm-config
    namespace: myapp
    files:
      - values.yaml=helm/values.yaml

The problem arises when you try to use hashed secret names with:

generatorOptions:
  disableNameSuffixHash: true
  immutable: true

The reason for having a hash value is to trigger an update to the pods, forcing kube to restart them and pick up changes in the ConfigMap/Secrets.

[casibbald]

🔧 Feature Proposal: Support for Hashed ConfigMaps and Secrets in valuesFrom

📌 Problem Summary

Currently, HelmRelease.spec.valuesFrom only supports referencing ConfigMap and Secret resources by exact name. This is incompatible with common GitOps workflows that use Kustomize generators (e.g., secretGenerator, configMapGenerator) with disableNameSuffixHash: false, which creates hashed resources like my-config-2mh2t8m94h.

This leads to brittle workarounds:

• Kustomize nameReference patches
• Manual or scripted injection of generated names into HelmRelease
• Drift detection inconsistencies and upgrade triggers being missed

---

💡 Proposed Solution

Introduce a new optional field in HelmRelease.spec.valuesFrom:

valuesFrom:
  - kind: ConfigMap
    name: my-values
    hashed: true

When hashed: true is set:

• The Helm controller will resolve my-values-* (matching known hash suffix pattern) at reconcile time
• It will select the latest matching resource by creation timestamp
• The resolved resource will be used for values loading (like a regular valuesFrom)
• Watches will be extended to trigger HelmRelease reconciliations when new matching hashed resources appear
• If none are found, reconciliation fails (unless optional: true is also set)

---

✅ Benefits

• Works out-of-the-box with Kustomize generators
• No manual patching or name injection needed
• Triggers Helm upgrades on config/secret changes
• Keeps HelmReleases clean and declarative
• Backwards compatible (default behavior remains unchanged)

---

🔄 Example Use Case

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: podinfo
  namespace: default
spec:
  chart:
    spec:
      chart: podinfo
      sourceRef:
        kind: HelmRepository
        name: podinfo
  valuesFrom:
    - kind: ConfigMap
      name: podinfo-values  # Base name only
      hashed: true

Combined with:

configMapGenerator:
  - name: podinfo-values
    files:
      - values.yaml=values.yaml
generatorOptions:
  disableNameSuffixHash: false
  immutable: true

---

🧪 Implementation Notes

• Pattern match suffix: 10-character alphanumeric (default from Kustomize)
• Resource selection: latest creation timestamp
• Compatible kinds: ConfigMap, Secret only
• CRD/API update: hashed: boolean in ValuesReference
• Store resolved resource name in status (for observability/debugging)

---

📎 Related Issue

This proposal directly addresses [#1270](#1270), where many users request support for dynamic config name resolution with Kustomize.

[stefanprodan]

Helm values stored in ConfigMaps/Secrets no longer have to be hashed for helm-controller to detect changes and trigger an upgrade. Starting with Flux 2.7 you'll be able to use: fluxcd/flux2#5446

[casibbald]

Awesome @stefanprodan I will give the RC's a spin!