Chapter 5. Red Hat Quay on OpenShift Container Platform configuration overview
When deploying Red Hat Quay on OpenShift Container Platform, the registry configuration is managed declaratively through two primary mechanisms: the QuayRegistry custom resource (CR) and the configBundleSecret resource. You use these mechanisms to configure and manage your registry deployment.
5.1. Understanding the QuayRegistry CR Copy linkLink copied to clipboard!
The QuayRegistry CR is used to determine whether a component is managed, or automatically handled by the Operator, or unmanaged, or provided externally by the user.
By default, the QuayRegistry CR contains the following key fields:
-
configBundleSecret: The name of a Kubernetes Secret containing theconfig.yamlfile which defines additional configuration parameters. -
name: The name of your Red Hat Quay registry. -
namespace: The namespace, or project, in which the registry was created. spec.components: A list of components that the Operator automatically manages. Each component entry includes the following fields:-
kind: The name of the component -
managed: A boolean that addresses whether the component lifecycle is handled by the Red Hat Quay Operator. Settingmanaged: trueto a component in theQuayRegistryCR means that the Operator manages the component. -
secretRef: Optional. For thetlscomponent only, references an externalkubernetes.io/tlsSecret whenmanagedisfalse. For more information, see Referencing an external TLS Secret for Red Hat Quay on OpenShift Container Platform.
-
All QuayRegistry components are automatically managed and auto-filled upon reconciliation for visibility unless specified otherwise. The following sections highlight the major QuayRegistry components and provide an example YAML file that shows the default settings.
5.2. Managed components Copy linkLink copied to clipboard!
Managed components are Red Hat Quay registry components that the Operator automatically configures and installs. By using managed components, you simplify deployment and reduce manual configuration tasks.
| Field | Type | Description |
|---|---|---|
|
| Boolean |
Holds overrides for deployment of Red Hat Quay on OpenShift Container Platform, such as environment variables and number of replicas. This component cannot be set to unmanaged ( |
|
| Boolean | Used for storing registry metadata. Currently, PostgreSQL version 13 is used. |
|
| Boolean |
Provides image vulnerability scanning. You can override ephemeral scratch storage for image layer extraction by using |
|
| Boolean | Stores live builder logs and the locking mechanism that is required for garbage collection. You can override CPU and memory resources for this component when it is managed. |
|
| Boolean |
Adjusts the number of |
|
| Boolean |
Stores image layer blobs. When set to |
|
| Boolean | Provides an external entrypoint to the Red Hat Quay registry from outside of OpenShift Container Platform. |
|
| Boolean | Configures repository mirror workers to support optional repository mirroring. |
|
| Boolean |
Features include a Grafana dashboard, access to individual metrics, and notifications for frequently restarting |
|
| Boolean |
Configures whether SSL/TLS is automatically handled. When |
|
| Boolean | Configures a managed Clair database. This is a separate database than the PostgreSQL database that is used to deploy Red Hat Quay. |
The following example shows you the default configuration for the QuayRegistry custom resource provided by the Red Hat Quay Operator. It is available on the OpenShift Container Platform web console.
apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
name: <example_registry>
namespace: <namespace>
spec:
configBundleSecret: config-bundle-secret
components:
- kind: quay
managed: true
- kind: postgres
managed: true
- kind: clair
managed: true
- kind: redis
managed: true
- kind: horizontalpodautoscaler
managed: true
- kind: objectstorage
managed: true
- kind: route
managed: true
- kind: mirror
managed: true
- kind: monitoring
managed: true
- kind: tls
managed: true
- kind: clairpostgres
managed: true
5.3. Referencing an external TLS Secret for Red Hat Quay on OpenShift Container Platform Copy linkLink copied to clipboard!
You can reference an external kubernetes.io/tls Secret from the tls component of the QuayRegistry custom resource (CR). The Red Hat Quay Operator uses the certificate and private key from that Secret instead of embedding ssl.cert and ssl.key files in the configBundleSecret resource. This approach supports automated certificate rotation from sources such as cert-manager, HashiCorp Vault, or manual Secret updates.
When you use an external TLS Secret, set spec.components[kind: tls].managed to false and specify secretRef. The Operator watches the referenced Secret and performs a rolling restart of Red Hat Quay pods when the certificate data changes.
-
secretRefis valid only when thetlscomponent is unmanaged (managed: false). -
Do not configure both
secretRefandssl.cert/ssl.keyfiles in theconfigBundleSecretresource. The Operator reports a conflict if both TLS sources are present. -
The certificate Subject Alternative Name (SAN) must include the hostname clients use to reach the registry. If the hostname does not match, the Operator can report
RolloutBlocked=Trueuntil the certificate is corrected. -
Existing deployments that use embedded
ssl.certandssl.keyfiles in the config bundle continue to work without changes.
Prerequisites
-
You have deployed the Red Hat Quay Operator and a
QuayRegistryCR. -
You have a TLS Secret of type
kubernetes.io/tlsin the same namespace as theQuayRegistry, withtls.crtandtls.keydata keys. - The certificate and private key are valid (format, key match, chain, and hostname).
Procedure
Create a TLS Secret in the registry namespace, for example:
apiVersion: v1 kind: Secret metadata: name: my-quay-tls namespace: <namespace> type: kubernetes.io/tls data: tls.crt: <base64_encoded_certificate> tls.key: <base64_encoded_private_key>Set the
tlscomponent to unmanaged and reference the Secret by entering the following command:$ oc patch quayregistry <registry_name> -n <namespace> --type=merge -p '{"spec":{"components":[{"kind":"tls","managed":false,"secretRef":{"name":"my-quay-tls"}}]}}'Verify that the
QuayRegistryCR contains the expected configuration:$ oc get quayregistry <registry_name> -n <namespace> -o yamlExample output
spec: components: - kind: tls managed: false secretRef: name: my-quay-tls- Wait for the Operator to reconcile the registry. When certificate data in the referenced Secret changes, the Operator triggers a rolling restart of Red Hat Quay pods to load the updated certificate.
Verify that TLS from the external Secret is ready by entering the following command. When the TLS component is healthy, the
ComponentTLSReadycondition reportsstatus: "True".$ oc wait quayregistry <registry_name> -n <namespace> --for=condition=ComponentTLSReady=True --timeout=300sYou can also review all component conditions in the OpenShift Container Platform web console on the QuayRegistry details page, or by entering
oc get quayregistry <registry_name> -n <namespace> -o yamland checkingstatus.conditions.
5.4. Modifying the QuayRegistry CR after deployment Copy linkLink copied to clipboard!
Modifying the QuayRegistry custom resource (CR) in Red Hat Quay after deployment lets you customize or reconfigure aspects of your Red Hat Quay environment.
Red Hat Quay administrators might modify the QuayRegistry CR for the following reasons:
-
To change component management: Switch components from
managed: truetomanaged: falsein order to bring your own infrastructure. For example, you might setkind: objectstorageto unmanaged to integrate external object storage platforms such as Google Cloud Storage or Nutanix. -
To apply custom configuration: Update or replace the
configBundleSecretto apply new configuration settings, for example, authentication providers, external SSL/TLS settings, feature flags. -
To enable or disable features: Toggle features like repository mirroring, Clair scanning, or horizontal pod autoscaling by modifying the
spec.componentslist. - To scale the deployment: Adjust environment variables or replica counts for the Quay application.
- To integrate with external services: Provide configuration for external PostgreSQL, Redis, or Clair databases, and update endpoints or credentials.
5.4.1. Modifying the QuayRegistry CR by using the OpenShift Container Platform web console Copy linkLink copied to clipboard!
To modify the QuayRegistry custom resource in Red Hat Quay, you can use the OpenShift Container Platform web console to change component management settings. You can set managed components to unmanaged and use your own infrastructure.
Prerequisites
- You are logged into OpenShift Container Platform as a user with admin privileges.
- You have installed the Red Hat Quay Operator.
Procedure
-
On the OpenShift Container Platform web console, click Operators
Installed Operators. - Click Red Hat Quay.
- Click Quay Registry.
- Click the name of your Red Hat Quay registry, for example, example-registry.
- Click YAML.
-
Adjust the
managedfield of the desired component to eitherTrueorFalse. Click Save.
NoteSetting a component to unmanaged (
managed: false) might require additional configuration. For more information about setting unmanaged components in theQuayRegistryCR, see Using unmanaged components for dependencies.
5.4.2. Modifying the QuayRegistry CR by using the CLI Copy linkLink copied to clipboard!
To modify the QuayRegistry custom resource in Red Hat Quay, you can use the CLI to change component management settings. You can set managed components to unmanaged and use your own infrastructure.
Prerequisites
- You are logged in to your OpenShift Container Platform cluster as a user with admin privileges.
Procedure
Edit the
QuayRegistryCR by entering the following command:$ oc edit quayregistry <registry_name> -n <namespace>Make the desired changes to the
QuayRegistryCR.NoteSetting a component to unmanaged (
managed: false) might require additional configuration. For more information about setting unmanaged components in theQuayRegistryCR, see Using unmanaged components for dependencies.- Save the changes.
5.4.3. Understanding the configBundleSecret Copy linkLink copied to clipboard!
The configBundleSecret is a Kubernetes Secret that stores the config.yaml file for Red Hat Quay. You use this secret to configure authentication backends, feature flags, TLS settings, and other registry parameters that the Operator merges with managed component settings.
Red Hat Quay administrators might update this secret for the following reasons:
- Enable a new authentication method
- Add custom SSL/TLS certificates
- Enable features
- Modify security scanning settings
If this field is omitted, the Red Hat Quay Operator automatically generates a configuration secret based on default values and managed component settings. If you provide this field, Red Hat Quay uses the config.yaml contents as the base configuration and merges them with values from managed components to form the final configuration, which is mounted into the quay application pods.
How the QuayRegistry CR is configured determines which fields must be included in the configBundleSecret’s `config.yaml file for Red Hat Quay on OpenShift Container Platform. The following example shows you a default config.yaml file when the Operator manages all components. Note that this example looks different depending on whether components are managed or unmanaged (managed: false).
ALLOW_PULLS_WITHOUT_STRICT_LOGGING: false
AUTHENTICATION_TYPE: Database
DEFAULT_TAG_EXPIRATION: 2w
ENTERPRISE_LOGO_URL: /static/img/RH_Logo_Quay_Black_UX-horizontal.svg
FEATURE_BUILD_SUPPORT: false
FEATURE_DIRECT_LOGIN: true
FEATURE_MAILING: false
REGISTRY_TITLE: Red Hat Quay
REGISTRY_TITLE_SHORT: Red Hat Quay
SETUP_COMPLETE: true
TAG_EXPIRATION_OPTIONS:
- 2w
TEAM_RESYNC_STALE_TIME: 60m
TESTING: false
In some cases, you might opt to manage certain components yourself, for example, object storage. In that scenario, you would modify the QuayRegistry CR as follows:
# ...
- kind: objectstorage
managed: false
# ...
If you are managing your own components, your deployment must be configured to include the necessary information or resources for that component. For example, if the objectstorage component is set to managed: false, you would include the relevant information depending on your storage provider inside of the config.yaml file. The following example shows you a distributed storage configuration using Google Cloud Storage:
# ...
DISTRIBUTED_STORAGE_CONFIG:
default:
- GoogleCloudStorage
- access_key: <access_key>
bucket_name: <bucket_name>
secret_key: <secret_key>
storage_path: /datastorage/registry
# ...
Similarly, if you are managing the horizontalpodautoscaler component, you must create an accompanying HorizontalPodAutoscaler custom resource.
5.4.3.1. Modifying the configuration file by using the OpenShift Container Platform web console Copy linkLink copied to clipboard!
To modify the config.yaml file stored in the configBundleSecret, you can use the OpenShift Container Platform web console to edit the secret and add configuration key-value pairs.
Prerequisites
- You are logged in to the OpenShift Container Platform cluster as a user with admin privileges.
Procedure
-
On the OpenShift Container Platform web console, click Operators
Installed Operators Red Hat Quay. - Click Quay Registry.
- Click the name of your Red Hat Quay registry, for example, example-registry.
- On the QuayRegistry details page, click the name of your Config Bundle Secret, for example, example-registry-config-bundle.
-
Click Actions
Edit Secret. In the Value box, add the desired key/value pair. For example, to add a superuser to your Red Hat Quay on OpenShift Container Platform deployment, add the following reference:
SUPER_USERS: - quayadminClick Save.
NoteYou must base64 encode any updated
config.yamlfile before placing it in the Secret. Ensure the Secret name matches the value specified inspec.configBundleSecretresource. Once the Secret is updated, the Operator detects the change and automatically rolls out updates to the Red Hat Quay pods.For detailed steps, see "Updating configuration secrets through the Red Hat Quay UI."
Verification
Verify that the changes have been accepted:
-
On the OpenShift Container Platform web console, click Operators
Installed Operators Red Hat Quay. - Click Quay Registry.
- Click the name of your Red Hat Quay registry, for example, example-registry.
Click Events. If successful, the following message is displayed:
All objects created/updated successfully
-
On the OpenShift Container Platform web console, click Operators
5.4.3.2. Modifying the configuration file by using the CLI Copy linkLink copied to clipboard!
To modify the config.yaml file for your Red Hat Quay registry and enable new features, you can download the existing configuration from the configBundleSecret by using the CLI. After making changes, you can re-upload the configBundleSecret resource to apply the changes.
Modifying the config.yaml file that is stored by the configBundleSecret resource is a multi-step procedure that requires base64 decoding the existing configuration file and then uploading the changes. For most cases, using the OpenShift Container Platform web console to make changes to the config.yaml file is simpler.
Prerequisites
- You are logged in to the OpenShift Container Platform cluster as a user with admin privileges.
Procedure
Describe the
QuayRegistryresource by entering the following command:$ oc describe quayregistry -n <quay_namespace># ... Config Bundle Secret: example-registry-config-bundle-v123x # ...Obtain the secret data by entering the following command:
$ oc get secret -n <quay_namespace> <example-registry-config-bundle-v123x> -o jsonpath='{.data}'{ "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo=" }Decode the data into a YAML file into the current directory by passing in the
>> config.yamlflag. For example:$ echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode >> config.yaml-
Make the desired changes to your
config.yamlfile, and then save the file asconfig.yaml. Create a new
configBundleSecretYAML by entering the following command.$ touch <new_configBundleSecret_name>.yamlCreate the new
configBundleSecretresource, passing in theconfig.yamlfile` by entering the following command:$ oc -n <namespace> create secret generic <secret_name> \ --from-file=config.yaml=</path/to/config.yaml> \ --dry-run=client -o yaml > <new_configBundleSecret_name>.yamlwhere:
- </path/to/config.yaml>
-
Specifies your base64 decoded
config.yamlfile.
Create the
configBundleSecretresource by entering the following command:$ oc create -n <namespace> -f <new_configBundleSecret_name>.yamlsecret/config-bundle createdUpdate the
QuayRegistryYAML file to reference the newconfigBundleSecretobject by entering the following command:$ oc patch quayregistry <registry_name> -n <namespace> --type=merge -p '{"spec":{"configBundleSecret":"<new_configBundleSecret_name>"}}'quayregistry.quay.redhat.com/example-registry patched
Verification
Verify that the
QuayRegistryCR has been updated with the newconfigBundleSecret:$ oc describe quayregistry -n <quay_namespace># ... Config Bundle Secret: <new_configBundleSecret_name> # ...After patching the registry, the Red Hat Quay Operator automatically reconciles the changes.