Do not update this Epic/Tasks directly. The template should be cloned and applied to the onboarding of your component/operator

Cloning and Customizing the Template

⚠️ DO NOT update the original Epic/Tasks directly. The template must be cloned and applied to your specific operator's OLMv1 adoption.

1. Clone the Template: Go to the template issue, select 'More' from the top menu, and click 'Clone EPIC and Children' from the drop-down.
2. Locate and Customize: After cloning, find the new Epic (it will be linked under Issue Links - is cloned by on the original template page). Select the cloned Epic (e.g., "CLONE – [Operator/Component Name] Central TLS Profile consistency (Template)"). Immediately update the Summary, Epic Name, and *Description with your operator's specific information.

Moving the Cloned Epic and Tasks to Your Project

To begin work, you should move the Cloned Epic and all its child tasks to your own Jira Project using the Bulk Edit feature.

• Search for Issues: Use the Jira search bar to find the cloned Epic and all its sub-tasks. Replace your cloned Epic ID with the actual ID ( Eg. id in (PLMPGM-6492) OR id in childIssuesOf(PLMPGM-6492) order by Rank ASC).
  • id in (your cloned Epic ID) OR id in childIssuesOf(your cloned Epic ID) order by Rank ASC

• Start Bulk Change: Once the search results populate, go to Tools (on the top right corner)
  • Bulk Change All Tasks.

• Move the Issues:
  • Select Move Tasks.
  • Select your JIRA Project as the new destination.
  • Crucially, during the move process, associate all the tasks to the Epic Link (the cloned Epic you created in Part 1) to maintain the hierarchy.
  • Once you have Epic moved to your Jira project, please link it to OCPSTRAT-2553 (Please use Is Triggered by)

***************************************************************************************************************

Description:

Hardcoding TLS configuration creates a security vulnerability because it does not align with our evolving, centrally managed security policy for Post-Quantum Cryptography (PQC) readiness. It is necessary that TLS configurations throughout OpenShift & layered products are configured centrally.{}

Action Required:

This feature requires refactoring the component to dynamically inherit its TLS settings from the designated global configuration source, rather than managing them locally.

• We need to ensure OpenShift components use the correct TLS version and cipher suites to prepare for the pending PQC-readiness.
• PQC-resilient algorithms will be available only in TLS 1.3+.
• Components should obtain their TLS configuration information from the API Server, Kubelet configuration, or Ingress configuration, so that customers who want to opt into PQC-resilient ciphers can do so across the entire platform by adjusting, at most, three documented knobs. You should check:
  • API Server configuration - For components that should match the API server TLS profile (should be the default for most)
  • Kubelet configuration - For components running on nodes
  • Ingress configuration - For components serving ingress traffic
• You should ensure your component pulls its TLS configuration from one of the three knobs customers can adjust to comply with any custom TLS profiles they define. Experience has shown that not all customers use the default TLS profiles (Old, Intermediate, Modern…), but instead create custom TLS profiles by starting with a base profile and disabling algorithms their security team considers unsafe.
• This is a release blocker for OpenShift 4.22.

If you have questions or need help, please contact jjung@redhat.com , mpatel1@redhat.com,  lbragsta@redhat.com , rh-ee-shsmith , or rh-ee-nirichar  in #forum-ocp-tls-strict-obedience.

Layered OCP products:

Your solution should adhere to the cluster’s overall TLS configuration, so obtain the TLS configuration information from the API Server, Kubelet, or Ingress configuration. If you need a separate TLS configuration, please engage with us in #forum-ocp-tls-strict-obedience to explain your need.

Acceptance Criteria (Definition of Done):

• All local or hardcoded TLS configurations (protocols, ciphers, curves) have been removed from the solution codebase and deployment scripts
• The component has been updated to successfully fetch and apply the TLS policy from the central configuration source (API Server is the default, Kubelet, or Ingress configuration)
• A security re-scan using tls-scanner confirms the service endpoint is now fully compliant with the current global TLS policy
• The service remains stable, functional, and accessible to legitimate clients after the changes are deployed
• The component explicitly respects all TLS profile settings (does not rely on Go defaults)
• If using Semgrep to help detect code snippets, consider reviewing the results to identify any remaining hardcoded TLS configurations (note: false positives are common)
• Functional testing confirms the component accepts only permitted TLS profile settings (including when using a custom TLS profile)
• The component is set up for PQC readiness in one pass by properly adhering to all aspects of the configured TLS profile

Need Guidance?

The team assembled a technical guide with general guidelines and code samples. Start there!
Also check the Frequently asked questions.