fix(rbac): Replace hardcoded namespace: default with namespace: system

[RobuRishabh]

Purpose of this PR

The config/rbac/spark-application-rbac.yaml file hardcodes namespace: default in its ServiceAccount, Role, RoleBinding, and RoleBinding subjects. This locks deployments to the default namespace and prevents deployers from controlling the target namespace via Kustomize, Helm, or kubectl apply -n.

Proposed changes:

• Remove namespace: default from ServiceAccount metadata
• Remove namespace: default from Role metadata
• Remove namespace: default from RoleBinding metadata
• Remove namespace: default from RoleBinding subjects

Change Category

• Bugfix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that could affect existing functionality)
• Documentation update

Rationale

Hardcoding namespace: default breaks multi-tenant and custom-namespace installations. Base manifests should omit explicit namespace fields and let the deployer decide, which is the standard Kubernetes/kubebuilder convention.

Checklist

• I have conducted a self-review of my own code.
• I have updated documentation accordingly.
• I have added tests that prove my changes are effective or that my feature works.
• Existing unit tests pass locally with my changes.

[Copilot]

Pull request overview

Updates the Spark application RBAC manifest to follow kubebuilder/kustomize conventions by using namespace: system instead of hardcoding namespace: default.

Changes:

• Replace namespace: default with namespace: system in the ServiceAccount metadata.
• Replace namespace: default with namespace: system in the Role metadata.
• Replace namespace: default with namespace: system in the RoleBinding metadata and its ServiceAccount subject.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[nabuskey]

LGTM

[nabuskey]

Actually we should just remove explicit namespace references. Namespaces are typically specified in kustomization files, correct?

[RobuRishabh]

Actually we should just remove explicit namespace references. Namespaces are typically specified in kustomization files, correct?

@nabuskey Thanks for the review, I've updated the PR to remove the explicit namespace fields entirely instead of replacing them with system.

[nabuskey]

LGTM

[nabuskey]

LGTM

[vara-bonthu]

/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vara-bonthu

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [vara-bonthu]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment