Chapter 5. Red Hat Quay on OpenShift Container Platform configuration overview


When deploying Red Hat Quay using the Operator on OpenShift Container Platform, configuration is managed declaratively through the QuayRegistry custom resource (CR). This model allows cluster administrators to define the desired state of the Red Hat Quay deployment, including which components are enabled, storage backends, SSL/TLS configuration, and other core features.

After deploying Red Hat Quay on OpenShift Container Platform with the Operator, administrators can further customize their registry by updating the config.yaml file and referencing it in a Kubernetes secret. This configuration bundle is linked to the QuayRegistry CR through the configBundleSecret field.

The Operator reconciles the state defined in the QuayRegistry CR and its associated configuration, automatically deploying or updating registry components as needed.

This guide covers the basic concepts behind the QuayRegistry CR and modifying your config.yaml file on Red Hat Quay on OpenShift Container Platform deployments. More advanced topics, such as using unmanaged components within the QuayRegistry CR, can be found in Deploying Red Hat Quay Operator on OpenShift Container Platform.

5.1. Understanding the QuayRegistry CR

By default, the QuayRegistry CR contains the following key fields:

  • configBundleSecret: The name of a Kubernetes Secret containing the config.yaml file 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 component that the Operator automatically manages. Each spec.component field contains two fields:

    • kind: The name of the component
    • managed: A boolean that addresses whether the component lifecycle is handled by the Red Hat Quay Operator. Setting managed: true to a component in the QuayRegistry CR means that the Operator manages the component.

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

By default, the Operator handles all required configuration and installation needed for Red Hat Quay’s managed components.

If the opinionated deployment performed by the Red Hat Quay Operator is unsuitable for your environment, you can provide the Red Hat Quay Operator with unmanaged resources, or overrides, as described in Using unmanaged components.

Expand
Table 5.1. QuayRegistry required fields
FieldTypeDescription

quay

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 (managed: false).

postgres

Boolean

Used for storing registry metadata. Currently, PostgreSQL version 13 is used.

clair

Boolean

Provides image vulnerability scanning.

redis

Boolean

Storage live builder logs and the locking mechanism that is required for garbage collection.

horizontalpodautoscaler

Boolean

Adjusts the number of quay pods depending on your memory and CPU consumption.

objectstorage

Boolean

Stores image layer blobs. When set to managed: true, utilizes the ObjectBucketClaim Kubernetes API which is provided by NooBaa or Red Hat OpenShift Data Foundation. Setting this field to managed: false requires you to provide your own object storage.

route

Boolean

Provides an external entrypoint to the Red Hat Quay registry from outside of OpenShift Container Platform.

mirror

Boolean

Configures repository mirror workers to support optional repository mirroring.

monitoring

Boolean

Features include a Grafana dashboard, access to individual metrics, and notifications for frequently restarting quay pods.

tls

Boolean

Configures whether SSL/TLS is automatically handled.

clairpostgres

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.

Example QuayRegistry custom resource

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
Copy to Clipboard Toggle word wrap

After you have installed the Red Hat Quay Operator and created an initial deployment, you can modify the QuayRegistry custom resource (CR) to customize or reconfigure aspects of the 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: true to managed: false in order to bring your own infrastructure. For example, you might set kind: objectstorage to unmanaged to integrate external object storage platforms such as Google Cloud Storage or Nutanix.
  • To apply custom configuration: Update or replace the configBundleSecret to 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.components list.
  • 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.

The QuayRegistry can be modified by using the OpenShift Container Platform web console. This allows you to set managed components to unamanged (managed: false) 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

  1. On the OpenShift Container Platform web console, click Operators Installed Operators.
  2. Click Red Hat Quay.
  3. Click Quay Registry.
  4. Click the name of your Red Hat Quay registry, for example, example-registry.
  5. Click YAML.
  6. Adjust the managed field of the desired component to either True or False.
  7. Click Save.

    Note

    Setting a component to unmanaged (managed: false) might require additional configuration. For more information about setting unmanaged components in the QuayRegistry CR, see Using unmanaged components for dependencies.

The QuayRegistry CR can be modified by using the CLI. This allows you to set managed components to unamanged (managed: false) and use your own infrastructure.

Prerequisites

  • You are logged in to your OpenShift Container Platform cluster as a user with admin privileges.

Procedure

  1. Edit the QuayRegistry CR by entering the following command:

    $ oc edit quayregistry <registry_name> -n <namespace>
    Copy to Clipboard Toggle word wrap
  2. Make the desired changes to the QuayRegistry CR.

    Note

    Setting a component to unmanaged (managed: false) might require additional configuration. For more information about setting unmanaged components in the QuayRegistry CR, see Using unmanaged components for dependencies.

  3. Save the changes.

5.3.3. Understanding the configBundleSecret

The spec.configBundleSecret field is an optional reference to the name of a Secret in the same namespace as the QuayRegistry resource. This Secret must contain a config.yaml key/value pair, where the value is a Red Hat Quay configuration file.

