[Auth] Impersonation vs Direct User Tokens in In-Cluster Deployments

[benoit-bst]

Hello Radar team 👋,

My company and I are currently evaluating Radar and are particularly interested in the in-cluster deployment mode, which provides a great user experience, especially for users requiring read-write access.

We believe Radar is a fantastic product. The ability to offer a full Kubernetes UI directly in the browser, without any local setup, is a very compelling feature.
While reviewing the architecture, we had a few questions regarding the current authentication model, which relies on Kubernetes impersonation:

• What are the architectural reasons for using impersonation in the in-cluster deployment?
• What security benefits does impersonation provide compared to using the user's token directly?
• From a security perspective, how does impersonation affect the blast radius in the event of credential leakage?

These questions came up because we already have the ability to provide users' Kubernetes tokens directly and would ideally like to continue following that workflow.

Would you be open to exploring support for direct user token authentication as an alternative authentication mechanism? We'd be interested in understanding the trade-offs and whether this could fit into Radar's roadmap.

Thanks in advance for your insights, and congratulations on building such a great product!

[nadaverell]

Hi Benoit, first thank you so much for the kind words! Great to hear how much you appreciate Radar :)

To answer your questions:

Radar uses its own serviceaccount access to read and live-watch the Kubernetes API server stream of changes to all resources, and cache what it needs locally. A lot of features in Radar require walking the resource graph, searching across all resources of various types, across namespaces etc.

If we had to query everything needed in real time for each user, everything would be painfully slow.
If we had to cache separately for each user, it would overwhelm both radar and the k8s API server itself.

So, we invested a lot thinking about how to balance the product needs with security.

The high-level design:

• Writes and live operations use impersonation. Edit, delete, restart, scale and Helm actions, as well as exec, logs, port-forward and Helm release reads, all run as the user, so your existing RBAC decides.
• Reads from the cache are filtered per user with SubjectAccessReview. Most namespaced kinds are checked per namespace. Secrets, RBAC objects and all cluster-scoped kinds (Nodes, PVs, CRDs…) are checked per kind.
• Radar refuses to impersonate reserved system:* identities such as system:masters, so a spoofed header or a misconfigured IdP group can't be used to reach them.

The tradeoff with impersonation vs direct tokens:
Radar never holds your users' Kubernetes credentials. A session carries only the identity (username + groups). A leaked Radar session works only through Radar, and it expires with the session TTL (4h by default; OIDC back-channel logout is supported). A leaked bearer token, by contrast, works directly against the API server until it expires.
On the other hand, impersonation can't be limited to a subset of identities. So if Radar itself is compromised, when in auth=on mode (proxy or OIDC), an attacker might be able to impersonate any user or group. In that mode, you should treat Radar like other privileged in-cluster controllers. Limit direct access to it, isolate it (namespace, NetworkPolicies, ingress only through the proxy etc).
We do our best of course to follow security best practices to reduce risk. We're SOC 2 compliant, we keep Radar patched each week, we take measures to reduce chance of supply-chain attacks.

If this is problematic for you, we can discuss adding an option to replace impersonation with direct tokens (while keeping the primary read-path via the cache which relies on Radar's own SA, not impersonation - that as I explained is critical).
Perhaps it might be helpful to schedule a quick chat about your use case and see what it would take to support it? https://calendly.com/nadav-erell/radar-intro

[benoit-bst]

Thank you for the detailed explanation. I didn't fully catch the performance aspect initially, but I understand it much better now.

You also make a very good point regarding the security tradeoff. The statement that, if Radar itself is compromised the breach is here as others in-cluster controllers with high access. In that regard, treating Radar as a privileged in-cluster controller and protecting it accordingly seems like the right approach.

From my perspective, your arguments are currently convincing enough to consider the impersonation model acceptable. Before drawing a final conclusion, I'll discuss it with our security team to determine whether supporting direct user tokens is truly a requirement for us or simply a nice-to-have.

Thanks again for taking the time to provide such a thorough explanation. It was very helpful.
I will open also others discussions for various improvement ideas I have in mind.

[nadaverell]

Great to hear, happy to chat if you need any more info, you have the calendar link :)
The core Radar team comes from deep security and kubernetes backgrounds, this is important to us and we know it is for many users as well, and I appreciate you taking the time to understand it.