Skip to content

Commit 34762b7

Browse files
stevsmitSteven Smith
andauthored
Starts postgresql SSL procedure (quay#1127)
Co-authored-by: Steven Smith <[email protected]>
1 parent 8bba4cd commit 34762b7

File tree

7 files changed

+150
-12
lines changed

7 files changed

+150
-12
lines changed

modules/arch-intro-security.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@
99
[id="arch-tls-ssl-config"]
1010
== TLS/SSL configuration
1111

12-
You can configure SSL/TLS for the {productname} registry in the configuration tool UI or in the configuration bundle. SSL/TSL connections to the database, to image storage, and to Redis can also be specified through the configuration tool.
12+
You can configure SSL/TLS for the {productname} registry in the configuration tool UI or in the configuration bundle. SSL/TLS connections to the database, to image storage, and to Redis can also be specified through the configuration tool.
1313

1414
Sensitive fields in the database and at run time are automatically encrypted. You can also require HTTPS and verify certificates for the {productname} registry during mirror operations.
1515

Lines changed: 116 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
1+
:_content-type: PROCEDURE
2+
[id="configuring-cert-based-auth-quay-sql"]
3+
= Configuring certificate-based authentication with SQL
4+
5+
The following procedure demonstrates how to connect {productname} with an SQL database using secure client-side certificates. This method ensures both connectivity and authentication through Certificate Trust Verification, as it verifies the SQL server's certificate against a trusted Certificate Authority (CA). This enhances the security of the connection between {productname} and your SQL server while simplifying automation for your deployment. Although the example uses Google Cloud Platform's CloudSQL, the procedure also applies to PostgreSQL and other supported databases.
6+
7+
.Prerequisites
8+
9+
* You have generated custom Certificate Authorities (CAs) and your SSL/TLS certificates and keys are available in `PEM` format that will be used to generate an SSL connection with your CloudSQL database. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/securing_red_hat_quay/index#ssl-tls-quay-overview[SSL and TLS for {productname}].
10+
* You have `base64 decoded` the original config bundle into a `config.yaml` file. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/deploying_the_red_hat_quay_operator_on_openshift_container_platform/index#operator-config-cli-download[Downloading the existing configuration].
11+
* You are using an externally managed PostgreSQL or CloudSQL database. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/deploying_the_red_hat_quay_operator_on_openshift_container_platform/index#operator-unmanaged-postgres[Using and existing PostgreSQL database] with the `DB_URI` variable set.
12+
* Your externally managed PostgreSQL or CloudSQL database is configured for SSL/TLS.
13+
* The `postgres` component of your `QuayRegistry` CRD is set to `managed: false`, and your CloudSQL database is set with the `DB_URI` configuration variable. The following procedure uses `postgresql://<cloudsql_username>:<dbpassword>@<database_host>:<port>/<database_name>`.
14+
15+
.Procedure
16+
17+
. After you have generated the CAs and SSL/TLS certificates and keys for your CloudSQL database and ensured that they are in `.pem` format, test the SSL connection to your CloudSQL server:
18+
19+
.. Initiate a connection to your CloudSQL server by entering the following command:
20+
+
21+
[source,terminal]
22+
----
23+
$ psql "sslmode=verify-ca sslrootcert=<ssl_server_certificate_authority>.pem sslcert=<ssl_client_certificate>.pem sslkey=<ssl_client_key>.pem hostaddr=<34.29.130.58> port=<5432> user=<cloudsql_username> dbname=<cloudsql_database_name>"
24+
----
25+
26+
. In your {productname} directory, create a new YAML file, for example, `quay-config-bundle.yaml`, by running the following command:
27+
+
28+
[source,terminal]
29+
----
30+
$ touch quay-config-bundle.yaml
31+
----
32+
33+
. Create a `postgresql-client-certs` resource by entering the following command:
34+
+
35+
[source,terminal]
36+
----
37+
$ oc -n <quay_namespace> create secret generic postgresql-client-certs \
38+
--from-file config.yaml=<path/to/config.yaml> <1>
39+
--from-file=tls.crt=<path/to/ssl_client_certificate.pem> <2>
40+
--from-file=tls.key=<path/to/ssl_client_key.pem> <3>
41+
--from-file=ca.crt=<path/to/ssl_server_certificate.pem> <4>
42+
----
43+
<1> Where` <config.yaml>` is your `base64 decoded` `config.yaml` file.
44+
<2> Where `ssl_client_certificate.pem` is your SSL certificate in `.pem` format.
45+
<3> Where `ssl_client_key.pem` is your SSL key in `.pem` format.
46+
<4> Where `ssl_server_certificate.pem` is your SSL root CA in `.pem` format.
47+
48+
. Edit your ``quay-config-bundle.yaml` file to include the following database connection settings:
49+
+
50+
[IMPORTANT]
51+
====
52+
* The information included in the `DB_CONNECTION_ARGS` variable, for example, `sslmode`, `sslrootcert`, `sslcert`, and `sslkey` *must* match the information appended to the `DB_URI` variable. Failure to match might result in a failed connection.
53+
* You cannot specify custom filenames or paths. Certificate file paths for `sslrootcert`, `sslcert`, and `sslkey` are hardcoded defaults and mounted into the `Quay` pod from the Kubernetes secret. You must adhere to the following naming conventions or it will result in a failed connection.
54+
====
55+
+
56+
[source,yaml]
57+
----
58+
DB_CONNECTION_ARGS:
59+
autorollback: true
60+
sslmode: verify-ca <1>
61+
sslrootcert: /.postgresql/root.crt <2>
62+
sslcert: /.postgresql/postgresql.crt <3>
63+
sslkey: /.postgresql/postgresql.key <4>
64+
threadlocals: true <5>
65+
DB_URI: postgresql://<dbusername>:<dbpassword>@<database_host>:<port>/<database_name>?sslmode=verify-full&sslrootcert=/.postgresql/root.crt&sslcert=/.postgresql/postgresql.crt&sslkey=/.postgresql/postgresql.key <6>
66+
----
67+
<1> Using `verify-ca` ensures that the database connection uses SSL/TLS and verifies the server certificate against a trusted CA. This can work with both trusted CA and self-signed CA certificates. However, this mode does not verify the hostname of the server. For full hostname and certificate verification, use `verify-full`. For more information about the configuration options available, see link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/configure_red_hat_quay/index#config-fields-postgres[PostgreSQL SSL/TLS connection arguments].
68+
<2> The `root.crt` file contains the root certificate used to verify the SSL/TLS connection with your CloudSQL database. This file is mounted in the `Quay` pod from the Kubernetes secret.
69+
<3> The `postgresql.crt` file contains the client certificate used to authenticate the connection to your CloudSQL database. This file is mounted in the `Quay` pod from the Kubernetes secret.
70+
<4> The `postgresql.key` file contains the private key associated with the client certificate. This file is mounted in the `Quay` pod from the Kubernetes secret.
71+
<5> Enables auto-rollback for connections.
72+
<6> The URI that accesses your CloudSQL database appended with your `root.crt`, `postgresql.crt`, and `postgresql.key` files. The SSL/TLS information included in `DB_URI` must match the information provided in `DB_CONNECTION_ARGS`. If you are using CloudSQL, you must include your database username and password in this variable.
73+
74+
. Create the `configBundleSecret` resource by entering the following command:
75+
+
76+
[source,terminal]
77+
----
78+
$ oc create -n <namespace> -f quay-config-bundle.yaml
79+
----
80+
+
81+
.Example output
82+
+
83+
[source,terminal]
84+
----
85+
secret/quay-config-bundle created
86+
----
87+
88+
. Update the `QuayRegistry` YAML file to reference the `quay-config-bundle` object by entering the following command:
89+
+
90+
[source,terminal]
91+
----
92+
$ oc patch quayregistry <registry_name> -n <namespace> --type=merge -p '{"spec":{"configBundleSecret":"quay-config-bundle"}}'
93+
----
94+
+
95+
.Example output
96+
+
97+
[source,terminal]
98+
----
99+
quayregistry.quay.redhat.com/example-registry patched
100+
----
101+
102+
. Ensure that your `QuayRegistry` YAML file has been updated to use the extra CA certificate `configBundleSecret` resource by entering the following command:
103+
+
104+
[source,terminal]
105+
----
106+
$ oc get quayregistry <registry_name> -n <namespace> -o yaml
107+
----
108+
+
109+
.Example output
110+
+
111+
[source,terminal]
112+
----
113+
# ...
114+
configBundleSecret: quay-config-bundle
115+
# ...
116+
----

modules/configuring-custom-clair-database.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ Use the following procedure to create a custom Clair database.
1212

1313
[NOTE]
1414
====
15-
The following procedure sets up Clair with SSL/TLS certifications. To view a similar procedure that does not set up Clair with SSL/TSL certifications, see "Configuring a custom Clair database with a managed Clair configuration".
15+
The following procedure sets up Clair with SSL/TLS certifications. To view a similar procedure that does not set up Clair with SSL/TLS certifications, see "Configuring a custom Clair database with a managed Clair configuration".
1616
====
1717

1818
.Procedure

modules/georepl-prereqs.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,7 @@
1818
+
1919
Geo-replication does not replicate the database. In the event of an outage, {productname} with geo-replication enabled will not failover to another database.
2020
21-
* A single Redis cache is shared across the entire {productname} setup and needs to accessible by all {productname} pods.
21+
* A single Redis cache is shared across the entire {productname} setup and needs to be accessible by all {productname} pods.
2222
2323
* The exact same configuration should be used across all regions, with exception of the storage backend, which can be configured explicitly using the `QUAY_DISTRIBUTED_STORAGE_PREFERENCE` environment variable.
2424

modules/rn_3_13_0.adoc

Lines changed: 18 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -9,21 +9,18 @@ The following sections detail _y_ and _z_ stream release information.
99

1010
Issued 2024-10-zz
1111

12-
{productname} release 3.13 is now available with Clair {clairproductminv}. The bug fixes that are included in the update are listed in the link:https://access.redhat.com/errata/RHBA-2024:XXXX[RHBA-2024:XXXX] advisory. For the most recent compatibility matrix, see link:https://access.redhat.com/articles/4067991[Quay Enterprise 3.x Tested Integrations].
13-
14-
[id="release-cadence-313"]
15-
== {productname} release cadence
16-
17-
With the release of {productname} 3.10, the product has begun to align its release cadence and lifecycle with {ocp}. As a result, {productname} releases are now generally available (GA) within approximately four weeks of the most recent version of {ocp}. Customers can not expect the support lifecycle phases of {productname} to align with {ocp} releases.
18-
19-
For more information, see the link:https://access.redhat.com/support/policy/updates/rhquay/[{productname} Life Cycle Policy].
12+
{productname} release 3.13 is now available with Clair {clairproductminv}. The bug fixes that are included in the update are listed in the link:https://access.redhat.com/errata/RHBA-2024:XXXX[RHBA-2024:XXXX] advisory. For the most recent compatibility matrix, see link:https://access.redhat.com/articles/4067991[Quay Enterprise 3.x Tested Integrations]. For information the release cadence of {productname}, see the link:https://access.redhat.com/support/policy/updates/rhquay/[{productname} Life Cycle Policy].
2013

2114
[id="documentation-changes-313"]
2215
== {productname} documentation changes
2316

2417
The following documentation changes have been made with the {productname} {producty} release:
2518

26-
*
19+
* The {productname} _Builders_ feature that was originally documented in the link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/use_red_hat_quay/index[Using {productname} guide] has been moved into a new, dedicated book titled "link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/builders_and_image_automation/index[Builders and image automation]".
20+
21+
* A new book titled "link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/securing_red_hat_quay/index[Securing {productname}]" has been created. This book covers SSL and TLS for {productname}, and adding additional certificate authorities (CAs) to your deployment. More content will be added to this book in the future.
22+
23+
* A new book titled "link:https://docs.redhat.com/en/documentation/red_hat_quay/3.13/html-single/managing_access_and_permissions/index[Managing access and permissions]" has been created. This book covers topics related to access controls, repository visibility, and robot accounts by using the UI and the API. More content will be added to this book in the future.
2724

2825
[id="new-features-and-enhancements-313"]
2926
== {productname} new features and enhancements
@@ -66,6 +63,18 @@ This feature greatly enhances the security of your {productname} registry by mit
6663

6764
For more information, see https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/manage_red_hat_quay/index#keyless-authentication-robot-accounts[Keyless authentication with robot accounts].
6865

66+
[id="quay-operator-updates-313"]
67+
== {productname-ocp} new features and enhancements
68+
69+
The following updates have been made to {productname-ocp}.
70+
71+
[id="certificate-based-auth-quay-postgresql"]
72+
=== Support for certificate-based authentication between {productname} and PostgreSQL
73+
74+
With this release, support for certificate-based authentication between {productname} and PostgreSQL has been added. This allows {productname} administrators to supply their own SSL/TLS certificates that can be used for client-side authentication with PostgreSQL or CloudSQL. This provides enhanced security and allows for easier automation for your {productname} registry.
75+
76+
For more information, see. . .
77+
6978
[id="v2-ui-enhancement"]
7079
=== {productname} v2 UI enhancements
7180

modules/ssl-tls-sql.adoc

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
:_content-type: PROCEDURE
2+
[id="cert-based-auth-quay-sql"]
3+
= Certificate-based authentication between {productname} and SQL
4+
5+
{productname} administrators can configure certificate-based authentication between {productname} and SQL (PostgreSQL and GCP CloudSQL) by supplying their own SSL/TLS certificates for client-side authentication. This provides enhanced security and allows for easier automation for your {productname} registry.
6+
7+
The following sections shows you how to configure certificate-based authentication between {productname} and PostgreSQL, and {productname} and CloudSQL.

securing_quay/master.adoc

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,12 @@ include::modules/ssl-trust-ca-system.adoc[leveloffset=+3]
2626
include::modules/operator-custom-ssl-certs-config-bundle.adoc[leveloffset=+2]
2727
include::modules/creating-custom-ssl-certs-config-bundle.adoc[leveloffset=+3]
2828

29+
//PostgreSQL SSL/TLS certificates
30+
include::modules/ssl-tls-sql.adoc[leveloffset=+1]
31+
include::modules/configuring-cert-based-auth-quay-sql.adoc[leveloffset=+2]
32+
include::modules/configuring-cert-based-auth-quay-cloudsql.adoc[leveloffset=+2]
33+
34+
2935
//additional ca certificates
3036
include::modules/config-extra-ca-certs-quay.adoc[leveloffset=+1]
3137
//Additional CA Certificates standalone

0 commit comments

Comments
 (0)