Epic Goal

• ...

Why is this important?

• 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. And today, not all OpenShift components (Core or layered) obey central TLS configuration, leading to inconsistencies & lack of observance of custom TLS profiles defined by customers.

Scenarios

1. ...

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• The registry should have a new configuration parameter "tlsSecurityProfile", see https://access.redhat.com/documentation/en-us/openshift_container_platform/4.8/html/security_and_compliance/tls-security-profiles for reference
• The default value should be "modern"
• The operator can use the existing support for the REGISTRY_HTTP_TLS_CIPHERSUITES environment variable and set the ciphers there according to the chosen profile
• Specified ciphers in the modern profile should be used by registry server

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>