feat: option to skip impersonation review for proxy environments (teleport)

[oliverbaehler]

Describe the feature

When using impersonation, the proxy will create for each group an SubjectAccessReview. We can't batch this operation and therefor the more groups you are sending as Impersonation headers, the more requests are hitting the API. We have noticed, that this can make things slow (when people are working parallel some queries take like 20s). I have already proposed other features which help improve the situations by filtering out the groups which are necessary for impersonation and dropping others.

• feat(controller): add impersonation group filter options #375

However in this scenario we had, IMHO we could have just skipped that process. Take for reference how Teleport connects a cluster:

https://goteleport.com/docs/kubernetes-access/introduction/

What's essentially happening:

1. The Teleport Proxy sends all the user meta to the cluster agent (Teleport Kubernetes Service)
2. The Teleport Kubernetes Service has a ServiceAccount which can impersonate anything. In that case the origin Username and the groups given via Teleport policies are Impersonated from the Teleport Kubernetes Service.
3. Because the ServiceAccount can impersonate anything, any SubjectAccessReview will always be successful. And here arises my point, since the entire Teleport Stack already solves Authentication/Authorization the capsule-proxy just slows down the entire process. The capsule-proxy only needs to filter the requests essentially.

What would the new user story look like?

Add a new flag --skip-impersonation-review which is by default false. When setting true the impersonation properties for all the requests (user and groups) are not reviewed by the proxy through the Kubernetes API.

[maxgio92]

Hi @oliverbaehler, thank you, you've been clear and I see the point.

What I think is that the problem is real. However, disabking the subject access review for all the requests means to potentially permit a user to impersonate groups that could not otherwise, thanks to Capsule.

I don't have now in mind an alternative to propose, but as soon as I have one I certainly be back with it.

Just my 2 cents

[oliverbaehler]

@maxgio92 yes, that's actually the point. But in said specific scenario that's offloaded to teleport. Meaning teleport blocks the impersonation. It's a very niche feature, however has great performance impact.

But we have to be clear to the end users: It's an immense security risk if no other system in front handles authroization.

[prometherion]

But we have to be clear to the end users: It's an immense security risk if no other system in front handles authroization

I would highlight this very well in the description of the flag, and maybe even some very alerting messages in the logs.
Just avoid any L8 problem afterwards 🫠

edit: I thought I was on the PR addressing this, my bad