Uploaded image for project: 'Project Quay'
  1. Project Quay
  2. PROJQUAY-8801

Cert-manager support

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • cert-manager-support
    • False
    • Hide

      None

      Show
      None
    • 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)

      1. ...

      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>

              Unassigned Unassigned
              bcaton@redhat.com Brandon Caton
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: