fix(security): pin the Kubescape relevancy capability instead of inheriting it by devantler · Pull Request #3881 · devantler-tech/platform

devantler · 2026-09-17T20:24:58Z

🤖 Generated by the Agentic Engineer

Why

Relevancy scanning is what makes our vulnerability reports actionable: the node agent watches which
libraries a container actually loads, so unreachable CVEs get marked not_affected instead of
competing for attention with the ones that matter. We rely on it — but we never asked for it. It is
on purely because the chart happens to default it on, so a future chart bump that flips that default
would switch a security capability off silently, with nothing in our config to notice or review.

What

Declares relevancy: enable in the Kubescape capabilities we pin, alongside the ones we already pin
there. No behaviour changes today — this makes the current state intentional and reviewable instead
of inherited, so it can only change deliberately.

Fixes #3707

…riting it Relevancy scanning feeds the reachable-CVE gate, but it was enabled only by chart 1.40.4's default. Declaring it makes a future default flip a visible, reviewable change rather than a silent loss of a security capability. Verified: chart 1.40.4 defaults relevancy=enable, so the rendered ks-capabilities ConfigMap is byte-identical with and without this pin; an ablation setting relevancy=disable does change it, confirming the render is sensitive to the value rather than ignoring it. Fixes #3707 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…vancy-pin-3707

…ancy pin Pinning the Kubescape relevancy capability moves the rendered authorization surface because a HelmRelease is a controller-RBAC emitter, even though the single added values line grants nothing. Conservation against main eea5453: 573 identities per side with identical sorted lists, exactly one differing rendered document (the kubescape HelmRelease), and 94 grant-bearing documents hashing byte-identically. Both results are controlled by a synthetic ClusterRole that changes each. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

devantler · 2026-09-17T23:23:14Z

🤖 Generated by the Agentic Engineer

@coderabbitai review

coderabbitai · 2026-09-17T23:23:28Z

@devantler I will review the changes in #3881.

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

coderabbitai · 2026-09-17T23:26:38Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Organization UI (inherited)

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 5140206d-6363-4342-9ba3-ba39451f6b63

📥 Commits

Reviewing files that changed from the base of the PR and between eea5453 and edee95c.

📒 Files selected for processing (2)

k8s/bases/infrastructure/controllers/kubescape/helm-release.yaml
scripts/validate-eks-ci-role-policy/main.go

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

📜 Recent review details

🔇 Additional comments (3)

k8s/bases/infrastructure/controllers/kubescape/helm-release.yaml (1)

56-63: LGTM!

scripts/validate-eks-ci-role-policy/main.go (2)

2605-2631: LGTM!

2644-2644: LGTM!

📝 Walkthrough

Walkthrough

The Kubescape HelmRelease now sets capabilities.relevancy explicitly to enable. Comments document the current chart default and the observed capability value. The EKS CI role-policy validator updates its approved rendered-surface fingerprints and records that the change comes from this values-line addition, with no grant-bearing identity, binding, service account, verb, wildcard, or AWS permission changes.

Priority: ⬇️ Low

Merge Risk: ⚪ Minimal · up to edee9

The change keeps Kubescape relevancy enabled and preserves the authorization approval checks, with no actionable merge-blocking risk identified.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Issue `#3707` requests Kubescape relevancy scanning. `k8s/bases/infrastructure/controllers/kubescape/helm-release.yaml` now sets `capabilities.relevancy: enable` for chart version 1.40.4. The change mak…
Out of Scope Changes check	✅ Passed	The changes are limited to the Kubescape capability pin and the required re-approval of the rendered authorization-surface fingerprint in `scripts/validate-eks-ci-role-policy/main.go`. The fingerprint…
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1…
Title check	✅ Passed	The title clearly and concisely describes the main change: explicitly pinning the Kubescape relevancy capability instead of inheriting the Helm chart default.
Description check	✅ Passed	The description directly explains why the relevancy capability is pinned, what configuration changes, and how the change preserves current behavior.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

devantler · 2026-09-17T23:28:37Z

🤖 Generated by the Agentic Engineer

Readiness at edee95c3b697d1c88cb05702ae5f1fb0fd29c616 — promoting.

