Skip to content

Files

Latest commit

 

History

History
144 lines (103 loc) · 6.49 KB

rn_3_00.adoc

File metadata and controls

144 lines (103 loc) · 6.49 KB

Version 3.0.5

Release Date: August 28, 2019

Added:

  • Config flag to disable TLSv1.0 support

Fixed:

  • LDAP config error when user search results exceeds 1000 objects

  • Remove obsolete 01_copy_syslog_config.sh

  • Config tool fails to set up database when password string contains "$"

Version 3.0.4

Release Date: July 15, 2019

Fixed:

  • Package vulnerability notifications now shown in UI

  • Fixed error while deleting manifest after pushing new tag

  • Manifest now shown in UI for all types

  • CSRF rotation corrected

  • nginx access and error logs now to stdout

Version 3.0.3

Release Date: June 20, 2019

Fixed:

  • Security scan notifications endpoint not working

  • Exception raised during parallel pushes of same manifest on Postgres

  • Connection pooling was ignoring environment variable

  • Exception when in OAuth approval flow

Version 3.0.2

Release Date: May 20, 2019

Fixed:

  • Running {productname} in config mode now works in a disconnected option which doesn’t require pulling resources from the Internet.

  • {productname}'s security scan endpoint is now enabled at startup for viewing results of Clair container image scans.

  • A flaw was found in the way the DES/3DES cipher was used as part of the TLS/SSL protocol. A man-in-the-middle attacker could use this flaw to recover some plaintext data by capturing large amounts of encrypted traffic between TLS/SSL server and client if the communication used a DES/3DES based ciphersuite. (CVE-2016-2183)

Version 3.0.1

Release Date: May 13, 2019

Fixed:

  • Health API endpoint (/health/instance) now correctly checks the internal port to verify all services.

Version 3.0.0

Release Date: May 1, 2019

{productname} V3 offers the following new features:

{productname} Web UI configuration tool

A new {productname} configuration tool option within the quay image lets you create {productname} configuration files before starting a {productname} installation. The result of the configuration tool is a tarball of {productname} configuration files. Using that tarball greatly simplifies multi-instance deployments. The tarball contains the config.yaml file, and any optional files such as an SSL certificate (ssl.cert) and SSL key (ssl.key).

Choosing between the two different configuration tool options, you can either create a configuration file from scratch or modify an existing set of configuration files. In both cases, after you create the configuration, you can carry the tarball to each machine in your new {productname} cluster or apply it on an OpenShift or other Kubernetes cluster to use it to actually deploy {productname}.

The new {productname} configuration tool greatly simplifies the deployment of {productname} on OpenShift and other Kubernetes platforms. Using this tool helps you automatically deploy changes to nodes and can trigger Kubernetes blue-grean deployments of {productname} containers for configuration updates.

Support for Windows Container Images

Windows containers offer a way to run applications written for Microsoft Windows server platforms on container-enabled platforms, such as OpenShift and Kubernetes. By supporting Windows containers, {productname} V3 allows you to store your Windows containers in your {productname} registry using the same kinds of tools you use to push and pull your Linux containers.

Multi-Architecture Container Image Support

{productname} V3 now supports multi-architecture container manifests. The Docker Registry API spec v2_s2 container specification supports multi-architecture containers by adding an architecture label to the image manifest. Having this field set for a particular architecture allows images of the same architecture type to be pushed to a {productname} repository and later automatically accessed from a {productname} repository, while still requesting generic names for containers. Supported architectures IBM Power LE and z System workloads, ARM based IoT devices and Windows-based workloads.

Built on Red Hat Enterprise Linux

As part of the process of moving {productname} toward fully integrating into the Red Hat Product lineup, {productname} V3 is now delivered in a Red Hat Enterprise Linux 7.x container image. Moving {productname} into a RHEL container does not in any way change the interface or general functioning of the container, but simply allows {productname} to become better aligned with other Red Hat product offerings.

{productname} images now in redhat repo on Quay.io

{productname} images formerly stores in the quay.io/coreos repository are moving to quay.io/redhat for {productname} version 3. Available images include:

  • quay.io/redhat/quay

  • quay.io/redhat/quay-builder

  • quay.io/redhat/clair-jwt

Earlier version of quay and quay-builder images will remain on quay.io/coreos. For example, quay.io/coreos/quay:v2.9.5.

Container Images based on RHEL inherit all certification and support features from RHEL. They can also take advantage of quickly leveraging security fixes and updates as they become available in RHEL.

Changes to support running containers in unprivileged mode

Previous versions of images required running in privileged mode. To remove this restriction, container config and ports were changed.

  • clair-jwt config has moved from /config to /clair/config

  • You must update references to additional files, such as certificates, in clair-jwt’s config.

  • The quay HTTP port is now 8080. The HTTPS port is 8443.

  • If you use the proxy port on quay, it has been moved to 7443.

The move to a RHEL base image means the certificate install path has changed to /etc/pki/ca-trust/source/anchors. Examples running the images have been updated to reflect this.