Epic Goal

• Address security concerns of customers by alleviating the need to allow traffic to the quay.io domain to install / mirror OpenShift and related images

Why is this important?

• Today the entire OCP payload is pulled directly from quay.io, this requires customers to add an exception for the quay.io domain and all subdomains (cdn*.quay.io) to their firewall / proxy
• Adding *.quay.io to the allow list of a firewall / proxy opens up usage of all of quay.io's content, not just OpenShift, which is generally trusted at the same level of content from DockerHub, which on-premise customers often block
• quay.io is not generally associated with a Red Hat domain property and therefor less trusted, customers expect to be able to allow traffic to redhat.com and/or redhat.io in order for our connected products to work
• quay.io CDN uses AWS CloudFront as the CDN which certificates are signed by AWS for AWS which further fragments the different properties customers need to trust in order to install OpenShift

Background

• registry.redhat.io is a reverse proxy effective for a couple of quay.io namespaces already and allows to transparently pull through that domain, including fronting the CDN that quay.io uses (alleviates adding CDN endpoints to the allow-list)

Scenarios

1. All OpenShift core images need to be able to be pulled via registry.redhat.io
2. All OpenShift core images pull spec references in the OpenShift payload need to refer to their images via registry.redhat.io
3. All OpenShift optional Red Hat Operators need to be able to be pulled via registry.redhat.io
4. All OpenShift optional Red Hat Operators need to refer to their related images via registry.redhat.io

Acceptance Criteria

• Customers can install OpenShift Container Platform and optional Red Hat Operators without the need to add quay.io or any of its subdomains to a allow-list in firewalls / proxy configuration
• quay.io uses AWS CloudFront as the CDN, so registry.redhat.io would need to proxy that as well
• quay.io responds with pre-signed AWS S3 blob URLs when clients ask to pull images, thus S3 also needs to be proxied by registry.redhat.io
• quay.io/openshift-release-dev/ocp-release and quay.io/openshift-release-dev/ocp-v4.0-art-dev repos continue to be the source of truth for OCP, and registry.redhat.io/openshift-release-dev (or similar namespace) simply serves as a proxy for the content.
• All hostnames involved resolve to IP addresses which are lifecycle managed
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ART
2. CPaaS

Previous Work (Optional):

1. registry.redhat.io already proxies a lot of operator-related images that are physically stored on quay.io

Open questions

1. should we rather implement selective story proxying in Quay so that registry.redhat.io doesn't need to proxy all AWS S3 endpoints?

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>