minimize the rbac permissions for karmada-operator - #5586

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 40.53%. Comparing base (be571fb) to head (8b6d4c4).
⚠️ Report is 1620 commits behind head on master.
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@            Coverage Diff             @@
##           master    #5586      +/-   ##
==========================================
- Coverage   40.53%   40.53%   -0.01%     
==========================================
  Files         650      650              
  Lines       55184    55184              
==========================================
- Hits        22369    22367       -2     
- Misses      31383    31385       +2     
  Partials     1432     1432              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

/cc @zhzhuang-zju

/assign

@B1F030 I see that you have broken down the RBAC permissions for component karmada-operator, which is a good idea. Have you validated this locally? If so, could you tell me how you conducted the validation?

@B1F030 The karmada-operator has two installation methods: installation via Helm and installation from source code. What you are modifying now is the RBAC under the Helm installation method. When the RBAC for the Helm installation method is ready, it needs to be synchronized and modified in the source code as well. I will break down the work items in the issue #5182.

During my review, I found a method for local verification; you might also want to give it a try.

1. Set up the KUBECONFIG and CONTEXT.

$ export KUBECONFIG=~/.kube/xxxx.config
$ kubectl config use-context xxx

2. Modify the manifest of the karmada-operator to increase the log level.

# charts/karmada-operator/templates/karmada-operator-deployment.yaml
- --v=4

3. Install the karmada-operator by Helm.

$ helm install karmada-operator -n karmada-system --create-namespace --dependency-update ./charts/karmada-operator --set operator.image.tag=latest --debug

4. Deploy a Karmada instance through the karmada-operator.
5. The environment will have a ServiceAccount (sa), a ClusterRole, and a ClusterRoleBinding. The ClusterRole controls the RBAC permissions for the karmada-operator, and we need to validate by modifying the content of the ClusterRole.

$ kubectl get clusterrole
NAME                                                                   
karmada-operator  
$ kubectl get sa
karmada-operator 
$ kubectl get clusterrolebinding
karmada-operator 

6. modify clusterrole

$ kubectl get clusterrole karmada-operator --namespace karmada-system -oyaml > karmada-operator.yaml
$ vi karmada-operator.yaml
$ kubectl apply -f karmada-operator.yaml

# karmada-operator.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    meta.helm.sh/release-name: karmada-operator
    meta.helm.sh/release-namespace: karmada-system
  labels:
    app.kubernetes.io/instance: karmada-operator
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: karmada-operator
    helm.sh/chart: karmada-operator-0.0.1
  name: karmada-operator
rules:
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases # karmada-operator needs to use the Leases resource for leader election.
  verbs:
  - get
  - create
  - update

7. restart karmada-operator

$ kubectl rollout restart deployment/karmada-operator -nkarmada-system

8. Check the functionality of the karmada-operator through logs. If the logs indicate insufficient permissions, supplement the permissions for the relevant resources.
9. Repeat steps 6, 7, and 8 until the functionality is fully operational.

@B1F030 I am using the RBAC you set up to install the karmada-operator and to deploy karmada instances through the karmada-operator. The installation process gets stuck when installing karmada-etcd. Refer to

@B1F030 Could you please squash the commits?

@B1F030 Could you please squash the commits?

@RainbowMango Done.

/lgtm
@zhzhuang-zju Please take another look.

@B1F030 others LGTM

Using the one-click installation script provided by #5519 to install Karmada, the result is as follows:

$ kh get pods -ntest
NAME                                                    READY   STATUS    RESTARTS   AGE
karmada-demo-aggregated-apiserver-7f88d95ddb-w4csq      1/1     Running   0          4m45s
karmada-demo-apiserver-58b4c865bb-7fh9w                 1/1     Running   0          5m27s
karmada-demo-controller-manager-8ccff6859-qjfk9         1/1     Running   0          4m42s
karmada-demo-descheduler-c64fbb854-c52wn                1/1     Running   0          4m41s
karmada-demo-etcd-0                                     1/1     Running   0          6m14s
karmada-demo-kube-controller-manager-8585fb7bc4-7pqth   1/1     Running   0          4m42s
karmada-demo-metrics-adapter-66d696d574-t8nqs           1/1     Running   0          4m41s
karmada-demo-metrics-adapter-66d696d574-tsvlp           1/1     Running   0          4m41s
karmada-demo-scheduler-5479b4c9fc-qjb5w                 1/1     Running   0          4m42s
karmada-demo-search-78b6dd56c9-97nfv                    1/1     Running   0          4m38s
karmada-demo-webhook-7dd55448cb-4pjq4                   1/1     Running   0          4m41s

Passed the basic e2e tests

$ ./run-e2e-local.sh "[BasicPropagation] propagation testing deployment propagation testing"
Ran 3 of 239 Specs in 36.530 seconds
SUCCESS! -- 3 Passed | 0 Failed | 0 Pending | 236 Skipped

$ ./run-e2e-local.sh "priorityMatchName/priorityMatchLabel/priorityMatchAll propagation testing"
Ran 1 of 239 Specs in 177.398 seconds
SUCCESS! -- 1 Passed | 0 Failed | 0 Pending | 238 Skipped


Ginkgo ran 1 suite in 3m32.078400677s
Test Suite Passed

/lgtm
cc @RainbowMango

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RainbowMango

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

The pull request process is described here