Uploaded image for project: 'OpenShift Authentication'
  1. OpenShift Authentication
  2. AUTH-364

Investigation spike for bring your own OIDC Auth provider feature

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Critical 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.  

      1. An automated solution the customer has that requires them to use tokens from their IDP to facilitate Client credential workflow 
      2. Seamless authentication to OpenShift and layered services such as ACS and ACM in a multi-cluster environment
      3. 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  

              slaznick@redhat.com Stanislav Láznička (Inactive)
              atelang@redhat.com Anjali Telang
              None
              Michal Fojtik (Inactive), Stanislav Láznička (Inactive)
              David Eads David Eads
              Stanislav Láznička Stanislav Láznička (Inactive)
              Giriyamma Karagere Ramaswamy Giriyamma Karagere Ramaswamy (Inactive)
              None
              Votes:
              0 Vote for this issue
              Watchers:
              16 Start watching this issue

                Created:
                Updated:
                Resolved: