Red Hat Quay 3.9 is Generally Available
Here in this blog, we are going to learn is Red Hat Quay 3.9 is generally available or not.
As of right now, Red Hat Quay 3.9 is generally accessible! This version offers a more scalable method of monitoring storage use across a large number of tenants utilizing the registry, expands audit logging coverage, integrates with external log management systems, and extends the vulnerability reporting coverage of container image content. Additionally, we enhanced Quay’s distinctive geo-replication feature’s resilience and automated updated the embedded PostgreSQL database. Red Hat Quay will eventually be in line with the Red Hat OpenShift Container Platform’s lifespan.
Increased and more accurate reporting of vulnerabilities
The breadth and depth of reporting vulnerabilities is becoming increasingly crucial as supply chain security becomes a top priority for many IT leaders. It’s crucial to avoid inundating security auditors and developers with noise in vulnerability reports that result from false positives while also enhancing reporting capacity.
A new version of Clair, Quay’s internal vulnerability reporting engine, is included in Red Hat Quay 3.9. Clair can now display CVEs discovered in Ruby-based apps utilizing RubyGems as well as vulnerabilities for Golang modules reported in Golang binaries.
Through Clair, Quay has already reported vulnerabilities for many operating system package managers, including apt in Debian and Ubuntu as well as apk in Alpine, as well as Red Hat’s rpm/yum/dnf in Red Hat Enterprise Linux, Oracle Enterprise Linux, AWS Linux, or SuSE Enterprise Linux. Additionally, it already addresses flaws in Python and Java maven package managers, and improvements have been made to address false positives that could arise when installing any of these language packages using an operating system’s package management.
For programming language package managers, Clair now additionally uses the OSV.dev vulnerability database, which makes it possible to report on Java CVEs that are accessible offline. Red Hat Quay versions 3.8 and older were reliant on a web service.
As a side note, Quay can store and provide image signatures, SBOMs, and attestations produced by the SigStore.dev toolchain because it supports OCI artifacts.
Red Hat Quay’s security vulnerability reporting is getting better all the time, so expect to see more ecosystems and programming languages covered in the future, including JavaScript.
Audit Logging integration with Splunk
As part of its integration with Splunk Quay, Audit Logging audits a large number of events that take place in a central registry service. As of the 3.9 release, this auditing now also covers the creation and modification of organizations, organization settings, and robots, in addition to repository-based events.
A central Splunk instance may now receive all audit events from Quay because we connected the auditing system with Splunk’s REST API in response to user requests. In contrast to what would often be achievable when storing the audit data in Quay’s own internal database, this enables users to efficiently store large amounts of auditing data from a Quay instance over longer periods of time. The user is intended to conduct log review in Splunk directly rather than through the Quay UI after Splunk integration is enabled.
Tracking of scalable storage utilization
Storage quotas had already been added in prior Red Hat Quay releases, but some of our clients with particularly big Quay deployments ran across problems with the implementation. Additionally, we have incorporated suggestions regarding the benefits of layer sharing and the overall calculation coverage of storage consumption.
Red Hat Quay 3.9 features a totally reimplemented tracking system that gives users access to a considerably faster storage consumption computation that scalable to deployments with tens of thousands of users and organizations without degrading the speed of image pushes or the UI’s display. Quay displays storage use at the repository level as well as the organization level, in contrast to traditional implementations, which enables organization administrators to appropriately attribute storage usage to specific teams or apps.
Users will now be encouraged to use a common base image across repositories in an organization because these will only be counted once for the organization, in contrast to the previous calculation where the use of a common base image in various repositories resulted in double counting.
UBI, for example, is a popular base image from Red Hat and is offered in several footprints based on the particular needs of the developer or containerized application. No matter how many of an organization’s repositories and image tags are based on such a base image, Red Hat Quay 3.9 will only assign that organization’s storage needs once. The storage consumption will still be ascribed to each organization that uses the same base image in their repository. Despite this, each distinct container picture layer is only ever saved once in Quay.
Geo-replication resilience
In geo-replication, a number of geographically separated Quay instances work as one single, sizable registry service with a single entry point, transparently replicating images to the client. Red Hat Quay 3.9 makes it easier to handle situations in which one of the instances and its storage are irretrievably lost. Previously, database changes were required to totally remove the site from the geo-replication configuration.
The Quay container image has utilities that have automated this process.
Updated Postgres version
Quay switches to Postgres v13 when Postgres v10 reaches its end of support in May 2024. This will be a fully automated migration for clients running Red Hat Quay with the operator on OpenShift, utilizing the potency of the Kubernetes operator pattern.
A lot happens behind the scenes: the operator creates new storage volumes, stops the Quay and Clair pods, and uses Postgres tooling to copy and dump the Quay and Clair databases’ content onto the new storage volumes. A fresh database instance running Postgres v13 is eventually started. The operator is handling the on-disk data format change required by upgrading to this version of Postgres by reimporting the database dumps into the new database instances. The update will be postponed till the databases are up and that process is finished. In the event that something goes wrong, the operator will provide the user the option to undo these modifications and restart the registry service.
However, the second database volume or momentarily increased storage consumption during the update downtime (minutes depending on the database size) must be taken into account. By shutting down the previous database instance and executing a migration script, users of standalone Quay deployments on RHEL server can manually migrate the database.
Added advancements
Numerous issues are fixed and vulnerabilities in Quay’s dependencies are addressed with each new release. This edition includes two additional enhancements that stand out: The image layers’ backend, Nutanix Objects Storage, is officially supported by Quay. Our support matrix has been updated to include this setup.
UI screens for Repository Settings, Permission control, Robot accounts, and Notifications have also been added to the new PatternFly-based UI. Even though the new user interface is still optional, it is simple to test it out by adding FEATURE_UI_V2 = True to the Quay configuration file.
In this little survey, please let us know your thoughts.
The lifespan will support future changes
Up until this point, Red Hat Quay adhered to an n-2 support model: for any given Red Hat Quay version, the two prior versions would be in the Maintenance support phase and receive changes as Red Hat saw fit.
The lifecycle will begin to synchronize with Red Hat OpenShift from Red Hat Quay 3.10 forward. As a result, the 3.10 release will be accessible 4 weeks after the introduction of OpenShift Container Platform 4.14 at the start of Q4 of this year, and it will share the same support phase dates. This will enable users to version-lock Quay deployments on top of OpenShift with the cluster’s lifespan. As a result, each Red Hat Quay release will receive support for 18 or 24 months, up to 12 months longer than the previous maintenance cycles. Customers who need to plan maintenance periods for changes to their central registry instance with a lot of advance notice will generally benefit from this.
Customers can expect to always have a supported update path between the various versions of Red Hat Quay, but particularly between the Extended Update Support versions that are aligned with even OCP releases. Red Hat Quay is still tested and supported on older OCP releases as it is right now. The support length and release cadence change. The deployment of Red Hat Quay outside of the OpenShift Container Platform is still supported.
The lifecycle of Red Hat Quay 3.8 and 3.9 has been extended as of the general availability of Red Hat Quay 3.10 to accommodate clients using earlier releases of Quay and give them adequate time to update.
On the Red Hat Quay Lifecycle Policy page, you can always check the lifecycle details and support phase dates.
