5 new key features and improvements in Red Hat Quay 3.13

The foundation of a robust container infrastructure is the container image. An image is a list of packages and configurations included in a container, so it's considered the source code of the container definition. Source code needs to be stored and managed, in ways that are both secure and accessible. Red Hat Quay is an open source and modern hub for your container images. With Quay, you have full control of your images, because you can run it on premises or on the cloud. You can use Quay to automate your container builds (with integration to GitHub, Bitbucket, and more), control access to your images, and even track image deployment.

The Red Hat Quay team is excited to announce version 3.13, which introduces a suite of new features aimed at enhancing security, streamlining access, and automating the management of container images. These updates address key challenges faced by users, and improves the overall efficiency of container operations. Significant updates include:

• Keyless authentication
• Certificate-based PostgreSQL authentication
• Enhanced auto-pruning policies
• Improved storage management and expanded read-only options
• Upgraded to Clair 4.8.0, removing Red Hat OVAL v2 updaters and adding Red Hat VEX updater

Keyless authentication: Added security with short-lived tokens

Quay now supports keyless authentication. Because it's keyless, you can access a system without the use of traditional credentials like a password or an API key. Instead, Quay uses short-lived, automatically generated tokens, which are periodically rotated for added security. This reduces the risk of credential theft while simplifying the authentication process.

The feature allows users to push and pull container images without relying on traditional static credentials, providing dynamic authentication between Quay and Red Hat OpenShift clusters. By leveraging OpenID Connect (OIDC) for identity-based access management, Quay now offers a robust and efficient method of authentication that aligns with modern cloud provider practices.

The implementation includes a pluggable credential provider for an OpenShift Kubelet, so a user can leverage an OIDC identity within the cluster to authenticate against Quay. This approach limits the permission scope to only what's required for push or pull operations.

How to help ensure only entitled users get a short-lived key

Quay lets you manage which users have access to it. You want only entitled users to have access to your system, so you can configure that. Assuming you have set up a pluggable credential provider for your  OpenShift kubelet that supports Red Hat Quay registry:

1. An OpenShift user leverages a valid OIDC identity within the cluster to authenticate against Quay
2. Your Kubelet provider uses the OIDC identity and token to create temporary credentials in Quay, limited to the permission scope required for push or pull operations on OpenShift
3. Tokens for individual registry transactions are automatically generated and refreshed every 5 minutes

Benefits of keyless authentication

Keyless authentication eliminates the need for manual pull secret management, and addresses concerns about static credentials. In short, it provides a security-focused, automated method for authentication that aligns with modern cloud provider practices. Other benefits include:

• Scalability: Simplifies authentication across multiple clusters and namespaces
• Improved security: The use of short-lived tokens minimizes the impact of potential credential leakage, making it harder for unauthorized access to occur
• Streamlined workflow: Automated authentication eliminates manual pull secret management

The 3.13 release delivers an API endpoint on Quay, and in future releases we'll add functionality to integrate with Red Hat OpenShift.

Certificate-based PostgreSQL authentication for enhanced database security

The introduction of certificate-based PostgreSQL authentication enables Quay to authenticate to PostgreSQL using client-side certificates. This significantly enhances database security and is a step closer to aligning with many customer policies. Currently, this feature can only be used in unmanaged external mode, but the future target is external, customer-managed Postgres databases.

How Certificate-based PostgreSQL authentication works

To ensure traffic encryption, you provide an SSL certificate, which Quay uses to authenticate with your PostgresSQL database.

Due to the immutable nature of secrets in Kubernetes pods, certificate rotation requires a pod restart. This cannot be done transparently without additional Kubernetes configurations, such as adding a K8s client, Role, RoleBinding, and token to fetch secrets on demand. It's important to consider (and include in your operational procedures) this limitation when planning for long-term certificate management.

In summary:

• Improved database security: Enables robust authentication ensuring only authorized users can connect to the PostgreSQL database
• Alignment with security policies: Helps organizations comply with stringent security requirements by implementing robust authentication methods
• Streamline operation: Simplifies the deployment process by automating the configuration of certifications, enhancing operational efficiency, and reducing manual intervention

Certificate-based authentication represents a significant step forward in securing Quay's database connections, particularly if you're managing your own PostgreSQL instances outside of Quay's managed environment.

Augmented auto-pruning policies

No image is ever truly complete, and after several iterations of lots of different images, things can get a little cluttered. Regularly pruning excess images that nobody's using any more is important, but when you have to do it manually it can be tedious. To help make it easier to tidy up, Quay now features enhanced auto-pruning policies, allowing you to create diverse auto-pruning rules based on tag patterns and multiple policies. Now you can implement targeted management of image tags, free of any limitations found in previous auto-pruning systems.

Pruning by tag patterns

You can now define regex patterns to specify which tags should be considered for pruning. For example, you can set rules to retain only the latest versions or specific tags while removing old or irrelevant images.

Support for multiple auto-pruning policies

There's rarely a single solution fit for every problem, so you can implement different pruning rules based on varying tag naming conventions within the same repository or organization.

Here are two concise examples of pruning by tag patterns:

• Targeting development tags: You create a policy using the regex pattern ^dev-.* to automatically prune all images tagged with dev- to maintain a clean registry by removing outdated development builds
• Managing nightly builds: Thanks to Quay's ability to run multiple rules, you could create one policy using the pattern .*nightly.* to prune nightly build images after 48 hours, and a separate policy to retain anything with a stable tag. This allows for distinct management of different image categories, ensuring important images are preserved while cleaning up non-critical ones

Whether through tag regex or multiple policy configurations, these auto pruning enhancements allow you to optimize storage, maintain a cleaner registry, and ensure that important images are preserved. Quay can  remove the obsolete ones for you.

Benefits of auto-pruning

• Optimized storage: You can maintain a cleaner registry by specifically targeting or excluding certain image tags by regex tag patterns
• Enhanced control: You can enforce policies that align with your development and release cycles, ensuring that critical images are preserved while obsolete ones are automatically removed
• Improved workflow efficiency: With multiple rules applied simultaneously, you can automate the cleanup process, reducing manual intervention and potential errors

Additional improvements

I've only covered some of the improvements to Quay with the 3.13 release. There are more new features, including:

• Improved storage management and expanded read-only options: Quay can push to the registry without manual configuration changes. You can now perform all registry operations without enabling pushes until quota recalculation is complete
• Upgraded to Clair to 4.8.0: The Clair team has deprecated the Red Hat OVAL v2 updaters, and has included a new VEX updater pulling data from security.access.redhat.com/data/csaf/v2/vex/. Vulnerabilities are now surfaced by CVE instead of RHSA. For more information, refer to our previous blog post explaining this update in more detail

Future enhancements

Looking ahead, we plan to implement immutable tags in a subsequent Z-stream which indicates a sub-release within the 3.13 version, prior to the next release. This feature allows image owners to set certain tags as immutable, helping ensure stable references for builds and compliance requirements.

These updates collectively strengthen Quay's capabilities, making it a great tool for managing your container images efficiently and more securely. Stay tuned for more insights on our blog, as we continue to discuss Quay's latest features and best practices. Stay tuned on the OpenShift YouTube channel for a look at these features in action.

We value your feedback! Help us shape the future of Quay on quay-sig group. Together, let's co-build the ultimate container management solution that meets the evolving needs of your organization!