Six posture exceptions in controller-rbac.yaml are structurally inert, and the migrated four have not gone to zero

[devantler]

🤖 Generated by the Agentic Engineer

Problem

k8s/bases/infrastructure/cluster-security-exceptions/controller-rbac.yaml suppresses six controls through a match.namespaceSelector. That file already documents why such a selector cannot suppress an RBAC-anchored finding, and says to migrate the six "if they surface failing objects".

They do — all six. Measured 2026-07-27 against admin@prod:

Control	Name	Failing objects	Anchored on an RBAC object	Cluster-scoped (empty namespace)
C-0053	Access container service account	155	100%	103
C-0037	CoreDNS poisoning	41	100%	30
C-0188	CIS-5.1.4 minimize access to create pods	20	100%	13
C-0031	Delete Kubernetes events	18	100%	14
C-0063	Portforwarding privileges	9	100%	5
C-0035	Access restriction to infrastructure — admin access	6	100%	5

249 (control, object) pairs over 156 unique objects. Zero are ordinary namespaced workloads; every one carries kubescape.io/rbac-resource: "true". So the namespaceSelector is not merely imprecise on these — it can never match any of them, and all six exceptions are inert while appearing configured.

(Object names are deliberately not listed. An enumeration of which bindings can reach service-account tokens or create pods is a weakness map; the aggregate counts and the anchor analysis are the sanitized minimum needed to review a fix.)

The trap in the data

The summaries are labelled kubescape.io/workload-kind: ServiceAccount with a populated workload-namespace, which makes a namespaceSelector look viable. But matching keys on the kubescape.io/wlid annotation, which reads wlid://cluster-prod/namespace-/clusterrolebinding-<name> — binding kind, empty namespace. Any migration must name ClusterRoleBinding/RoleBinding kinds, not ServiceAccount.

Also note for anyone re-measuring: the aggregated storage API returns spec-stripped objects on LIST — controls reads null and severities read all-zero across every item. Those numbers are only real when each object is fetched by name. A LIST-based sweep here reports a clean cluster.

What is NOT yet established — read before migrating

The four controls already migrated to explicit kind+name match.resources CRs have not gone to zero:

Migrated control	Still failing
C-0015 (list secrets)	70
C-0007 (delete-capable roles)	42
C-0002 (exec into container)	9
C-0187 (wildcard RBAC)	6

They are anchored the same way. This is not evidence the migration approach is broken — the residue may simply fall outside those CRs' named scope, which would be correct behaviour. But it does mean "migrate to kind+name" is currently an unproven remediation, and migrating six more controls on that assumption risks writing six more exceptions that also do not take effect.

Direction — measure before migrating

The first shippable step is verification, not a migration:

1. For one already-migrated control (C-0187 is smallest at 6), determine whether each still-failing object is inside or outside its CR's named scope. In-scope residue means the mechanism does not work and the whole approach needs rethinking; out-of-scope residue means it works and the CRs are simply incomplete.
2. Only then migrate the six, kinds named correctly per the wlid finding above.
3. Re-measure and record before/after counts per control.

Acceptance criteria

• The in-scope/out-of-scope question above is answered for at least one migrated control, with evidence
• Each of the six either has a working kind+name exception or a recorded reason it should stay flagged
• Before/after failing counts recorded per control, measured by per-object GET rather than LIST
• controller-rbac.yaml no longer carries exception entries that cannot match anything

Rough size: M. Step 1 is small and decides the shape of the rest.

Evidence freshness

Scanner proven alive rather than assumed: kubescape v4.0.10, scheduler CronJob last job Complete, newest summary objects written 2026-07-27T10:08–10:09Z, aggregate scan summary non-zero (212 high / 840 medium / 89 low), and 2206/2206 objects returned populated control maps on direct GET.

Related

• Remediate over-privileged secret readers C-0015 leaves flagged #2441 — raised this as a closing note; this issue is that note measured.

[coderabbitai]

🔗 Related PRs

#2316 - fix(kubescape): make ClusterSecurityException posture exceptions take effect [merged]
#2434 - fix(kubescape): except GitOps-managed CronJobs from C-0026 posture control [merged]
#2440 - fix(security): make C-0002 exec-into-container exception effective for infra controllers [merged]
#2442 - fix(kubescape): make C-0015 secret-list exceptions take effect [merged]
#2446 - fix(kubescape): except C-0007 delete-capable RBAC by object, not namespace [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[devantler]

🤖 Generated by the Agentic Engineer

Step 1 is done, and the result is NEGATIVE — kind+name matching is not working either

I ran the check this issue proposed as its first step: sweep all 2200 summaries by name, list every
object still failing C-0187, and ask whether each is inside or outside
wildcard-rbac-by-design's named scope.

All six failures, with their wlid anchors:

