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

Separate client certificate trust from the global Hypershift CA

    XMLWordPrintable

Details

    • Hypershift client certificate trusts
    • False
    • None
    • False
    • Green
    • To Do
    • OCPSTRAT-591 - HyperShift Core Component Readiness for GA - Part I
    • Impediment
    • OCPSTRAT-591HyperShift Core Component Readiness for GA - Part I
    • 100
    • 100% 100%
    • Auth - Sprint 225, Auth - Sprint 226, Auth - Sprint 227, Auth - Sprint 230, Auth - Sprint 231, Auth - Sprint 232
    • Approved

    Description

      Epic Goal*

      The goal is to split client certificate trust chains from the global Hypershift root CA.

       
      Why is this important? (mandatory)

      This is important to:

      • assure a workload can be run on any kind of OCP flavor
      • reduce the blast radius in case of a sensitive material leak
      • separate trust to allow more granular control over client certificate authentication

       
      Scenarios (mandatory) 

      Provide details for user scenarios including actions to be performed, platform specifications, and user personas.  

      1. I would like to be able to run my workloads on any OpenShift-like platform.
        My workloads allow components to authenticate using client certificates based
        on a trust bundle that I am able to retrieve from the cluster.
      1. I don't want my users to have access to any CA bundle that would allow them
        to trust a random certificate from the cluster for client certificate authentication.

       
      Dependencies (internal and external) (mandatory)

      Hypershift team needs to provide us with code reviews and merge the changes we are to deliver

      Contributing Teams(and contacts) (mandatory) 

      • Development - OpenShift Auth, Hypershift
      • Documentation -OpenShift Auth Docs team
      • QE - OpenShift Auth QE
      • PX - I have no idea what PX is
      • Others - others

      Acceptance Criteria (optional)

      The serviceaccount CA bundle automatically injected to all pods cannot be used to authenticate any client certificate generated by the control-plane.

      Drawbacks or Risk (optional)

      Risk: there is a throbbing time pressure as this should be delivered before first stable Hypershift release

      Done - Checklist (mandatory)

      • CI Testing -  Basic e2e automationTests are merged and completing successfully
      • Documentation - Content development is complete.
      • QE - Test scenarios are written and executed successfully.
      • Technical Enablement - Slides are complete (if requested by PLM)
      • Engineering Stories Merged
      • All associated work items with the Epic are closed
      • Epic status should be “Release Pending” 

      Attachments

        Activity

          People

            slaznick@redhat.com Stanislav Laznicka
            slaznick@redhat.com Stanislav Laznicka
            He Liu He Liu
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: