fix(rbacgraph): order escalation results instead of reading map order - #3739

Overview

analyze_rbac_escalation_paths returns a differently-ordered result on every run against one unchanged cluster snapshot, so two scans of the same cluster never match and a report can't be diffed against a baseline.

Six places in core/pkg/rbacgraph read a Go map directly, and everything they yield reaches the report. targetNamespaces and knownNamespaces in escalation.go range over idx.serviceAccountsByNS to expand a cluster-wide grant into namespaces. matchingClusterRoles, matchingRoles and matchingRolesAnyNamespace range over idx.clusterRoles and idx.roles to find the roles a bind or escalate grant covers. escalateVerbEdges ranges over its escalateByScope map. FromResources in adapter.go ranges over the collected resource map, so even the slices that build the Index arrive shuffled. Map iteration order is randomized, so the edges come out in a different order each time, the BFS in closure.go discovers subjects in a different order, and Reached, EffectiveRules and Unbounded all end up ordered by chance.

Order also decides which findings survive. The search stops early once ClusterAdmin is confirmed, and again at maxEscalationHops, so on a large cluster a truncated result keeps a random subset of the paths rather than a stable one.

The fix sorts each of them: namespaces and scopes by name, roles by namespace/name, cluster roles by name, resources by resource ID. NewIndex also sorts the ServiceAccount names it collects per namespace, so an Index built directly is canonical whatever order its inputs arrived in. Which edges are found does not change, only the order they come out in.

This is what the rest of the repo already does where map iteration feeds output: dedupeServedVersionAliases in core/pkg/resourcehandler/k8sresources.go walks slices.Sorted(maps.Keys(allResources)), the related-location loop in core/pkg/resultshandling/printer/v2/sarifprinter.go sorts with the comment "map iteration order is randomized and this feeds directly into the written SARIF file", and groupByManifest in core/pkg/resultshandling/printer/v2/fixcache.go notes that sorting "makes the report order deterministic, which map iteration was not". rbacgraph is the newest of these packages and was missed.

How to Test

Three tests in core/pkg/rbacgraph/closure_test.go. Two run the analysis 25 times over one Index and compare the full ordering of every reached path and unbounded finding, and check the accessors return sorted lists; one does the same for FromResources. All three fail on master and pass with the change.

On master, with the tests applied and the source reverted:

$ git checkout master -- core/pkg/rbacgraph/adapter.go core/pkg/rbacgraph/escalation.go core/pkg/rbacgraph/index.go
$ go test -count=1 -run 'StableOrder|TestFromResources_ConvertsInResourceIDOrder' ./core/pkg/rbacgraph/...
--- FAIL: TestAnalyzeEscalation_ClusterWideGrantEnumeratesNamespacesInStableOrder
    closure_test.go:689: run 1 differs from run 0
--- FAIL: TestAnalyzeEscalation_BindableRolesAndClusterRolesAreEnumeratedInStableOrder
    closure_test.go:730: matchingClusterRoles = [kilo alfa binder zulu], want sorted by name
    closure_test.go:738: matchingRolesAnyNamespace = [prod/beta dev/zeta dev/alpha prod/mu], want sorted by namespace/name
--- FAIL: TestFromResources_ConvertsInResourceIDOrder
    closure_test.go:770: run 1 = [beta kilo zeta alpha mu], want [zeta alpha mu beta kilo] (same order every run)
FAIL

With the change:

$ go test -count=5 -race ./core/pkg/rbacgraph/...
ok  	github.com/kubescape/kubescape/v4/core/pkg/rbacgraph	2.227s

$ go test -count=1 -run 'RBAC|Escalation' ./cmd/mcpserver/
ok  	github.com/kubescape/kubescape/v4/cmd/mcpserver	8.314s

$ golangci-lint run --timeout 10m ./core/pkg/rbacgraph/...     # v2.12.2, the version CI pins
0 issues.

$ gofmt -l core/pkg/rbacgraph/     # no output
$ go vet ./core/pkg/rbacgraph/... ./cmd/mcpserver/...     # no output

TestRunWorkloadScan_AmbiguousInFile in cmd/mcpserver fails here with framework 'nsa' not found because this machine can't reach the policy service. It fails identically on unmodified master, so it is unrelated to this change.

Summary by CodeRabbit

• Bug Fixes

  • Improved consistency of RBAC escalation results by applying stable ordering to resources, namespaces, service accounts, roles, and escalation paths.
  • Ensured repeated analyses produce the same output regardless of input collection order.

• Tests

  • Added coverage verifying deterministic ordering across escalation analysis and resource conversion scenarios.