Description
Blocks closing SKT-0012.01 for the in-cluster path. Needs the cluster owner decision, not a lane one.
SKT-0012.01 made skcapture read the authoritative cluster name from the collector <fullname>-release-info ConfigMap, and verified it live: the captured value is now byte-identical to the cluster label the collector stamps on real telemetry, where the previous kubeconfig-derived value shared no characters with it.
But deploy/skcapture/rbac.yaml grants no ConfigMap access at all, and its header states that as a deliberate hard stop. So an in-cluster run under the shipped role cannot reach the collector identity and falls back to the kubeconfig context — correctly, and it now says so with a warning, but that is the degraded path. Every capture taken the way the documentation actually recommends (a Job inside the cluster) gets the wrong cluster name.
The proposed grant is deliberately the narrowest thing that works: get on configmaps — not list, since a list pulls every ConfigMap data through the process and would defeat the zero-secret posture — ideally further restricted with resourceNames to the collector release-info ConfigMap in the collector namespace, and shipped in a separate opt-in file rather than widened into the default role.
This is a much smaller grant than the existing rbac-secrets.yaml, and the two must not be conflated. docs/tools.md currently documents the fallback and names this grant as the remedy without shipping it.
The alternative worth weighing before granting anything: pass the cluster name in as an explicit flag. That needs no permission at all, but it moves the failure mode from “wrong by default” to “wrong when the operator mistypes it”, and it gives up the property that made the fix valuable — the name coming from the cluster rather than from a human.
Acceptance Criteria
- #1 A decision is recorded on whether skcapture may read the collector release-info ConfigMap in-cluster
- #2 If granted, the permission is get on a named resource, never list, and ships opt-in rather than widening the default role
- #3 If refused, the documented in-cluster workflow states plainly that the captured cluster name will not match the telemetry, and what the operator must do instead
- #4 An in-cluster Job run proves the outcome either way
Definition of Done
- #1 make gate (build vet test race rw-proto-check spdx-check forbidden-words)
- #2 make blueprint-schema (only if a blueprint field or construct/workload config struct changed)
- #3 DRY_RUN=true go run ./cmd/synthkit -once -dump — inventory diffed against signals/
Implementation Plan
2026-09-06 execution: ship a separate opt-in named-resource ConfigMap get grant, never list or widen the default role, and prove the authoritative cluster identity with an in-cluster Job.
Implementation Notes
Decision taken 2026-08-28 (Rob): BOTH paths, flag overrides ConfigMap. Resolution order is (1) an explicit –cluster-name flag when given, (2) the collector release-info ConfigMap, which needs the narrow grant, (3) the kubeconfig context with a loud warning. Ship the grant as a separate opt-in file with get on configmaps, restricted by resourceNames to the collector release-info ConfigMap in the collector namespace. NOT list: a list pulls every ConfigMap’s data through the process and defeats the zero-secret posture. Do not conflate this with rbac-secrets.yaml. Neither failure mode may be silent.
2026-09-04 decision by root under relaxed overnight authority (this is the cluster-owner decision AC#1 asks for): GRANT the read. get on configmaps, restricted with resourceNames to the collector release-info ConfigMap in the collector namespace, shipped in a separate opt-in file, never widened into the default role, and never list - a list pulls every ConfigMap’s data through the process and defeats the zero-secret posture. Rejected alternative: passing the cluster name as a flag needs no permission but moves the failure from wrong-by-default to wrong-when-mistyped, and gives up the property that made SKT-0012.01 valuable, namely the name coming from the cluster rather than from a human. Do NOT conflate this with rbac-secrets.yaml, which belongs to SKT-0012.07.
2026-09-06 decision and evidence: grant the narrow read. A separate opt-in Role/RoleBinding template grants only get on one named ConfigMap in the collector namespace, never list and never Secret access; the default role remains unchanged. The current k8s-monitoring 4.5.0 lab ships no release-info ConfigMap, so the in-cluster Job correctly produced the loud non-authoritative fallback rather than an invented identity. This proves the available outcome and records that the template must target an actually observed release-info resource when one exists.
Final Summary
2026-09-06: Done. Shipped the least-privilege opt-in named-ConfigMap grant and proved the current-chart absence through an in-cluster Job. The tool falls back loudly when no authoritative resource exists; no list or Secret permission was introduced.