2026 Feb 25

• We are splitting this effort into two
  • 1. Key exchange: this is tracked as part of the UBI-9 effort ROX-33132 . This topic is blocked on Postgres 15 - details below. We will deliver key exchange for everything else. Will be part of 4.11.
  • 2. Profile inheritance from the central mechanism: still blocked on the API (HPCASE-180 ) . This effort is now a stretch goal for 4.11 

What's the deal with PG ?

• PG 15 does not and will not support the key exchange
• This will be added for PG 16 (by the RHEL team ??)  and will require RHEL 10 
• We cannot use RHEL 10 yet b/c it does not support FIPS

2026-02-11:

• JP and crew introduced a new requirement for key exchange. They key exchange algorithm itself needs to be post quantum safe. This requires  UBI 9 for the built-in crypto libraries that it provides.
• They were late with the API, everyone has been complaining
• They reduced the priority , it is no longet blocking for 4.22 b/c some teams are not able to make it. However it is still highly desired. Basically asking the teams that if thaey can make it, continue as planned. Core products will push it into 4.22 patch cycle.
• OpenShift functionality might be Tech Preview because the picture will not be complete.
•  
• Bottom line - the impact is hightened dependency on UBI9. Michael to align with David House.
• Updated "New functional requirements" below for visibility

2026-02-04:

• What about overrides, do we allow local overrides in ACS compared to what Openshift gives us?
  • JP does not have a stance
  • Boaz: history teaches us, it will be required, we should have "a way"
  • Asking for Eng impact recommendation.
• How about visibility about the "sync state" with OCP and which profile was picked? Where would this be visible?
  • Boaz: Is required, but does not have to be in the UI. Having a way for customers/eng/support to verify is key.
• How do we configure ACS components?
  • Operator sets Env Vars in CR on the deployments
• Given the TLS profile setting is per OCP cluster, the question is how is this supposed to work for multicluster systems like ACS?
  • Do we want to show the information in ACS console as part of the cluster information
    • Should we log/capture the negotiated cipher between central and secured cluster components ?
    • Should we log/capture the settings that we follow (to indicate that we observe the OpenShift setting itself) 
  • Decision: All of this is a nice to have, when possible, eng please present impact / alternatives. Intuitively Vlad feels this is out of scope.
• Do we enforce only TLS server settings, or do we also enforce client side?
  • The question becomes more facetted when we mix "enforcing" and "non-enforcing" clusters
• Enforcement can only work on ACS driver servers, and between ACS components.
  • In particular, external services can potentially not offer the expected standards, but there is no enforcement expected there.
• What should we do for non OCP secured clusters?
  • Should we expose this setting ?
  • Decision: We will do nothing. This will behave like before.

Goal Summary:

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.

PARENT: OCPSTRAT-2611 - Centralized & enforced TLS configuration throughout OpenShift (Core & layered products)

DUE DATE:  Release blocker for OCP 4.22

Goals and expected user outcomes:

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:

• 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

Additional Functional Requirements

1. ACS shall have a fallback mechanism to override the external seting, in case the product breaks for some wrong configuration externally
2. Provide visibility about the "sync state" with OCP and the profile that was was picked
   1. Question: Where would this be visible?
   2. options
      1. operator log as MVP this is sufficient
      2. Environment variable related to each of the ACS deployments. You would see that in "oc describe" 
      3. Collecting this info in cluster info is better  (nice to have)

Success Criteria or KPIs measured:

A list of specific, measurable criteria that will be used to determine if the feature is successful. Include key performance indicators (KPIs) or other metrics., etc. Initial completion during __Refinement_ status._

[enter success criteria and/or KPIs here]

Additional Information:

Need Guidance?

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