Why does capsule-proxy need to use impersonation?

[zhangfane]

I’m trying to understand the design choice behind the use of impersonation in capsule-proxy.

From what I see, impersonation is used for all requests, including namespace-scoped resources like Pods, Deployments, etc. However, wouldn’t it be possible to just forward those requests directly to the Kubernetes API server, using the tenant user’s credentials or identity, and only apply impersonation or special handling for cluster-scoped resources?

In other words, why not treat namespace-scoped and cluster-scoped resources differently in the proxy layer, instead of applying impersonation universally?

It seems like direct passthrough (without impersonation) for namespace resources would work fine and reduce complexity.

[prometherion]

@zhangfane just moved to Discussion section since Issues are mostly used for bug reports.

Capsule Proxy supports two kind of auth mechanisms: TLS certificates, and Token based.

The latter is easy peasy: just read the token, and reuse that to transparently pass to the upstream API Server. With TLS certificates, instead, we need to terminate the TLS connection and read the peer certificates data, and we can't perform the same actions as we do with the bearer token.