fix: resolve ClusterRole refs from RoleBindings - #1255
Conversation
Signed-off-by: lokesh0186 <lokesh0186@gmail.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Central YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 SummarySummary by CodeRabbit
WalkthroughThe access-to-resources template now resolves ClusterRoles referenced by RoleBindings. A test verifies detection of secret access through this binding type. ChangesRoleBinding ClusterRole resolution
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to RoleBindings that reference ClusterRoles now resolve those permissions correctly, with regression coverage for secret access detection. No current merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1255 +/- ##
===========================================
- Coverage 62.36% 31.35% -31.01%
===========================================
Files 197 239 +42
Lines 4854 6563 +1709
===========================================
- Hits 3027 2058 -969
- Misses 1439 4328 +2889
+ Partials 388 177 -211
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Summary
This updates the
access-to-resourcestemplate to followroleRef.kindwhen aRoleBindingreferences a role.Kubernetes permits a
RoleBindingto reference either aRolein the same namespace or a cluster-scopedClusterRole. The template currently sends everyRoleBindingthrough namespacedRolelookup, so the built-inaccess-to-secretsandaccess-to-create-podschecks can miss permissions granted throughRoleBinding -> ClusterRole.The change routes a
ClusterRolereference through the existing cluster-role lookup and adds a focused regression test. ExistingRoleBinding -> RoleandClusterRoleBinding -> ClusterRolebehavior is unchanged.Reproduction
I reproduced the gap with kube-linter v0.8.3 and current main at
ea3abb8abfe0fc4d7c2b20c9a30d95db9f0b2e2a:RoleBinding -> ClusterRolegrantinggeton Secrets: no report, exit 0RoleBinding -> Role:access-to-secretsreport, exit 1ClusterRoleBinding -> ClusterRole:access-to-secretsreport, exit 1The same routing gap also reproduces with
access-to-create-podswhen aRoleBindingreferences aClusterRolegrantingcreateon Pods.As an independent role-reference cross-check, public IaC-Guard-V 0.1.0b1 resolves the fixture's
RoleBindingto the cluster-scopedClusterRoleand reports the binding scope as consistent. IaC-Guard-V does not simulate authorization and is not used here as theaccess-to-secretsoracle.Validation
go test ./pkg/templates/accesstoresources -count=1make testBoth pass with the change.