Project Quay Release Notes

With this release, Project Quay supports multiple OIDC issuers and audiences per identity provider in *_LOGIN_CONFIG blocks. You can configure Project Quay to accept Microsoft Entra ID v1.0 and v2.0 tokens from the same provider, validate custom token audiences for On-Behalf-Of (OBO) API flows, and optionally restrict which client applications can authenticate by using the authorized party (azp) claim.

This enhancement enables integrations with Red Hat Developer Hub (RHDH), Red Hat Dev Spaces, and other tools that use modern Entra ID v2.0 access tokens. Existing configurations that use a single OIDC_ISSUER continue to work without changes.

Project Quay now validates token audiences on API bearer-token requests. Audience verification is no longer disabled for SSO bearer tokens.

Federated robot authentication also supports an optional audiences array on each federation configuration entry. When configured, Project Quay validates the external OIDC token audience during robot token exchange. When absent, audience validation is skipped and a deprecation warning is logged. For more information, see Robot federation audiences field.

For configuration field descriptions, see OIDC multi-issuer configuration fields. For setup and migration procedures, see Configuring Microsoft Entra ID v2 and multi-issuer OIDC.

When the tls component is set to unmanaged, the Project Quay Operator inherits the cluster’s TLS security profile from the APIServer configuration when neither SSL_PROTOCOLS nor SSL_CIPHERS is configured in the configBundleSecret resource. This helps align Project Quay with the platform TLS policy and supports Post-Quantum Cryptography (PQC) readiness when the cluster profile requires TLS 1.3.

To fully override or preserve TLS behavior, set both SSL_PROTOCOLS and SSL_CIPHERS in the configBundleSecret resource. Setting either field disables cluster-profile inheritance for both fields; partial configuration is not supported. Supported profile types are Old, Intermediate, Modern, and Custom. If the cluster has no profile set, the Operator defaults to the Intermediate profile (TLS 1.2 and TLS 1.3).

On Kubernetes clusters without the config.openshift.io API, the Operator does not inject TLS settings and Project Quay uses its built-in defaults.

For more information about SSL/TLS configuration fields, see SSL/TLS configuration fields.

For information about custom certificates and the config bundle, see Configuring custom SSL/TLS certificates for Red Hat Quay on OpenShift Container Platform. For information about TLS protocol and cipher inheritance, see OpenShift Container Platform cluster TLS security profile inheritance.

For more information about NIST post-quantum cryptography standards, see Post-Quantum Cryptography.

For the latest compliance information for OpenShift Container Platform, RHEL, and Red Hat Enterprise Linux CoreOS (RHCOS), see Compliance Activities and Government Standards.

With this release, you can override CPU and memory requests and limits for the Operator-managed redis component in the QuayRegistry custom resource. This brings redis in line with other managed components, such as quay, clair, mirror, and postgres, that already support resource overrides through spec.components[].overrides.resources.

When you do not set resource overrides for redis, the Operator uses the following defaults:

For example, to tune Redis resources for a smaller cluster, add an entry like the following under spec.components:

For more information about configuring resource requests and limits, see Configuring QuayRegistry CR resources.

With this release, you can configure volumeSize and storageClassName overrides on the managed clair component in the QuayRegistry custom resource. These overrides customize the ephemeral volume that Clair uses for image layer extraction at /var/tmp.

When you do not set overrides, the Operator requests 20Gi of ephemeral storage with no explicit storage class. Large or unexpected images can exhaust this scratch space and disrupt vulnerability scanning.

For example:

These overrides apply to Clair scratch storage only. They do not resize the managed Clair PostgreSQL database.

For more information, see Configuring ephemeral storage for managed Clair.

The Project Quay Operator supports referencing an external kubernetes.io/tls Secret for registry HTTPS certificates through the QuayRegistry CR. This feature enables automated certificate rotation without embedding ssl.cert and ssl.key files in the configBundleSecret CR. Certificate sources can include cert-manager, HashiCorp Vault, or manually updated Secrets. When the referenced Secret changes, the Operator performs a rolling restart of Project Quay pods.

The QuayRegistry status includes a ComponentTLSReady condition that reports whether TLS from the external Secret is valid and applied.

For configuration steps, see Referencing an external TLS Secret for Red Hat Quay on OpenShift Container Platform. For a cert-manager example, see Example: Using cert-manager with an external TLS Secret.

When you deploy Red Hat Quay on OpenShift Container Platform, the Operator can populate the existing SSL_PROTOCOLS and SSL_CIPHERS fields from the cluster-wide OpenShift Container Platform tlsSecurityProfile when neither field is set in the configBundleSecret resource. To fully override or preserve TLS behavior, set both fields. Setting either field disables cluster-profile inheritance for both fields.

For more information, see OpenShift Container Platform cluster TLS security profile inheritance and Preserving TLS settings before upgrading Red Hat Quay on OpenShift Container Platform.

The following optional fields were added to *_LOGIN_CONFIG blocks in Project Quay 3.18:

If both OIDC_ISSUER and OIDC_ISSUERS are set, OIDC_ISSUERS takes precedence and Project Quay logs a warning.

For field reference details, see OIDC configuration fields. For configuration examples, see Configuring Microsoft Entra ID v2 and multi-issuer OIDC. The following configuration fields have been added to Project Quay 3.18.

The following fields apply to the tls entry in spec.components of the QuayRegistry CR when deploying Red Hat Quay on OpenShift Container Platform.

For procedures and examples, see Referencing an external TLS Secret for Red Hat Quay on OpenShift Container Platform.

Robot federation configuration entries now support an optional audiences array in addition to issuer and subject. During federated robot token exchange (GET /oauth2/federation/robot/token), when audiences is present on the matching federation entry, Project Quay validates the external OIDC token audience against that list. When audiences is absent, audience validation is skipped and Project Quay logs a deprecation warning advising you to configure audiences.

A future release will require the audiences field for federated robot authentication.

Configure federation entries by using the Project Quay v2 UI or POST /api/v1/organization/{orgname}/robots/{robot_shortname}/federation. In Project Quay 3.18, create and update requests persist issuer and subject only; audience validation applies when audiences is present in the stored federation configuration. For field descriptions, examples, and current API limitations, see createOrgRobotFederation and Configuring federation audiences.