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.