[RFE] Allow to override requests or token management

[joaquimrocha]

Recently, a plugin developer asked whether we could support having a global token that could be used for all clusters, as they access a lot of clusters with the same generated token and wanted to skip having to set it up to multiple clusters. They also wanted a way to maybe override the token setter/getter altogether, as this way they could check if the token is expired and refresh it before the request is made.

I think having a way to override the token functions could be interesting for plugins but also thought maybe we could go one level up and actually allow to override the whole request. This way, a plugin to set up a function to be used instead of the regular request, where the plugin can e.g. check for the token's expiration and refresh it if needed, store it in a location, and then call the normal request for things to be processed as usual.

I think this is not very trivial to accomplish but it's probably a good idea for plugins.

Discussion on this approach or alternatives are welcome.

[lijianzhi01]

Link to https://github.com/kinvolk/headlamp/issues/761

[lijianzhi01]

We definitely benefit from override token management.

Scenario Our app is based on Headlamp. We have our own logic get token and refresh it. So, we'd like to override get/setToken. Then, we can always get the latest token in time.

[joaquimrocha]

I was initially thinking that maybe instead of allowing the getToken to be overridden, we could allow the whole request to be overridden. The way that getting the token could be changed by overriding the request is that a plugin developer could define the request as: 1. First get a token in whatever way is required; 2. Call the regular request but pass the header options to include "Authorization..." (with the new token), so this makes the plugin fetched token be used instead of a default one.

While this request override may still be a useful thing in general, for now it's probably simpler and less compromising for the future to just override the getToken function.

[illume]

smaller surface

The benefit of allowing request replacement is complete flexibility. However maintenance and flexibility could benefit by only allowing token overriding. There's less of an API to maintain, and it'd be easier to change the request API later. What if we don't use HTTPS later for example? Having an explicit token API would make it easier to change things, than having a request API that's tied to HTTPS. Are there already known use cases that would benefit from changing the request?

Other auth methods?

I was wondering how other auth methods would be affected by this at all, and I remember an exercise from a kubernetes course I was doing where they set up auth in different ways.

It got me wondering further if we can achieve auth using some ways that kubernetes supports that Headlamp doesn't yet, and how these would be affected. What if we later added these other authentication methods (webhooks, authenticating proxy, etc)? Would our proposed plugin API for tokens/requests still be ok?

• our good friend kubectl supports webhooks which allow fetching a token from a service.

• authenticating proxy (with kubectl again). Allows putting a proxy in front of it which handles authentication, and then passes the user info in via headers.

[joaquimrocha]

After some discussion, it seems like it's a less compromising approach ATM to go with overriding getToken, so let's do it this way. (In the future we may override the request too)