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

Support for Postgres client-side certs via the Operator

XMLWordPrintable

    • Support for Postgres client-side certs via the Operator
    • False
    • False
    • To Do
    • 0% To Do, 0% In Progress, 100% Done
    • undefined

      Epic Goal

      • Add support for certificate based authentication between Quay and Postgres.

      Why is this important?

      • Operator does not support deploying Quay with Postgres client-side certs. Certificate based authentication can be more secure and allow for easier automation.

      Scenarios

      1. A user is able to supply their own certificates that can be used for client-side authentication with PostGres
      2. The operator is able to configure this new mode of auth

      Acceptance Criteria

      • Quay can pick user-provided certificate files for authentication against Postgres databases
      • Quay deploys fine with GCP CloudSQL (using client side certs)
      • Users can deploy using client side certs through a custom config bundle
      • This is desireable but not required for the Clair Postgres database as well

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      1. Attempts were made to validate this behavior both through the UI as through a custom config bundle. For extra details please see history on https://issues.redhat.com/browse/PROJQUAY-2239
      2. Reach out to rhn-support-milang

      Open questions::

      1. There's an outstanding PR already, do we just need to review and test?

      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>

      Notes

      Generally this can be achived with a database connection string like this:

      DB_URI: postgresql://<username>@<hostname>:5432/<database>sslcert=/conf/stack/database.crt&sslkey=/conf/stack/database.key" 

      Engineering hints:

      • providing custom private keys is possible via the Operator-managed config bundle but the key files are injected into the Quay pod using projected volumes with a file permission mode of 0644
      • the Quay postgres connector library refuses to read private key files with 0644, it can only read them via 0600 if owned by the same user as Quay or 0640 if owned by root
      • because of OpenShifts randomized UID of container in pods Quay, the projected files are always owned by root but their group is set to the group id of Quay, so files readable by Quay need to be at least 0640
      • the config editor does not accept private key files when uploading into "extra CA certs" so manipulating the config bundle is currently the only way to get those files into the pod

              bcaton@redhat.com Brandon Caton
              rmarasch@redhat.com Ricardo Maraschini (Inactive)
              Eric Rich Eric Rich
              Votes:
              1 Vote for this issue
              Watchers:
              12 Start watching this issue

                Created:
                Updated:
                Resolved: