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.

This initiative 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.

FIX: 

• propose changes in upstream Velero main and cherry-pick to openshift Velero-1.18 or oadp-1.6 branches as we need this for OADP-1.6 and OCP 4.22