refactor: support multi-namespace operator deployments

[yalzhang]

Restructure RBAC to allow installing the operator in multiple namespaces simultaneously without conflicts.

• Move RBAC to standard Kustomize base/overlays structure

  • Base resources in config/rbac/base/
  • Platform overlays in config/rbac/overlays/{kind,openshift}

• Add namespace prefix to cluster-scoped bindings to prevent conflicts

  • ClusterRoleBindings: {namespace}-manager-rolebinding, {namespace}-metrics-auth-rolebinding
  • OpenShift SCC: {namespace}-trusted-cluster-scc

• Add PLATFORM variable (kind/openshift) to Makefile

• Consolidate kubebuilder RBAC markers in api/v1alpha1/crds.go

This enables running multiple operator instances without resource conflicts.

[yalzhang]

Test with the policies in #126, the result is as expected.
Run integration test on with kubevirt - PASS
Deploy the operator instance on 2 seperate namespaces on Azure openshift cluster, and scale a machine, the VM boot successfully - PASS (with PLATFORM=openshift)
Deploy the operator on kind cluster, and start a libvirt vm, the vm boot successfully - PASS

[alicefr]

@yalzhang one question, why the cluster role needs to be independent? I do understand that one change affects the entire cluster. However, it is similar for the TrustedExecutionCluster. Do we want to run test completely independent one from another? Theoretically, we do a single installation with the same RBAC and then run the tests

[yalzhang]

@yalzhang one question, why the cluster role needs to be independent? I do understand that one change affects the entire cluster. However, it is similar for the TrustedExecutionCluster. Do we want to run test completely independent one from another? Theoretically, we do a single installation with the same RBAC and then run the tests

My understanding is that this operator is intended to support multiple instances running in different namespaces, correct?
ClusterRoles are cluster-scoped resources, so they are shared and cannot have different names per namespace.
To avoid conflicts, I only updated the ClusterRoleBindings to be independent, for example: {namespace}-manager-rolebinding and {namespace}-metrics-auth-rolebinding.
The reason is that the ServiceAccount is namespaced, while the ClusterRole is cluster-scoped. A single ClusterRoleBinding binds the cluster-scoped ClusterRole to a namespaced ServiceAccount. For example:

1. trusted-cluster-operator-role is first bound to the ServiceAccount trusted-cluster-operator in namespace A.

2. When the operator is deployed again in namespace B, a ClusterRoleBinding with the same name is created and binds the same ClusterRole to the ServiceAccount in namespace B.

Because the ClusterRoleBinding name is reused, the binding for namespace A is overwritten, causing the operator instance in namespace A to break (for example, the register-server pod fails to start).

Another approach would be to modify the existing ClusterRoleBinding when deploying a second instance and append additional subjects, like:

$ oc get clusterrolebinding manager-rolebinding -o yaml 
.....
subjects:
- kind: ServiceAccount
  name: trusted-cluster-operator
  namespace: ns-A
- kind: ServiceAccount
  name: trusted-cluster-operator
  namespace: ns-B

However, this approach is more complicated to manage and maintain.

[alicefr]

I see, thanks for the explanation, makes totally sense

[alicefr]

do we need those?

[yalzhang]

Updated to be like below to make it minimum:

requiredDropCapabilities:
- ALL

[alicefr]

@yalzhang have you tried if make manifest and the integration tests work with the new directory? If yes, I'm fine with the changes, a part a last small question.

[openshift-ci]

@yalzhang: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/infra-provision-verify	6175a34	link	true	/test infra-provision-verify
ci/prow/operator-lifecycle-verify	6175a34	link	true	/test operator-lifecycle-verify

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[yalzhang]

@yalzhang have you tried if make manifest and the integration tests work with the new directory? If yes, I'm fine with the changes, a part a last small question.

Yes, for openshift, one more step 'export PLATFORM=openshift' before run 'make manifests'

[yalzhang]

Tested on openshift cluster with 2 namespaces, and on kind cluster, VMs can boot successfully. And run integration test locally pass.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: alicefr, yalzhang

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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