Condition	Evidence
Programmatically tested	All required checks green, including `🔐 Validate Production Authorization` = SUCCESS. The re-approval carries a 573-identity conservation with two negative controls that both fired (a synthetic ClusterRole changes the grant hash and adds an identity), and the aggregate was read from CI's own approved renderer, not this host's unapproved one.
Reviewed	CodeRabbit at this exact head — auto-summary refreshed 23:26:38Z after the 23:23:13Z request, names the head, zero actionable finding sections (only the non-actionable `🔇 Additional comments (3)`), no rate-limit or did-not-run marker on the newest same-head reply. Threads 0/0, `fetched == totalCount`.
Tried and evaluated as a user	Live on the production cluster: `ks-capabilities` reads `relevancy=enable`, with 1133 `vulnerabilitymanifests` labelled `kubescape.io/context: filtered` against 235 non-filtered — i.e. relevancy is not merely configured, it is demonstrably producing the filtered verdicts that make CVE triage actionable. That is the behaviour this PR pins.

One thing I checked before promoting, because it would have failed in the queue

main moved twice after this branch's conservation was computed against eea5453d — #3880 (22:40Z) and #3884 (23:07Z). A retained aggregate is only valid while main has not moved, and #3884 touched k8s/bases/apps/fleetdm/helm-release.yaml, which sits under appsOverlayPath — one of the five authorizationOverlayPaths. On its face that stales previousRenderedSurfaceSHA.

It does not, and the proof is structural rather than a re-render:

chore(deps): update helm release fleet to v7.0.19 #3884 merged through the queue without touching scripts/validate-eks-ci-role-policy/main.go. The gate runs on merge_group whenever k8s changes, so had that merge moved the aggregate, chore(deps): update helm release fleet to v7.0.19 #3884's own gate would have failed. It passed.
Mechanism: fleetdm/ is commented out of k8s/bases/apps/kustomization.yaml ("fleetdm disabled 2026-06-03 — not in use"), so nothing under bases/apps/fleetdm/ is rendered at all. Changing that HelmRelease is inert to the authorization surface.

#3880 is separately inert here — it changed only .github/workflows/{ci,cd}.yaml and a test script, i.e. no manifests.

So both constants stand as written, and the merge-group gate re-evaluates against the real base regardless.

github-project-automation Bot added this to 🌊 Project Board Sep 17, 2026

github-project-automation Bot moved this to 🫴 Ready in 🌊 Project Board Sep 17, 2026

devantler and others added 2 commits September 18, 2026 00:01

Merge remote-tracking branch 'origin/main' into claude/kubescape-rele…

75a0308

…vancy-pin-3707

devantler mentioned this pull request Sep 17, 2026

fix(ci): run the authorization gate's diagnostics on a real mismatch #3880

Merged

devantler marked this pull request as ready for review September 17, 2026 23:28

devantler added this pull request to the merge queue Sep 17, 2026

Merged via the queue into main with commit d24dc41 Sep 17, 2026
30 checks passed

devantler deleted the claude/kubescape-relevancy-pin-3707 branch September 17, 2026 23:42

github-project-automation Bot moved this from 🫴 Ready to ✅ Done in 🌊 Project Board Sep 17, 2026

Navigation Menu

fix(security): pin the Kubescape relevancy capability instead of inheriting it - #3881

fix(security): pin the Kubescape relevancy capability instead of inheriting it#3881
devantler merged 3 commits into
mainfrom
claude/kubescape-relevancy-pin-3707

devantler commented Sep 17, 2026

Uh oh!

devantler commented Sep 17, 2026

Uh oh!

coderabbitai Bot commented Sep 17, 2026 •

edited

Loading

Uh oh!

coderabbitai Bot commented Sep 17, 2026 •

edited

Loading

Walkthrough

Uh oh!

devantler commented Sep 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

devantler commented Sep 17, 2026

Why

What

Uh oh!

devantler commented Sep 17, 2026

Uh oh!

coderabbitai Bot commented Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coderabbitai Bot commented Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Uh oh!

devantler commented Sep 17, 2026

One thing I checked before promoting, because it would have failed in the queue

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

coderabbitai Bot commented Sep 17, 2026 •

edited

Loading

coderabbitai Bot commented Sep 17, 2026 •

edited

Loading