-
Feature
-
Resolution: Unresolved
-
Critical
-
None
-
None
-
Proactive Architecture
-
False
-
-
False
-
50% To Do, 0% In Progress, 50% Done
-
9
-
0
Problem & Overview
Currently, the existing procedure for full rotation of all cluster CAs/certs/keys is not suitable for Hypershift. Several oc helper commands added for this flow are not functional in Hypershift. Therefore, a separate and tailored procedure is required specifically for Hypershift post its General Availability (GA) stage.
Background
Most of the rotation procedure can be performed on the management side, given the decoupling between the control-plane and workers in the HyperShift architecture.
That said, it is important to ensure and assess the potential impacts on customers and guests during the rotation process, especially on how they affect SLOs and disruption budgets.
Why care?
- Additional Security: Regular rotation of cluster CAs/certs/keys is essential for maintaining a secure environment. Adapting the rotation procedure for Hypershift ensures that security measures align with its specific requirements and limitations.
- Compliance and Governance: Maintaining compliance(e.g., FIPS). Rotating certificates produced by non-compliant modules in Hypershift clusters is essential to align with FIPS requirements and mitigate future compliance risks...
- relates to
-
HOSTEDCP-457 Implement CA Certificate Rotation
- New
-
HOSTEDCP-1256 Create a short lived signer with rotation for signing customer certs
- Closed
-
OCPSTRAT-855 Ensure HyperShift Deployed Components Meet New Cert Handling Criteria
- Backlog