Feature Overview (aka. Goal Summary)

Enable OpenShift/HyperShift platform capabilities required for ARO-HCP clusters to implement secure OIDC signing keypair rotation and enforce maximum token expiration policies on customer service accounts, meeting Microsoft security requirements.

Goals (aka. expected user outcomes)

• ARO-HCP cluster administrators can rotate OIDC signing keypairs seamlessly without manual intervention
• ARO-HCP clusters automatically enforce maximum expiration times on all tokens minted from customer service accounts
• Clusters running OCP 4.19.x can participate in automated key rotation workflows
• Enhanced security posture through regular cryptographic key rotation and token lifetime controls

Requirements (aka. Acceptance Criteria):

OCP 4.19.x Compatibility (CNTRLPLANE-1372):

• kube-apiserver pods must restart automatically when sa-signing-key content changes in OCP 4.19.x
• Custom development solution required (backporting not feasible per platform team)
• Ensure ARO-HCP clusters running 4.19.z can support OIDC signing token rotation

Non-functional Requirements:

• Security: All cryptographic operations must follow industry best practices
• Reliability: Rotation operations must not disrupt running workloads
• Performance: Status monitoring must not impact cluster performance
• Maintainability: Solution must be supportable across OCP versions
• Scalability: Must work across large numbers of ARO-HCP clusters

Deployment considerations:

Use Cases (Optional):

1. Scheduled Key Rotation:

• CS initiates rotation by updating bound-service-account-signing-key
• HyperShift detects change and updates sa-signing-key automatically
• kube-apiserver pods restart with new key material

2. Token Expiration Enforcement:

• Customer creates service account in ARO-HCP cluster
• Tokens minted for this service account respect maximum expiration policy
• Existing long-lived tokens are handled gracefully during enforcement activation

Questions to Answer (Optional):

• How should existing long-lived tokens be handled when expiration enforcement is enabled?

Out of Scope

• Self-managed OpenShift clusters
• Classic (non-HCP) cluster architectures
• Automatic backporting to versions older than 4.19.x
• Customer-managed rotation schedules (platform-controlled)
• Integration with external certificate authorities

Background

This feature is essential for ARO-21644 (Cluster OIDC signing tokens rotation) implementation. Microsoft security requirements mandate regular rotation of cryptographic keys and enforcement of token expiration policies for ARO-HCP clusters. The current platform lacks automated rotation capabilities and reliable status feedback mechanisms.

This does the feature backport section of OCPSTRAT-2533

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

<your text here>

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

<your text here>

Interoperability Considerations

• Primary Impact: ARO-HCP (Azure Red Hat OpenShift Hosted Control
  Planes)
• Dependencies: HyperShift, OpenShift 4.19.x+,
• Test Scenarios:
  • Cross-version compatibility testing (4.19.x through latest)
  • Integration testing with Azure identity systems
  • Failover/recovery scenarios during rotation
  • Performance impact assessment on large-scale deployments