Skip to content

cacert: a dotted HelmRelease name can land on another release's canonical projection name #4071

Description

Describe the bug
The CA-extraction controller publishes the trust anchor as <release>.tenant-ca. The dot keeps that name apart from every engine Secret <release><suffix> on the assumption that release names are dot-free. The apps API enforces that (release.prefix is ^[a-z0-9-]*$, application names are DNS-1035 labels). The controller, though, derives the release from the helm.toolkit.fluxcd.io/name label value (internal/controller/cacert/reconciler.go), and a label value may contain dots.

A hand-written HelmRelease named foo.tenant.tenant with an ordinary -ca suffix produces foo.tenant.tenant-ca, the canonical projection name of release foo.tenant. The adoption guard refuses to overwrite a Secret it does not own, so the outcome is a stuck projection, not a leak. The invariant is just not checked where the name is built.

Environment

  • Cozystack main, 2026-09-04

To Reproduce

  1. Create a HelmRelease foo.tenant.tenant in a tenant namespace whose chart writes a Secret <release>-ca
  2. Create a sentinel for release foo.tenant in the same namespace
  3. The projection for foo.tenant refuses its name because a foreign Secret occupies it

Expected behaviour
The controller refuses a derived release name containing a dot with its own Ready=False reason.

Actual behaviour
The dotted name is accepted. Tenants have no RBAC on HelmReleases, so this takes an operator, which bounds the severity.

Checklist

  • I have checked the documentation
  • I have searched for similar issues
  • I have included all required information
  • I have provided clear steps to reproduce
  • I have included relevant logs

Activity

  1. added
    kind/bugCategorizes issue or PR as related to a bug
    area/platformIssues or PRs related to platform infrastructure (bundle, flux, talos, installer)
    on Sep 3, 2026
  2. added
    triage/acceptedIndicates an issue is ready to be actively worked on
    priority/backlogGeneral backlog priority. Lower than priority/important-longterm
    and removed
    triage/needs-triageIndicates an issue needs triage by a maintainer
    on Sep 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/platformIssues or PRs related to platform infrastructure (bundle, flux, talos, installer)kind/bugCategorizes issue or PR as related to a bugpriority/backlogGeneral backlog priority. Lower than priority/important-longtermtriage/acceptedIndicates an issue is ready to be actively worked on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions