fix: Add resourceclaims/binding RBAC for DRA granular status authorization

[praveen0raj]

Summary

• Add resourceclaims/binding with update and patch verbs to the binder ClusterRole
• Updated both the kubebuilder RBAC marker in source code and the auto-generated manifest

Why

Starting in Kubernetes v1.36, modifying status.allocation and status.reservedFor on a ResourceClaim requires additional permission on the synthetic resourceclaims/binding subresource. Without this change, KAI-Scheduler's binder will get 403 Forbidden when binding claims to nodes.

The existing resourceclaims/status permission is still required and kept as-is.

Files changed

• pkg/binder/controllers/bindrequest_controller.go — added +kubebuilder:rbac marker
• deployments/kai-scheduler/templates/rbac/binder.yaml — added generated RBAC rule

References

• Migrate DRA components to support granular authorization on status updates kubernetes/kubernetes#138149
• Fine-grained Authorization for ResourceClaim Status Updates kubernetes/kubernetes#134947
• KEP4817: add docs for granular authorization on DRA status kubernetes/website#55070

Test plan

• Deploy ClusterRole without fix → kubectl auth can-i update resourceclaims/binding returns no
• Deploy ClusterRole with fix → kubectl auth can-i update resourceclaims/binding returns yes
• Existing resourceclaims/status permission unchanged

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 65cb6d3f-b7c3-4cea-9edf-86a20f16ae6d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[enoodle]

@praveen0raj what would happen if we use this rbac on k8s v1.31 for example? Will it fail? Should we guard this with some "if k8s version is >=1.36"?

[github-actions]

Merging this branch will not change overall coverage

Impacted Packages	Coverage Δ	🤖
github.com/kai-scheduler/KAI-scheduler/pkg/binder/controllers	46.85% (ø)

---

Coverage by file

Changed files (no unit tests)

Changed File	Coverage Δ	Total	Covered	Missed	🤖
github.com/kai-scheduler/KAI-scheduler/pkg/binder/controllers/bindrequest_controller.go	67.68% (ø)	99	67	32

Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code.

[praveen0raj]

@enoodle

No, it won't fail, and no version guard is needed.

Kubernetes RBAC rules are declarative and permissive — a ClusterRole can reference resources that don't exist on the cluster. The API server simply ignores rules for unknown resources/subresources. It won't error when you apply the manifest, and it won't cause any runtime issues.

So on v1.31:

• The ClusterRole applies successfully with the extra rule
• The resourceclaims/binding rule is effectively a no-op (nothing checks it)
• All existing permissions work exactly as before

On v1.36+:

• The rule becomes active and grants the binder the new required permission

This is the same pattern used throughout the Kubernetes ecosystem — projects routinely ship RBAC for newer API features without version guards. Adding conditional logic would actually be worse: it would add Helm template complexity for zero practical benefit.

[enoodle]

@praveen0raj Thank you for explaining that.
Could you please sign-off on the commit and add a changelog line?

[praveen0raj]

@enoodle I have made changes. Thanks.