Pull模式agent与karmada-apiserver通信默认采用的是karmada-apiserver高权限凭据，因此在agent中会存放高权限凭据。此处能否出个最佳实践教导用户对权限进行控制。

[SHIRO-BAKO]

What happened:
当采用默认方式部署agent时，会在member集群中部署高权限karmada-apiserver凭据。

What you expected to happen:
出最佳实践配置指导用户低权限凭据agent与karmada-apiserver进行通信
How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• Karmada version:
• kubectl-karmada or karmadactl version (the result of kubectl-karmada version or karmadactl version):
• Others:

[XiShanYongYe-Chang]

I think this should not be considered a bug, let me update the label.
/kind question
/remove-kind bug

[everpeace]

I think this should not be considered a bug, let me update the label.

However, I think this is very important issue which should be fixed because karmada-agent registers privileged token and impersonate token in control plane. These token is very strong. Moreover, any agents can read those secrets without restriction.　(ref: ClusterRole/system:karmada:agent and its clusterrolebinding)

This means, any agents can get privilege access(even impersonate permission) to any member clusters. If network is reachable, it's dangerous. Moreover, any agent can update/delete very critical resources (Cluster, Works, Secrets, Lease, etc.) for other member clusters. In this situation, whole clusters(all the members, and control plane) would be taken by malicious attacker even if only one member cluster is compromised.

In ideal situation, in control plane, karmada-agents should be able to operate only resources which is associated to the agent.

Here is my idea, How about implementing webhook authorization mechanism in control plane which is similar to NodeRestriction admission controllersNodeAuthorization.

Say Cluster Authorization. This authorization prevents agent user (i.e. system:node:<cluster name> in control plane):

• can CRUD only own Cluster
• can CRUD only own cluster Secrets in karmada-cluster namespace
• can RU only Works in own execution space (karmada-es-<cluster name>)
• can CRUD only Leases associated to the agent
• etc.

Probably, we have to implement the mechanism by combining the authorization webhook and admission webhook like Node Authorization.

WDYT??

[XiShanYongYe-Chang]

WDYT??

Hi @everpeace thanks for your feedback. I think we should put this on the agenda. Are you interested in dealing with this issue?

[everpeace]

@XiShanYongYe-Chang Thanks for the quick reply.

Are you interested in dealing with this issue?

Sure, I'm glad to do this. Because I'm not full-time OSS engineer, I have limited bandwidth, though.

[XiShanYongYe-Chang]

Thank you, looking forward to your contribution. :)

[XiShanYongYe-Chang]

In favor of #4593.
/assign @everpeace

[zhzhuang-zju]

/close as completed
more info can refer to #5793

[RainbowMango]

/close