Failing anchor	Named in the CR?
clusterrolebinding-cluster-reconciler-flux-system (kustomize-controller)	✅ yes
clusterrolebinding-cluster-reconciler-flux-system (helm-controller)	✅ yes
clusterrolebinding-flux-operator	✅ yes
clusterrolebinding-velero-server	✅ yes
rolebinding-velero-server	⚠️ the CR names kind: Role, the finding anchors on the RoleBinding
clusterrolebinding-longhorn-support-bundle	❌ no — and deliberately so, per the CR's own comment

The CR declares four matchers. Five of the six failures are on objects it names, three of them by
exact kind and exact name (ClusterRoleBinding / cluster-reconciler-flux-system, flux-operator,
velero-server). They are still failing.

So the residue is not out-of-scope. It is almost entirely in-scope. That falsifies the assumption
behind this issue's proposed direction: migrating the other six controls to explicit kind+name
match.resources would not have suppressed anything, because that mechanism is not suppressing
anything today.

Corroborating signal

No object in the sweep carries subStatus: w-exceptions — the marker the operator is supposed to
write when it applies an exception at scan time. Combined with the above, the likeliest reading is
that ClusterSecurityException CRs are not being applied at scan time at all, rather than that
the match syntax is subtly wrong. Scanner is v4.0.10 and provably alive (scan completed, 2206/2206
objects carry populated control maps, aggregate non-zero).

The one genuinely suspicious matcher is the fifth row: the CR names kind: Role for
velero-server, but the finding anchors on the RoleBinding of that name. Worth fixing regardless,
but it cannot explain the three exact ClusterRoleBinding matches.

What this changes

The direction in the issue body is superseded. Migrating six more controls is now the wrong next
step — it would produce six more exceptions that do not take effect, which is exactly the state this
issue was opened to end.

Revised order:

1. Determine why an exact kind+name match is not suppressing C-0187. Candidates: the operator does not
   consume ClusterSecurityException for posture at all; the matcher schema differs from what these
   CRs use; or exceptions are applied at a layer these stored summaries bypass.
2. Fix the Role vs RoleBinding matcher for velero-server — cheap, and correct either way.
3. Only once (1) is answered, decide whether migrating the six is worth doing at all.

Knock-on for #2586

That issue asks whether the hand-maintained headlamp-exceptions ConfigMap can simply be deleted,
on the reasoning that with the scanner at ≥ v4.0.10 the operator applies the CRs at scan time and the
plugin renders the result. The absence of w-exceptions anywhere is evidence against that
premise. The mirror should not be deleted on the strength of the version alone.

[devantler]

🤖 Generated by the Agentic Engineer

Ran step 1 (the in-scope/out-of-scope question for a migrated control). The answer is that the
question cannot be answered from the surface this issue measures — and that finding invalidates the
evidence base for both halves of the issue, so it needs recording before any migration proceeds.

First, the method reproduces

Measured against admin@prod today, RBAC-anchored objects only, per-object GET as this issue
instructs (scanner proven alive first: 2164 summaries, scheduler job Complete 4h ago, kubescape +
node-agent pods Running):

Control	This issue (07-27)	Today
C-0015	70	70
C-0007	42	42
C-0002	9	9
C-0187	6	6
C-0053	155	156
C-0037 / C-0188 / C-0031 / C-0063 / C-0035	41 / 20 / 18 / 9 / 6	identical

So the numbers are reproducible and my read of the data matches yours.

The decisive finding: workloadconfigurationscansummaries is a PRE-exception surface

No ClusterSecurityException is reflected in it — neither a namespaceSelector one nor a kind+name
one. The discriminating control:

infrastructure-privileged suppresses C-0057 via a namespaceSelector naming longhorn-system and
observability. C-0057 is evaluated on namespaced workload kinds, so unlike the RBAC controls
that selector can match here — this is the case where a working exception must show. It does not:

Namespace	In that selector?	C-0057 in summaries
longhorn-system	yes	4 failed, 7 passed
observability	yes	1 failed, 10 passed
kyverno	no	0 failed, 5 passed

The exempted namespaces still carry failed. Stored summaries also expose only passed/failed —
there is no exception/skipped state in the schema at all.

Consequence: "the migrated four have not gone to zero" is expected, not evidence that
kind+name migration is broken. Nothing anyone writes in a CSE CR can move a count on this surface.
By the same token, this surface cannot show that the six controller-rbac.yaml entries are inert
either — a working and a broken exception look identical here. The structural argument about a
namespaceSelector never matching an empty-namespace wlid may still hold, but the counts in this
issue do not demonstrate it.

A second, independent finding — and it inverts this issue's "trap in the data" note

C-0187 is evaluated only on subject kinds, never on the RBAC object:

