Auth - Sprint 225, Auth - Sprint 226, Auth - Sprint 227, Auth - Sprint 230, Auth - Sprint 231, Auth - Sprint 232
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
Provide details for user scenarios including actions to be performed, platform specifications, and user personas.
- 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.
- 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”