Hi Sig-Auth,
Our use case is that we want to manage kubevirt on multiple k8s clusters through a centralized control plane (a hub k8s cluster). A user on the centralized control plane can start/pause kubevirt based virtual machine, or access the console of the vm without needing to access the member clusters apiserver directly. At the same time, member cluster's apiserver should audit and control access of the request from the user.
To implement this
1. An agent is run on each member cluster as a deputy connecting to the control plane.
2. user request is first sent to the agent from the centralized control plane, and then the agent proxies the request to the apiserver.
3. agent's service account on the member cluster has the impersonate permission, so the agent can get user info from the request from the control plane and impersonate as the user on the apiserver of the member cluster.
The problem of the above flow is impersonate is too powerful that this agent can impersonate to any person which raises both security and audit problem.
Hence after discuss with @deads2k, we want to rethink of introducing acting-as which means
- when Bob acting-as Alice, the permission cannot exceed both Bob and Alice's permission.
And this will be more secure than impersonate, and make it more secure to set such permission to a service account. I think it will also benefit other use cases.
Regards
Qiu Jian