Repository navigation
Kubescape runtime detection loads no rules: the node agent checks nothing #4968
Description
🤖 Generated by the Agentic Engineer (interactive Claude Code session)
Expected Behavior
With runtime detection enabled, the Kubescape node agent loads its detection rules and their bindings. Suspicious runtime behaviour then raises an alert through the existing routing.
Actual Behavior
Read-only checks on 2026-10-16 show the node agent running and syncing, but with nothing to apply:
- Every rule sync reports
enabledRules: 0,totalRules: 0andruleBindings: 0. - The cluster holds no
Rulesobjects and noRuntimeRuleAlertBindingobjects. - Profiling still works, so application profiles and network neighbourhoods keep filling in. Detection is idle.
So "no runtime alerts" currently means "nothing is being checked", not "nothing suspicious happened". The alert routing is wired, but it has nothing to send.
The node agents' current pods started about three days ago. That matches the operator chart update to 1.40.5 (#4827, merged 2026-10-13). This is a correlation, not a confirmed cause: the issue is to establish whether that release moved the default rules and bindings behind a setting this platform does not set.
Steps to Replicate
- Read the node agent's log:
RulesWatcher - synced rules from clustershowsenabledRules: 0, totalRules: 0. - List
rules.kubescape.ioandruntimerulealertbindingscluster-wide: both are empty.
Acceptance Criteria
- Establish from the chart source at the pinned version how the default rules and bindings are installed, and why none exist here.
- Restore them declaratively, through chart values or a reviewed manifest, without widening what the agent may do.
- After deployment, read back non-zero enabled rules and bindings from the node agent's sync log.
- Add a check, in CI against the rendered chart or in the live-health probe, that fails when runtime detection is enabled with zero rules. That way this cannot go silent again.
Part of the Kubescape security programme #2447.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Effort
Projects
- Status
Activity
devantler commentedon Oct 16, 2026
Cause, from the chart source. I pulled
kubescape-operator1.40.4 and 1.40.5 from the chart repository and compared them:Rulesobject (default-rules, 28 rules) and the cluster-wideRuntimeRuleAlertBinding(all-rules-all-pods) only whenalertCRD.installDefaultis true.false.alertCRDat all.So the chart bump did not change the gate. The node agent reads its rules from these objects (
RulesWatcher - synced rules from cluster). None exist now, and nothing in this repository installs them.runtimeDetection: enableturns the agent on but gives it nothing to check. The 13 October date in the description is only when the current pods started. When detection actually stopped is not established: an earlier node-agent release that moved its rules into these objects is one possibility.The fix is one value, but it changes behaviour, so it needs a rollout plan. Setting
alertCRD.installDefault: truebinds all of the default rules to every pod outside the excluded namespaces. That includes anomaly rules such as Unexpected process launched, which depend on complete application profiles, and several current workloads have only partial ones. Turned on as is, it could flood the existing Slack route. A safe first slice, either:Then measure the alert volume before widening. Either slice also needs the zero-rules guard from the acceptance criteria, so detection cannot go silent again.
No production object was changed. This is diagnosis only.
devantler commentedon Oct 16, 2026
Root-cause read for the acceptance criterion "establish from the chart source at the pinned version how the default rules and bindings are installed", from the Kubescape operator chart (pulled from the chart repository, not from the cluster).
What installs the defaults. The chart renders the default
Rulesobject (default-rules) only whenalertCRD.installDefaultis true. It renders the defaultRuntimeRuleAlertBinding(all-rules-all-pods) only when that flag is true andalertCRD.scopeClusteredis true. The chart default forinstallDefaultisfalse.Why none exist here. The platform's Kubescape HelmRelease does not set
alertCRD.installDefault, so the chart renders neither object. Ahelm templateof the pinned chart confirms it: with the flag set, the render contains oneRulesand oneRuntimeRuleAlertBinding; without it, zero of each.Does the 1.40.5 bump explain it? Not by itself. The
installDefault: falsedefault is identical in 1.40.0 and 1.40.4 as well as 1.40.5, so this chart update did not move the gate. The platform has never set the flag in its own values, and nothing in the repository creates these objects. So the correlation with the 1.40.5 update is not the cause. I have not established how any rules were present before this node-agent generation, and I could not read that history from the cluster.Proposed fix (not started). Set
alertCRD.installDefault: truein the HelmRelease values, leavingscopeClusteredat its chart default of true. Expected effect: the node agent syncs the default rule set and binding, and alerts route through the existing Alertmanager, Slack and Coroot paths. Two of the default rules ship disabled. Expected cost, to be measured after deploy: more node-agent work and more alert volume, which the routing wiring has not been exercised against.Acceptance criteria still open: the deploy and read-back of non-zero rules and bindings, and the CI or live-health check that fails when detection is enabled with zero rules.
Platform's In Progress and In Review columns are not clear, so I am not starting the change this run. Expediting it needs a maintainer WIP decision.
chore: agent-claim #4968 nonce=1c788879e0fc086e6a9e3ab249147cf0
chore(security): approve the kubescape release's new surface entry
docs(runtime-security): say what the default-rules switch controls
devantler commentedon Oct 17, 2026
A follow-up for the rollout PR that turns the switch on. The review of #4976 found two wording nits in
scripts/tests/test-kubescape-runtime-rules-switch.sh, and neither changes what the test checks:on_problemsbinds$namesbut never uses it.They were not fixed in #4976 because a push would restart its full CI for two cosmetic edits. Fix both in the next PR that touches the script.