Repository navigation
Kubescape default binding names a rule ("Port forward") that its Rules object does not define #4978
Description
🤖 Generated by the Agentic Engineer (interactive Claude Code session)
Evidence
The pinned kubescape-operator chart (1.40.5) ships a default Rules object and a cluster-wide RuntimeRuleAlertBinding (all-rules-all-pods). Rendering both offline shows that the binding lists a rule named "Port forward", while the Rules object names that rule "Port forward to pod". Every other bound name matches a rule. The new switch regression (#4976) reports the mismatch as a note on every run.
Two rules in the Rules object are not bound at all: "Process tries to escape container" and "ld_preload hooks technique detected".
Problem and who it affects
Once the default rules are switched on (#4968), port-forwarding into a pod may raise no alert. The binding entry would match nothing, and nothing in the cluster reports a binding that names an unknown rule. The platform operator would then believe port-forward detection is active when it is not.
Hypothesis
If the node agent matches bindings by exact rule name, "Port forward" binds nothing, and port-forward detection stays off even with the switch on.
Success signal
After the switch is turned on, the node agent's rule sync and a deliberate kubectl port-forward against a test pod show whether the rule fires. Measure it in the same window as the #4968 read-back.
Smallest useful change
- Verify the node agent's matching (by name, rule ID or tag) against the shipped node-agent release.
- If the entry is unbound, bind the rule correctly in the platform (for example, a binding that also names "Port forward to pod"), and report the mismatch to the chart's maintainers.
Acceptance criteria
- The node agent's binding-match behaviour for rule names is established from its released source or a live read.
- Port-forward detection is shown to fire, or is bound so that it does, once the default rules are on.
- Whether the two unbound rules should be bound is decided and recorded.
Size: small. Part of #4968.
Activity
devantler commentedon Oct 25, 2026
First acceptance criterion established from the released source: a binding matches a rule by exact name, so "Port forward" binds nothing.
The node agent the platform runs is built from
kubescape/node-agentv0.3.219 (ghcr.io/devantler-tech/platform-kubescape-node-agent:v0.3.219-alerts.1-…). At that tag:pkg/rulebindingmanager/cache/cache.gocreateRuleresolves each binding entry byruleIDfirst, thenruleName, thenruleTags.pkg/rulemanager/rulecreator/factory.goCreateRuleByNamereturns the first rule whoseNameis exactly equal (==, case-sensitive) to the requested name, and otherwise an emptyRule{}, whichcreateRulestill appends.So the default
all-rules-all-podsentryruleName: "Port forward"resolves to an empty rule rather than to "Port forward to pod": port-forward detection stays off even once the default rules are switched on (#4968), and nothing reports it. (The-alerts.1platform build patches alert routing; this read assumes it leaves rule binding unchanged, which the next step can confirm against the patch.)Proposed next step (implementation, not done here): bind the rule correctly in the platform, preferably by its rule ID so a future rename cannot unbind it again, and decide in the same change whether "Process tries to escape container" and "ld_preload hooks technique detected" should be bound. Proof stays as the issue states: once #4968's switch is on, a deliberate
kubectl port-forwardagainst a test pod raises the alert.