With Red Hat Quay 3.8 DevSecOps teams now have a solution available to contain ubiquitous container image sprawl. This release of Quay focuses on manageability, targeting operations teams in charge of providing a central container registry service to a wide range of container clients with an ever increasing variety in content types. Red Hat Quay 3.8 is supported to be run on all current OpenShift releases as well as the upcoming OpenShift 4.12 version, RHEL 8 and RHEL 9 and ships a new set of versions of the Container Security Operator and the Clair scanning engine. It can be obtained from our Red Hat Container Catalog or by installing / updating the Red Hat Quay Operator on OpenShift.
A new user interface
The front ends of Red Hat Quay and Quay.io are tried and trusted but haven’t changed in a very long time, and certainly feel different from the rest of the Red Hat product portfolio. With this release we are launching a preview of the new user interface of Quay that is based on the PatternFly project and aligns visually with the Red Hat OpenShift platform.
In this new interface users and superusers will be able to carry out standard image management tasks like browsing, creating or deleting repositories in an organization or user account, managing image tags, getting pull commands and reviewing security vulnerability reports. Functionality like user and robot account management, creating proxy caches, managing default permissions or the superuser panel will be added in subsequent releases, so be sure to watch out for new public previews of Quay (for instance via the Quay Operator on OperatorHub.io) updated to receive the newest features.
The new user interface focuses heavily on ease of management with large content sets and introduces new actions that can be applied to a group of repositories and image tags. You can also watch a demo here.
Future versions will see a lot more operations that can be applied to multiple repositories, teams, users, builds and organizations at once. The new frontend will also allow more in-place configuration updates, for instance for build triggers, so that modifications can be made without having to delete and recreate things first. This lays the foundation for completely new visualizations for certain content types like Software Bill-of-Materials (SBOMs), image signatures or Helm Charts
For now the new interface will remain in Tech Preview and will transition into a supported state when all standard management tasks within organizations, repositories and image tags can be accomplished without switching back to the current frontend. We plan to complete this transition within the next two Quay releases and eventually remove the old UI. With that we will also introduce new APIs for browsing and listing content that lifts computational burden from the backend.
A new type of superuser
In its current form, the Quay superuser has limited access to the actual content of the registry and can only directly manage users. If superusers wanted to access user content they first needed to take ownership of the organization containing the desired images. Users have frequently reported this to be an obstacle in daily management and auditing tasks and we listened to this feedback.
In Red Hat Quay 3.8, the superuser can be configured to have full control over all content in the system. It can be enabled via the `FEATURE_SUPERUSERS_FULL_ACCESS` configuration toggle and allows the superuser to simply browse and introspect all images in all organizations as if they were their own. They can also delete and create new content as they see fit. All these events are audited for compliance and allow Quay administrators to quickly intervene or manage content. Be sure to check out the demo to learn more!
Another frequent use case for wide access to a registry is content auditing. While Quay, as mentioned above, already logs all events and changes to the system, users told us that they would like to be able to give global read-only access to a trusted actor. This persona would become an auditor for the content itself without making them able to change any setting or content on the platform.
Again, we listened and in Red Hat Quay 3.8 this can now also be achieved with the `GLOBAL_READONLY_SUPER_USERS` configuration option. In the 3.8.0 release, it will enable this kind of user to pull all images in the registry. We expect connecting external image scanners to Quay to be a popular use case for this. In subsequent releases of Quay read-only superusers will also be able to read other data in the registry, like build and action logs and team membership and permissions settings.
A new type of user
Today, in some environments, users are not allowed to log in to a Quay instance directly via the web user interface. They only get registry credentials via robot tokens for usage with podman, docker or Kubernetes clusters to push and pull images and occasionally create new image repositories. But they are not actual users in Quay because administrators are hesitant. This is because as soon as an individual has a user account in Quay, they can start to create new organizations or start consuming storage space by pushing images into their own account. In highly regulated environments or deployments with limited resources this is often not desirable.
With Red Hat Quay 3.8 administrators can confidently give all their users direct access to Quay without worrying about content sprawl and resource contention. This is possible with a new type of permission profile that is known as a “restricted users”. Users in this category can by default not create or see any content in the registry. They can also not create new organizations. Only another Quay user that owns or can create an organization or is a superuser can invite them to existing organizations and assign them roles and responsibilities in this space. This way, Quay user audiences can be split into two groups: regular users which can create new content and organization without prior permission and restricted users which need to be invited to existing organizations first. This allows for user onboarding to be modeled. You can see the effects in this demo!
Restricted users can be enabled and will by default apply to all users currently registered in Quay unless they are on an allow-list. If Quay is configured to use LDAP as an authentication source, the allow-list (list of unrestricted/regular users) can also be expressed via an LDAP filter query.
Proxy-pull thru caching moves out of Tech Preview
In the last release, Red Hat Quay 3.7, a new way to integrate external registry content was introduced: pull-thru proxy caching. You can read more about it in the official 3.7 launch blog. In short, it allows Quay to transparently cache images in other registries and serve them, as if they were mirrored to Quay. The actual image transfer however happens on demand and is transparent to the user.
The limitation of the Tech Preview version in 3.7 was that there was no size limit to the cache. When caching an upstream registry like quay.io or DockerHub, the cache size can grow significantly. In Red Hat Quay 3.8, administrators don’t need to worry about that anymore. Caches can be limited to a maximum size using storage quotas. Once defined, Quay will autonomously delete older images from the cache to stay below the limit. See it in action in this demo.
Red Hat Quay 3.8 now also supports IPv6 single-stack environments for all supported deployment flavors. This enables usage of Quay as a central registry in environments with a fleet of edge devices that often only support IPv6.
The Container Security Operator is an addition to the Red Hat Quay product that ships with the product on OpenShift and allows to relay security vulnerability reports from Quay directly into the OpenShift Console. Previously, this wasn’t available in disconnected environments because the Container Security Operator did not have support for OpenShift offline mirroring. With the Container Security Operator v3.8 this is now possible and vulnerabilities will be reported for mirrored images and cluster-wide proxy setups.
Quay and Quay.io have an exciting year ahead. In 2023 we are looking to move over to a completely redesigned user interface with better APIs in the background supporting that frontend. Quay.io will also move its authenticated user experience into console.redhat.com. Vulnerability scan coverage is going to be significantly increased with the addition of NPM and Ruby Gem as package managers Clair can index content from and support for scanning Golang binaries.
While we are planning to introduce new image lifecycle capabilities like mirroring of large sets of content across organizations and image retention policies to help with cleanup of old images, overall Quay is positioned to be the trusted source of containerized software and related artifacts like signatures, SBOMs, attestations and more in a world that is heavily focussed on supply chain security.