-
Story
-
Resolution: Done
-
Major
-
None
-
None
-
None
-
BU Product Work
-
False
-
None
-
False
-
OCPSTRAT-956 - Enable Break Glass access Mechanism for Cloud Services (ROSA as MVP)
-
-
-
Hypershift Sprint 249
-
0
-
0
-
0
Create a new short-lived signer CA that signs a cluster-admin kubeconfig we provide to the customer upon request.
The CA must be trusted by the KAS and included in the CA bundle along with the CA that will sign longer lived cert-based creds like those used by SRE.
TBD: should we create the signer at the point of kubeconfig request from the customer? Or should we always have the signer active through periodic rotation?
On-demand signer:
- Pro: the kubeconfig will be valid for the entire lifetime of the signer
- Con: we have to rollout the KAS deployment with the new signer which adds latency to the kubeconfig request from the customer. The signer generation will be fast so we could generate the kubeconfig quickly, but it wouldn't be reliably honored by the KAS until the rollout is complete (~10-15m)
Always valid signer with rotation:
- Pro: kubeconfig generation/publish is fast and near immediately honored by the KAS
- Con: the kubeconfig could be valid for a very short period of time if the signer is just about to rotate when the request for the kubeconfig is made
- blocks
-
HOSTEDCP-1257 Create controller for approving and issuing signed customer certs
- Closed
-
HOSTEDCP-1344 Create controller for rotating customer signer cert
- Closed
- is related to
-
OCPSTRAT-693 Implement Rotation Procedure for Hypershift Cluster CAs/Certs/Keys
- Refinement
- links to
- mentioned on