Epic Goal

• Support id token from external provider to access apiserver from proxy

https://github.com/open-cluster-management-io/cluster-proxy/issues/103 

Why is this important?

• 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

Scenarios

1. ...

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>