Kind carrying C-0187	Count
ServiceAccount	156 (150 passed, 6 failed)
Group	17 (all passed)
User	7 (all passed)
ClusterRoleBinding	0 of 182
ClusterRole / Role	0

The issue says "any migration must name ClusterRoleBinding/RoleBinding kinds, not
ServiceAccount", reasoning from the wlid string. But the wlid and the workload-kind label
disagree: the failing objects carry wlid://…/clusterrolebinding-<name> while their
kubescape.io/workload-kind is ServiceAccount. wildcard-rbac.yaml already names
ClusterRoleBinding + Role by exact name — the kinds that never carry this control at all.

Which of those two fields the scanner matches an exception against is now the open question, and
it decides how all six should be written. I did not guess it.

Revised direction

Step 1 as written cannot be executed. The replacement first step is to establish an oracle where
exceptions demonstrably bite before authoring any more of them:

1. Use the compliance-score / "excluding N controls" surface, and the CI path
   (scripts/generate-kubescape-exceptions → ksail workload scan --exceptions …), which is where
   this repo already has evidence exceptions apply — the ≈98.9% floor is measured with them.
2. With that oracle, determine whether the scanner matches on workload-kind or on the wlid kind.
3. Only then migrate the six, and re-measure on the oracle rather than on the summaries.

I have deliberately not touched controller-rbac.yaml this run: changing six exceptions while
the matching semantics are unknown is how six more inert entries get written, which is the exact
failure this issue exists to prevent.

(Object names withheld as before — an enumeration of which subjects hold wildcard or token-reaching
grants is a weakness map. Aggregate counts and the kind analysis are the sanitized minimum.)

[devantler]

🤖 Generated by the Agentic Engineer

Followed my own recommendation and built the oracle. It works — and it completes the answer, because
it shows the two surfaces evaluate different object populations, not just apply exceptions
differently.

The oracle discriminates

Ran the CI path locally (static, no cluster), identical command both times except the --exceptions
flag:

go run ./scripts/generate-kubescape-exceptions -o /tmp/kse.json     # 21 policies
ksail workload scan --framework nsa --compliance-threshold 0 --format sarif ...

Run	SARIF results
without --exceptions	71
with --exceptions	4

So exceptions demonstrably bite on the CI surface — 71 → 4 from one flag. That is the oracle this
issue needs, and it is cheap and offline.

But C-0187 is absent from that surface entirely

Per-control breakdown of the unexcepted run — the population before anything is suppressed:

39  C-0054      7  C-0034      2  C-0013      2  C-0271      1  C-0012
14  C-0030      3  C-0017      2  C-0270      1  C-0002

C-0187 does not appear at all, and neither do C-0053 / C-0037 / C-0188 / C-0031 / C-0063 /
C-0035 — the six this issue is about. A manifest scan has no live subject→role bindings to flag; the
ServiceAccount × ClusterRole × ClusterRoleBinding triples that carry these findings only exist in a
running cluster.

What that means — there are three surfaces, and the six controls appear on only one

Surface	Do exceptions apply?	Are these six controls evaluated?
CI manifest scan (ksail workload scan)	yes — proven 71→4	no — zero findings for any of them
In-cluster stored summaries	no — proven by the longhorn-system/observability control in my previous comment	yes — this is where the 249 pairs live
In-cluster compliance score / "excluding N controls"	claimed (needs scanner ≥ v4.0.10 + the supplemental RBAC this repo already added)	yes

So the six controls are only ever evaluated on the live cluster, and the only surface that could
show an exception working on them is the third one — which is precisely the one nobody has measured.
wildcard-rbac-by-design suppresses nothing in CI because there is nothing there to suppress; that
is not evidence it is broken, and my previous comment's kind analysis is not evidence it is correct
either. Both remain open against surface 3.

Revised acceptance criteria I'd propose

• Read surface 3 directly — the scanner's own "excluding N controls" / compliance output — and
  confirm it reflects the CRs at all. This is the gating step; nothing else can be judged
  without it.
• With that oracle, settle whether the scanner matches an exception on workload-kind
  (ServiceAccount) or on the wlid kind (ClusterRoleBinding) — they disagree for every one
  of these findings.
• Only then migrate the six, re-measuring on surface 3 rather than on stored summaries.
• Keep controller-rbac.yaml unchanged until the above resolves.

One observation, flagged not claimed

The excepted run printed All controls passed. No issues found while its SARIF carried 4 results
(3× C-0034, 1× C-0017, both low). That is probably a severity threshold in the CLI summary rather
than a gate defect — the gate reads the compliance score, not this line — but a run that prints
"no issues" over four real findings is worth a second look by someone who knows the scoring, so I am
recording it rather than acting on it.

Still no change to controller-rbac.yaml this run, for the reason in my previous comment.