Use Cluster secret ref namespace in unified-auth-controller when generate ClusterRoleBinding

[XiShanYongYe-Chang]

Signed-off-by: changzhen changzhen5@huawei.com

What type of PR is this?

/kind bug

What this PR does / why we need it:

As talked in #2480 (comment) and #2495, we need to use cluster impersonate secret ref in unified-auth-controller when generating ClusterRoleBinding. As a result, we can access subCluster resources through the aggregate-apiserver when the cluster uses different namespaces to store secrets.

Which issue(s) this PR fixes:
Fixes #2495

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

karmada-controller-manager: use cluster secret ref namespace in unified-auth-controller when generate ClusterRoleBinding

[XiShanYongYe-Chang]

How to verify it?

• Create a kind cluster and join it to the karmada:

# create a kind cluster named cz01
kind create cluster --name cz01 --kubeconfig /root/.kube/cz01.config --image kindest/node:v1.23.4
# rename kind context
kubectl config rename-context "kind-cz01" "cz01" --kubeconfig /root/.kube/cz01.config
# Kind cluster uses `127.0.0.1` as kube-apiserver endpoint by default, thus kind clusters can't reach each other.
# So we need to update endpoint with container IP.
container_ip=$(docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' cz01-control-plane)
kubectl config set-cluster "kind-cz01" --server="https://${container_ip}:6443" --kubeconfig /root/.kube/cz01.config
# join cluster
karmadactl join cz01 --cluster-kubeconfig='/root/.kube/cz01.config' --cluster-namespace='cz01'

• Create serviceaccount zhangsan and grant permission to it:

kubectl create sa zhangsan
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: zhangsan
  annotations:
    kubernetes.io/service-account.name: zhangsan
type: kubernetes.io/service-account-token
EOF
kubectl apply -f zhangsan-rbac.yaml

unfold me to see the yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-proxy-clusterrole
rules:
- apiGroups:
  - 'cluster.karmada.io'
  resources:
  - clusters/proxy
  resourceNames:
  - member1
  - member2
  - cz01
  verbs:
  - '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-proxy-clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-proxy-clusterrole
subjects:
- kind: ServiceAccount
  name: zhangsan
  namespace: default
- kind: Group
  name: "system:serviceaccounts"
- kind: Group
  name: "system:serviceaccounts:default"

• execute the request, we can refer to here

[RainbowMango]

Do we have an E2E test to cover this feature?

[XiShanYongYe-Chang]

Do we have an E2E test to cover this feature?

Yes, but E2E didn't test this point.

[XiShanYongYe-Chang]

Add the related e2e test case.

[RainbowMango]

/lgtm
/approve

[XiShanYongYe-Chang]

/hold

[XiShanYongYe-Chang]

/hold cancel

I update the e2e test to fix the occasional errors: namespace not found in member cluster.

[RainbowMango]

/lgtm

[karmada-bot]

[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

Needs approval from an approver in each of these files:

• OWNERS [RainbowMango]

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

[RainbowMango]

Do we need to pick this patch for release-1.1?

[XiShanYongYe-Chang]

Do we need to pick this patch for release-1.1?

I have cherry-picked to release-1.1, need to wait for the ci pass.