-
Epic
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
cert-manager-support
-
False
-
-
False
-
Not Selected
-
To Do
-
100% To Do, 0% In Progress, 0% Done
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)
- ...
Previous Work (Optional):
- …
Open questions::
- …
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>