Feature Overview (aka. Goal Summary)  

An elevator pitch (value statement) that describes the Feature in a clear, concise way.  Complete during New status.

As an OpenShift Administrator, I need to ensure that I rotate signing keys for self-managed Openshift Azure Entra Workload ID enabled clusters to comply with PCI-DSS v4 (see #8 on life cycle management) and NIST (see PCI “Tokenization Product Security Guidelines”) rules.

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.

When creating a self-managed Openshift cluster on Azure using Azure Entra Workload ID, a dedicated OIDC endpoint is created. This endpoint exposes a document located at .well-known/openid_configuration which contains key jwks_uri, that points itself to JSON Web Key Sets.

Regular key rotations are an important part of PCI-DSS v4 and NIST rules. To ensure PCI-DSS V4 requirements, a mechanism is needed to seamlessly rotate signing keys. Currently, we can only have one signing/private key present in the OpenShift cluster; however, JWKS supports multiple public keys.

This feature will be split into 2 phases:

• Phase 1: document the feature.
• Phase 2 (post Phase 1): automate as much as we can of the feature to be informed by what's possible based on what we do in Phase 1 – this will be in a future OCPSTRAT (TBD).

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

<enter general Feature acceptance here>

Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

<your text here>

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

<your text here>

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

<your text here>

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

Related references

• Customer case : 03786147 

• Jira : RFE-6397 

Additional references

• Microsoft Entra Workload ID
• Configuring an Azure cluster to use short-term credentials
• What are managed identities for Azure resources?

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

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>