The configBundleSecret stores the config.yaml file. Red Hat Quay administrators can define the following settings through the config.yaml file:

  • Authentication backends (for example, OIDC, LDAP)
  • External TLS termination settings
  • Repository creation policies
  • Feature flags
  • Notification settings

Red Hat Quay 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 the field is provided, the contents of the config.yaml are used as the base configuration and are merged 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 all components are managed by the Operator. Note that this example looks different depending on whether components are managed or unmanaged (managed: false).

Example YAML with all components managed by the Operator

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
Copy to Clipboard Toggle word wrap

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:

Unmanaged objectstorage component

# ...
    - kind: objectstorage
      managed: false
# ...
Copy to Clipboard Toggle word wrap

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:

Required information when objectstorage is unmanaged

# ...
DISTRIBUTED_STORAGE_CONFIG:
    default:
        - GoogleCloudStorage
        - access_key: <access_key>
          bucket_name: <bucket_name>
          secret_key: <secret_key>
          storage_path: /datastorage/registry
# ...
Copy to Clipboard Toggle word wrap

Similarly, if you are managing the horizontalpodautoscaler component, you must create an accompanying HorizontalPodAutoscaler custom resource.

Use the following procedure to modify the config.yaml file that is stored by the configBundleSecret by using the OpenShift Container Platform web console.

Prerequisites

  • You are logged in to the OpenShift Container Platform cluster as a user with admin privileges.

Procedure

  1. On the OpenShift Container Platform web console, click Operators Installed Operators Red Hat Quay.
  2. Click Quay Registry.
  3. Click the name of your Red Hat Quay registry, for example, example-registry.
  4. On the QuayRegistry details page, click the name of your Config Bundle Secret, for example, example-registry-config-bundle.
  5. Click Actions Edit Secret.
  6. 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:
    - quayadmin
    Copy to Clipboard Toggle word wrap
  7. Click Save.

Verification

  1. Verify that the changes have been accepted:

    1. On the OpenShift Container Platform web console, click Operators Installed Operators Red Hat Quay.
    2. Click Quay Registry.
    3. Click the name of your Red Hat Quay registry, for example, example-registry.
    4. Click Events. If successful, the following message is displayed:

      All objects created/updated successfully
      Copy to Clipboard Toggle word wrap
Note

You must base64 encode any updated config.yaml before placing it in the Secret. Ensure the Secret name matches the value specified in spec.configBundleSecret. 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."

You can modify the config.yaml file that is stored by the configBundleSecret by downloading the existing configuration using the CLI. After making changes, you can re-upload the configBundleSecret resource to make changes to the Red Hat Quay registry.

Note

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

  1. Describe the QuayRegistry resource by entering the following command:

    $ oc describe quayregistry -n <quay_namespace>
    Copy to Clipboard Toggle word wrap
    # ...
      Config Bundle Secret:  example-registry-config-bundle-v123x
    # ...
    Copy to Clipboard Toggle word wrap
  2. Obtain the secret data by entering the following command:

    $ oc get secret -n <quay_namespace> <example-registry-config-bundle-v123x> -o jsonpath='{.data}'
    Copy to Clipboard Toggle word wrap

    Example output

    {
        "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo="
    }
    Copy to Clipboard Toggle word wrap

  3. Decode the data into a YAML file into the current directory by passing in the >> config.yaml flag. For example:

    $ echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode >> config.yaml
    Copy to Clipboard Toggle word wrap
  4. Make the desired changes to your config.yaml file, and then save the file as config.yaml.
  5. Create a new configBundleSecret YAML by entering the following command.

    $ touch <new_configBundleSecret_name>.yaml
    Copy to Clipboard Toggle word wrap
  6. Create the new configBundleSecret resource, passing in the config.yaml file` by entering the following command:

    $ oc -n <namespace> create secret generic <secret_name> \
      --from-file=config.yaml=</path/to/config.yaml> \ 
    1
    
      --dry-run=client -o yaml > <new_configBundleSecret_name>.yaml
    Copy to Clipboard Toggle word wrap
    1
    Where <config.yaml> is your base64 decoded config.yaml file.
  7. Create the configBundleSecret resource by entering the following command:

    $ oc create -n <namespace> -f <new_configBundleSecret_name>.yaml
    Copy to Clipboard Toggle word wrap

    Example output

    secret/config-bundle created
    Copy to Clipboard Toggle word wrap

  8. Update the QuayRegistry YAML file to reference the new configBundleSecret object by entering the following command:

    $ oc patch quayregistry <registry_name> -n <namespace> --type=merge -p '{"spec":{"configBundleSecret":"<new_configBundleSecret_name>"}}'
    Copy to Clipboard Toggle word wrap

    Example output

    quayregistry.quay.redhat.com/example-registry patched
    Copy to Clipboard Toggle word wrap

Verification

  1. Verify that the QuayRegistry CR has been updated with the new configBundleSecret:

    $ oc describe quayregistry -n <quay_namespace>
    Copy to Clipboard Toggle word wrap

    Example output

    # ...
      Config Bundle Secret: <new_configBundleSecret_name>
    # ...
    Copy to Clipboard Toggle word wrap

    After patching the registry, the Red Hat Quay Operator automatically reconciles the changes.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat