[bmscomp]

Why

A kates-platform install could still give the Kates API's ServiceAccount get, list and watch on every Secret in the cluster. The umbrella installs whatever sits in charts/kates-platform/charts/. That directory and Chart.lock are gitignored build output (.gitignore: charts/*/charts/, charts/*/*.lock), and Helm never checks those tarballs against the ranges in Chart.yaml. A charts/ left from an earlier helm dependency update kept installing kates 0.9.1, whose ClusterRole had the cluster-wide Secret rule that kates 0.10.8 (#287) dropped. The main checkout here still had it: kates 0.9.1, kafka-cluster 1.0.1, mirror-maker2 0.11.0, connect-cluster 2.1.1, locked 2026-09-20.

I checked this with Helm 4.3.0. With the kates range raised to >=0.10.8, the stale 0.9.1 tarball still passes helm template, helm lint and helm install --dry-run. Only helm dependency list says "wrong version". Raising the ranges alone protects nothing.

What changes

• Ranges: each floor is the version this umbrella was rendered and linted with: kafka-cluster >=1.0.10, kates >=0.11.6, apicurio-registry >=0.4.0, mirror-maker2 >=0.11.6, connect-cluster >=2.1.8. The upper bounds are unchanged.
• Guard: templates/subchart-versions.yaml renders nothing. It fails the render while charts/ holds an enabled subchart outside its range. The error names the subchart and the fix:

  charts/ holds kates 0.9.1, outside ">=0.11.6 <1.0.0" in Chart.yaml: run `make platform-chart-deps` (helm dependency update charts/kates-platform)
  

• CI: a new step in the Helm Lint job copies the umbrella, swaps its kates tarball for one packaged as 0.10.7 (the last chart that read every Secret), and expects that refusal.
• Chart 0.8.0, with two artifacthub.io/changes entries, both ACTION REQUIRED: rebuild charts/ before installing or upgrading; and the kates pass-through changes since 0.9.1 (kates.rbac.cdcSecretNamespaces for INTEGRATION_CDC; one pod, so replicaCount > 1, autoscaling, RollingUpdate and podDisruptionBudget.minAvailable are refused). The README documents the guard, the new ranges and kates.rbac.cdcSecretNamespaces. The README chart table and the book's version matrix are updated.

Values: the umbrella sets only kafka-cluster.profile: platform and the enabled flags. Both still map unchanged: kafka-cluster 1.0.10 still has profiles/platform.yaml. Diffing default values from 0.9.1 to 0.11.6, kates adds keys and removes only strategy.rollingUpdate.*, which the umbrella never set. kafka-cluster 1.0.1 to 1.0.10 only moves its tester image pins.

Checked locally

• A fresh make platform-chart-deps locks kates 0.11.6, kafka-cluster 1.0.10, mirror-maker2 0.11.6, connect-cluster 2.1.8 and apicurio-registry 0.4.0. helm template (release names p and kates-platform, defaults and every optional subchart enabled): the only ClusterRole is kates', and it has no secrets resource and no wildcard. The one secrets match is the chart's own comment, "No secrets: …". The same render from the old charts/ shows resources: ["secrets"] with get, list, watch.
• Guard: the old charts/ is refused, fresh deps render, and the old charts/ with the old ranges still renders. That last one is why the floors had to move.
• The new CI step, run verbatim: OK.
• helm lint + helm template over every chart, as in the CI loop: all pass. strimzi-operator needed its gitignored operator tarball built first, as CI does. scripts/gen-chart-table.sh --check, scripts/gen-version-matrix.sh --check, check-book-style.sh, check-book-contrast.py, check-mermaid.sh, make check-versions, make check-chart-tests, and actionlint on ci.yml: all pass.

Not run locally: kubeconform (not installed), and Helm 3.17.0, the CI version, which this PR's CI covers. .Subcharts and .Chart.Dependencies have been in Helm since 3.7.

Deliberately not done

• The main checkout's stale charts/kates-platform/charts/ is local, untracked output, so this PR can't change it. Once this merges, an install from it fails with the message above. Run make platform-chart-deps there to refresh it.
• The umbrella's Kafka namespace. The umbrella installs Kafka in its release namespace (the README uses -n kates). The kates defaults point at krafter-kafka-bootstrap.kafka.svc:9092, and the kates NetworkPolicy allows egress only to namespace kafka. 0.9.1 and 0.11.6 behave the same here, so this upgrade doesn't change it. Unless the release goes in kafka, Kates can't reach Kafka. That needs its own fix.
• rbac.scope=namespace (feat/rbac-namespace-scope, kates 0.12.0) isn't a dependency here. 0.12.0 satisfies >=0.11.6 <1.0.0.

Second commit: Go 1.27.3 (not this PR's regression)

Editing ci.yml runs the whole backend pipeline, and its Dependency CVE scan failed: govulncheck reports GO-2026-6809 (crypto/x509, reached through detect.RenderHTML) in Go 1.27.2, fixed in 1.27.3. The advisory came out after main's last green run, so every PR that runs the scan fails until the toolchain moves. 142e0ee changes cli/go.mod's toolchain line to go1.27.3 (the go 1.26.0 directive is unchanged). Locally on 1.27.3: govulncheck v1.7.0 finds nothing, go build ./... passes, and the version matrix check passes. The golang:1.27-alpine digests in kates/Dockerfile* are untouched.