-
Epic
-
Resolution: Done
-
Critical
-
None
-
None
-
Investigation for BYO External OIDC Identity Provider for direct API Server access
-
Product / Portfolio Work
-
OCPSTRAT-306[TP] Support for bring your own external OIDC based Auth provider for direct API Server access [Standalone OCP]
-
0% To Do, 0% In Progress, 100% Done
-
False
-
None
-
False
-
None
-
None
-
None
Epic Goal*
The ability in OpenShift to create trust and directly consume access tokens issued by external OIDC Authentication Providers using an authentication approach similar to upstream Kubernetes.
Customers would like to enable automated workflows across multi-cloud environments where OpenShift/K8s and non-OpenShift clusters exist. There is a need to easily integrate their Identity provider to access OpenShift/K8s API using the access token provided by their IDP.
The Goal of this spike is to investigate the feasibility of solutions in OpenShift where such workflows are possible. Ideal solutions should minimize impact to RBAC, admission control policies or other workflows already supported on the Platform.
Non-Goal: Replacing OAuth Server.
Why is this important? (mandatory)
This is a priority for seamless authentication to OpenShift in Multi-cluster environments.
Scenarios (mandatory)
Provide details for user scenarios including actions to be performed, platform specifications, and user personas.
- An automated solution the customer has that requires them to use tokens from their IDP to facilitate Client credential workflow
- Seamless authentication to OpenShift and layered services such as ACS and ACM in a multi-cluster environment
- Ability to integrate with Backstage in a multi-cluster environment that interfaces with a single IDP such as Keycloak for federation.
Dependencies (internal and external) (mandatory)
N/A
Contributing Teams(and contacts) (mandatory)
Our expectation is that teams would modify the list below to fit the epic. Some epics may not need all the default groups but what is included here should accurately reflect who will be involved in delivering the epic.
- Development - For investigation spike, need Authentication mfojtik@redhat.com slaznick@redhat.com and team
- Documentation - N/A for investigation spike
- QE - N/A for investigation spike
- PX - N/A for investigation spike
- Others -
Acceptance Criteria (optional)
Provide some (testable) examples of how we will know if we have achieved the epic goal.
Drawbacks or Risk (optional)
Reasons we should consider NOT doing this such as: limited audience for the feature, feature will be superseded by other work that is planned, resulting feature will introduce substantial administrative complexity or user confusion, etc.
Done - Checklist (mandatory)
Results from Investigation are recorded and linked to https://issues.redhat.com/browse/OCPBU-542
