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

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 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 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. Setting managed: true to a component in the QuayRegistry CR means that the Operator manages the component.
    • secretRef: Optional. For the tls component only, references an external kubernetes.io/tls Secret when managed is false. 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

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.

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. You can override ephemeral scratch storage for image layer extraction by using overrides.volumeSize and overrides.storageClassName.

redis

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.

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. When managed is false, you can optionally set secretRef to reference an external kubernetes.io/tls Secret instead of embedding ssl.cert and ssl.key in the configBundleSecret.

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.

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

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.

Important
  • secretRef is valid only when the tls component is unmanaged (managed: false).
  • Do not configure both secretRef and ssl.cert / ssl.key files in the configBundleSecret resource. 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=True until the certificate is corrected.
  • Existing deployments that use embedded ssl.cert and ssl.key files in the config bundle continue to work without changes.

Prerequisites

  • You have deployed the Red Hat Quay Operator and a QuayRegistry CR.
  • You have a TLS Secret of type kubernetes.io/tls in the same namespace as the QuayRegistry, with tls.crt and tls.key data keys.
  • The certificate and private key are valid (format, key match, chain, and hostname).

Procedure

  1. 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>
  2. Set the tls component 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"}}]}}'
  3. Verify that the QuayRegistry CR contains the expected configuration:

    $ oc get quayregistry <registry_name> -n <namespace> -o yaml

    Example output

    spec:
      components:
      - kind: tls
        managed: false
        secretRef:
          name: my-quay-tls

  4. 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.
  5. Verify that TLS from the external Secret is ready by entering the following command. When the TLS component is healthy, the ComponentTLSReady condition reports status: "True".

    $ oc wait quayregistry <registry_name> -n <namespace> --for=condition=ComponentTLSReady=True --timeout=300s

    You 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 yaml and checking status.conditions.

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: 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.

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

  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.

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

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

    $ oc edit quayregistry <registry_name> -n <namespace>
  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.4.3. Understanding the configBundleSecret

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.

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

  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
  7. Click Save.

    Note

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

  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

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.

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>
    # ...
      Config Bundle Secret: example-registry-config-bundle-v123x
    # ...
  2. 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="
    }
  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
  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
  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> \
      --dry-run=client -o yaml > <new_configBundleSecret_name>.yaml

    where:

    </path/to/config.yaml>
    Specifies 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
    secret/config-bundle created
  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>"}}'
    quayregistry.quay.redhat.com/example-registry patched

Verification

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

    $ 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.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

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.

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 Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top