fix(rbac): grant spritz binding access

[onutc]

Summary

• let spritz-api manage SpritzBinding resources in tenant namespaces
• let the operator manage SpritzBinding resources and status/finalizers
• keep Helm RBAC and operator RBAC aligned

Validation

• helm template spritz /Users/onur/repos/spritz/helm/spritz --values /Users/onur/repos/platform-4/deploy/spritz/envs/staging/values.yaml --show-only templates/api-rbac.yaml --show-only templates/operator-rbac.yaml >/tmp/spritz-rbac-rendered.yaml && rg -n "spritzbindings|spritzbindings/status|spritzbindings/finalizers" /tmp/spritz-rbac-rendered.yaml

[gitrank-connector]

👍 GitRank PR Analysis

Score: 20 points

Metric	Value
Component	Other (1× multiplier)
Severity	P2 - Medium (20 base pts)
Final Score	20 × 1 = 20

Eligibility Checks

Check	Status
Issue/Bug Fix	✅
Fix Implementation	✅
PR Documented	✅
Tests	✅ (not required)
Lines Within Limit	✅

Impact Summary

This PR grants the spritz-api and operator proper RBAC permissions to manage SpritzBinding resources and their status/finalizers in tenant namespaces. The fix aligns Helm-based RBAC definitions with the operator's RBAC configuration, ensuring consistent permission models across deployment methods. Without these permissions, the services would fail to manage SpritzBinding resources despite being designed to do so.

Analysis Details

Component Classification: This PR modifies RBAC configuration files (Kubernetes Role and RoleBinding templates) which are infrastructure/configuration changes rather than feature-specific code. No specialized component category applies, so OTHER is appropriate.

Severity Justification: This is a P2 (Medium) severity fix addressing a functional gap in RBAC permissions. The spritz-api and operator lack proper access to SpritzBinding resources, which could cause operational failures or permission errors when managing these resources. However, it's not a critical security vulnerability or complete service outage, making it medium rather than high severity.

Eligibility Notes: The PR is fixing a reported RBAC permission gap (issue=true), the code changes directly implement the claimed fix (fix_implementation=true), and it has clear documentation with validation steps (pr_linked=true). No tests are included (tests=false), but tests are not required for this type of change since it's a configuration/RBAC update rather than business logic or API changes (tests_required=false). RBAC changes are typically validated through manual testing or integration tests rather than unit tests.

---

Analyzed by GitRank 🤖