Support id token from external provider to access apiserver from proxy

[qiujian16]

Consider we have an open id provider (e.g. github), we need a way to use the id token from the provider to access multiple managed clusters if they use the same id provider.

/cc @yue9944882 @xuezhaojun

[tpouyer]

With IdPConfig we are able to configure Managed Cluster's OCP oauth config to connect to a central IDP server running on the hub cluster. The oauth config in OCP allows for browser based automatic login but does nothing for allowing the IDP issued token to be used when connecting to the Managed Cluster's kube api server. Effectively we are looking for a solution that would allow for a user to pass a bearer token populated with an IDP issued token on requests to a Managed Cluster's kube api server. On the Managed Cluster the reciever of the request would need to verify the authenticity of the bearer token with a pre-defined IDP server (configured on each Managed Cluster via either by custom config or utilizing the existing OCP oauth config). Once the bearer token has been verified and the user-info has been retrieved from the IDP server the reciever on the Managed cluster should lookup an existing user by the username provided by the IDP token in the OCP cluster. Once the user has been found the request should utilize user-impersonation to execute the request against the kube api server on the Managed Cluster and return the result to the user.

This is a good example of the functionality we are looking for:
https://www.jetstack.io/blog/kube-oidc-proxy/

Here is the existing code related to the article above:
https://github.com/jetstack/kube-oidc-proxy

[tpouyer]

I'm not yet convinced that this work needs to be integrated into the reverse proxy service. If the reverse proxy service is capable of calling multiple service end-points on the managed cluster then it would make more sense to create a new proxy service that would run on the Managed Clusters that the reverse proxy could target. That way a user could either use the reverse proxy and target the kube-oidc-proxy service on the Managed Cluster or they could target the kube-oidc-proxy service on the managed cluster directly without going through the reverse proxy. My only concern about forcing all communications through the reverse proxy would be the performance hit. Obviously if there is a firewall between the hub and the Managed Cluster then it would be necessary to go through the reverse proxy, otherwise the user may elect to communicate directly with the managed cluster via the kube-oidc-proxy service.