The Quay team at Red Hat is proud to announce that Red Hat Quay 3.5 is generally available as of today. The Quay 3.4 release was announced just back in February and we are looking to get a new Quay release into your hands every quarter. Here is what you can expect from Red Hat Quay 3.5:
FIPS Readiness and Compliance
A lot of customers in the public sector as well as other heavily regulated industries like banking or health care look at FIPS (Federal Information Processing Standard developed by the National Institute of Standards and Technology, NIST) as the gold standard for securing and encrypting sensitive data. Red Hat Enterprise Linux and Red Hat OpenShift Container Platform do support this standard by providing a FIPS mode in which the system would only allow usage of certain, FIPS-validated cryptographic modules, like openssl. This ensures FIPS compliance.
Red Hat Quay 3.5 now supports running on RHEL and OCP in FIPS mode in production. Furthermore, Quay itself also commits to exclusively using cryptography libraries that are validated or are in the process of being validated by NIST. Quay 3.5 has pending FIPS 140-2 validation based on the RHEL 8.3 cryptography libraries. As soon as that validation is finalized, Quay 3.5 is officially FIPS compliant.
Quay Observability through OpenShift Monitoring
Running Quay on OpenShift via the Operator brings many benefits. Scheduling and scaling decisions as well as configuration injection can be delegated to the lower Kubernetes layer while providing the administrator a clean control interface to deploy and manage their Quay registry via an API. Updates are fully automated and initiated by simply updating the Quay Operator.
But there is more: OpenShift ships with an onboard monitoring stack that is supported via the graphical OpenShift Console by an embedded dashboard. This is where you can observe the healthiness and performance of various OpenShift subsystems. The Quay Operators adds a Quay Dashboard there that allows administrators to track vital data about their Quay registry like the push and pull rates, API latency and the CPU utilization of various Quay sub processes to quickly spot bottlenecks and potential performance issues that may cause a degraded user experience.
Also several statistics of your Quay registry like the amount of users, organizations or image repositories is captured. If you manage multiple Quay deployments via the Operator then you will get one dashboard per registry.
Having visual observability of your registry is one further step into integration of Quay with OpenShift. You can expect more to happen in this space in the future, where we ship pre-configured alert thresholds so that OpenShift proactively warns administrators when certain metrics exceed well-known limits.
Helm Chart Support
Helm v3 supports delivering charts packaged via OCI images. The capability to store these images is already present in Quay but the necessary configuration flags to enable OCI support and accept the Helm image type were off by default and the feature was officially designated as Technology Preview. We are now transitioning this to general availability and the features flags are set to enabled by default.
You can learn more about how this feature works in this blog post.
Quay Operator managing custom TLS certificates
Quay 3.5 brings a lot of improvements to the Operator. A particular aspect of that is enabling deployments in environments where a certificate signing service like Let’s Encrypt is used to generate trusted TLS certificates.
The Operator validates custom certificates and previously required cluster-internal domains to be part of the Subject Alternate Name (SAN) fields of the certificate to be set as well. Those domains cannot be validated by public services like Let’s Encrypt however and a certificate missing those domains would be rejected by the Operator. In 3.5 it is no longer required to provide a certificate with cluster internal domains in those fields and thus it should be easier to get trusted certificates from public or corporate-internal providers.
How to get Quay 3.5
Customers using the Quay Operator can easily update their existing 3.4 deployments by switching the channels on which the Operator is installed from, as explained in the previous blog post. The Operator automates all required update steps and only a minimal downtime is required. Customers deploying Quay manually can obtain the required container images from the Red Hat Container Catalog and follow the standalone upgrade instructions.
