Goals (Expected user outcomes)

• The Quay operator can manage SSL certificates from Cert Manager without manual intervention, streamlining the certificate renewal process by allowing Cert-Manager to inject certificates into the Quay operator config Secret.

• Quay will automatically apply renewed certificates, eliminating the need for manual data copying, which in turn reduces downtime and operational overhead.

• The operator will be more GitOps-friendly by supporting the standard tls.crt and tls.key naming conventions and allowing a Secret reference, making configuration management easier.

Background (Why is this important?)

Customers are currently forced to manually copy ssl.key and ssl.cert values from a Cert-Manager Secret into the Quay config Secret.  This is a time-consuming, manual, and error-prone process that doesn't scale well.  Feedback from the customers, including Airbus, has highlighted the need for a more automated solution.  The proposed change aligns with the industry standard of using Cert-Manager and its injection functionality, which uses the well-known tls.crt and tls.key fields.  This change removes the need for custom scripts or manual steps, making the operator more robust and user-friendly.

Requirements (Acceptance criteria)

• Support Cert-Manager key naming: The Quay operator can read SSL certificate data from a Secret with the keys tls.crt and tls.key.

• Operator change detection: The operator actively monitors the referenced Secret for any changes to the certificate data.

• Automatic pod restart: Upon detecting an updated certificate in the Secret, the operator must automatically restart the Quay pods to apply the new certificate.

• Backward compatibility: The existing manual method of hardcoding ssl.key and ssl.cert values directly into the Quay config Secret continues to function for users who do not wish to adopt the new method.

• Configuration conflict handling: If both the legacy ssl.key/ssl.cert and the new tls.crt/tls.key fields are present in the configuration, the operator should fail with a clear error message.

Documentation considerations

• Update the Quay Operator doc: A new section in the official documentation explains the process of configuring the Quay operator to work with Cert-Manager in a step-by-step fashion.

• Provide a YAML example: Include a YAML manifest that showcases how to configure the Quay operator to reference a Kubernetes Secret for SSL certificates.

• Explain new configuration options: Explain the purpose and accepted values of the new fields in the Quay configuration schema for Cert-Manager support

• Describe the Operator's behavior: Describe how the operator detects changes to the referenced Secret and the resulting automatic pod restart.

• Call out backward compatibility: Explain that the existing method of hardcoding ssl.key/ssl.cert values will still be supported, ensuring a smoother transition and for users who are not yet ready to adopt the new method.

• Warn against configuration conflicts: Call out that using both the legacy ssl.key/ssl.cert and the new tls.crt/tls.key fields is not supported and will result in a configuration error.

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>