Red Hat Quay 3.11: Smarter permissions, lifecycle, and AWS integration

The Quay team is excited to announce that Red Hat Quay 3.11 will be generally available this month. This release will introduce updates to permission management and image lifecycle automation automation for more effective management at scale.

Significant updates include:

• Team-sync with OIDC groups
• Pruning policies at the repository level
• More Quay feature coverage in the new UI
• General AWS STS support
• Quay operator enhancements

Increased control across user groups

With Quay 3.11, users can manage permissions based on groupings defined in an OIDC provider (e.g. Azure Active Directory Service). Quay administrators and organization owners can benefit from this update by defining access levels more effectively: The group membership in OIDC identifies users and their roles centrally across multiple systems, and permissions in Quay can be easily added or removed from arbitrarily large groups of users. For example, an OIDC group called “developer” could be leveraged to give permissions to a team of engineers to use CI/CD pipelines and push images to their Quay organization but not change organization-level settings in Quay.

See a demo of how it works here. In Quay organizations, teams are groups of users who can pull, push, update images, or administer the organization based on their role. OIDC group sync allows team members to be automatically recognized by mapping the team definition to a group name in the OIDC provider.

Flexibility with automated image lifecycles

Expanding off of the previous release, Quay 3.11 introduces repository-specific rules to prune policies in addition to or instead of organization-level policies. This adds an extra layer of granularity when defining the lifecycle for images. For example, inside an organization, multiple repositories host images for different components of an application stack. A pruning policy could be defined at the organizational level to automatically remove images once they are more than one year old. With Red Hat Quay 3.11, users can now define additional policies for individual repositories that hold test and staging images, which might remove nightly builds after 30 days. This will also foster a better security posture by reducing exposure to vulnerabilities found in outdated images. Check out a demo of how it works here!

**Unlocked features in the new UI **

This release also includes more Quay feature coverage in the new user interface to enable more workflows. Users can now manage their image builds as well as review audit events in organizations.

This update also introduces efficient search across many tags, repositories, and organizations with regular expressions. In addition, users can leverage a dark mode within the new UI, which is automatically enabled based on the user’s system settings.

Strengthened security with AWS services

You can now connect Quay with greater security to AWS S3 through AWS’s Secure Token Service. By leveraging STS, users no longer need to leverage classic, long-lived AWS access keys and secret keys to give Quay access to AWS services but can rely on an automated token exchange mechanism between Red Hat Quay and the AWS IAM system. These tokens are time-limited and refreshed automatically by Quay so that the impact of token leaking is limited. The Red Hat Quay team implemented this based on feedback from customers who mandate using STS across their environment.

Operational Enhancements

The Quay operator can now be leveraged to fine-tune the resource consumption requests and limits at the Kubernetes level. Every managed component of the Quay stack, that is Quay itself, Clair, the PostgreSQL instance for both, as well as Redis and the mirror workers, can be configured with individual resource requests and limit values:

spec:
 components:
   - kind: clair
     managed: true
     overrides:
       resources:
         limits:
           cpu: "5"     # Limiting to 5 CPUs (vs. 4 default)
           memory: "18Gi"  # Limiting to 18 Gibibytes of memory (vs. 16 Gi default)
         requests:
           cpu: "4"     # Requesting 4 CPUs (vs. 2 default)

This helps adjust the minimum resources Quay components will request from the cluster to be able to run, which, in general, is useful when running on smaller, more resource-constrained clusters. Limits can also be adjusted, which can be used to account for very large deployments, like shown in the example above.

The Red Hat Quay 3.11 release also addresses an issue where custom replica settings for Quay deployment components managed by the operator conflicted with the horizontal pod auto-scaler settings. Now, these can be adjusted and the HPA will honor these settings accordingly. This alleviates the need to disable automatic scaling if a higher default amount of Quay and Clair pod instances is desirable.

Other Enhancements

Customers with large deployments often want to use Quay to pool connections on the PostgreSQL side. One of the popular PostgreSQL connection poolers is pgBouncer, and users have requested that pgBouncer be verified to work with Quay as well. With Red Hat Quay 3.11 the use of pgBouncer is supported and tested by our QA team with CrunchyDB Postgres. Quay’s static vulnerability analyzer has also been enhanced to improve resource utilization

Future outlook

Quay’s roadmap for 2024 and beyond is very interesting. We want to complete the migration to the new UI this year and fully remove the old Angular-based interface. We plan to invest in core registry features that improve and automate the container image lifecycle and workflow, such as immutable tags, default tag expiration policies, and policies to deny a pull based on vulnerabilities or incorrect/missing signatures. Improvements to authenticating users and workloads on OpenShift clusters on the Quay side at scale are also planned. Finally, we want to make it easier to transfer the vulnerability databases into offline environments when Quay and Clair are running disconnected from the internet.

Learn more about Red Hat Quay