OpenShift Outbound URLs to Allow

Solution Verified - Updated -

Environment

  • Red Hat OpenShift Container Platform (RHOCP)
    • 3.x
    • 4.x

Issue

  • To what URLs does an OpenShift cluster need to access?
  • Which URLs need to be allowed on the OCP HTTP proxy?

Resolution

  • For OpenShift 4, review Configuring your firewall section in addition to this article.

  • The outbound depends on the language and frameworks used in OpenShift.

  • OpenShift depends on the Red Hat registry, which provides the basic pod images, registry image, and router image.

  • Below is the list of the recommended URLs to be allowed on firewall or proxy:

    • Registries:
     - registry.access.redhat.com (provides pod, registry, router, s2i, jboss and etc images)
     - registry.redhat.io 
     - registry.connect.redhat.com (provides third-party images)
     - quay.io
     - *.quay.io
     - storage.googleapis.com/openshift-release
     - sso.redhat.com
     - docker.io (images not in Red Hat's registry)
     - docker.com
     - hub.docker.com
     - index.docker.io
  • Depending on your firewall you may need to add this to be able to download image blobs:
     - oso-rhc4tp-docker-registry.s3-us-west-2.amazonaws.com (CNAME)
     - s3-us-west-2-r-w.amazonaws.com
  • Source code repositories (allow the ones that apply):
     - github.com
     - gitlab.com
     - Internal git repository hostnames
  • Language/framework related resources (allow the ones that apply)
*.maven.org
*.apache.org
*.npmjs.com
*.openshift.io
*.openshift.org
*.docker.io
*.docker.org
*.rubygems.org
*.cpan.org
*.githubusercontent.com
*.githubapp.com
*.cloudfront.net
*.fabric8.io
*.codehaus.org
*.sonatype.org
*.jboss.org
*.jenkins-ci.org
*.jenkins.io
*.bintray.com
*.spring.io
*.eclipse.org
*.fusesource.com
*.eclipse.org
*.quay.io
  • When registering RHEL hosts with subscription manager, it needs to access the subscription url [1] and has to have access the redhat repos atomic-openshift-* and docker-*. The OpenShift could be installed without connection to the internet, but pod, registry, and router images must be available in the custom registry or available on hosts.

[1] https://access.redhat.com/solutions/65300
[2] https://access.redhat.com/articles/1525183

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

9 Comments

Not mentioned in the solution above: outbound connections are tcp/443 (aka HTTPS).

how come these are not on the list? cloud.redhat.com:443 cert-api.cloud.redhat.com:443 api.cloud.redhat.com:443 Infogw.api.openshift.com:443

confirmed that cert-api.cloud.redhat.com:443 api.cloud.redhat.com:443 are not needed. It was a documentation error.

So is there any documentation/reference that can be used that lists required URLs to be opened for standing up OCP 4.1? I do appreciate above is list of recommended URLs, but for strict/security driven environments we need to justify every single one of them. We've opened up the ones from official documentation, which as per your comment appears to be documentation error? These were also not sufficient as installer require *.cloudfront.net and it failed on that. So really looking for minimum list required to stand up vanilla cluster - we can expand url's further based on development teams requirement.

IHAC asks why do we need *.cloudfront.net? Anyone knows?

That's the first one we hit which wasn't in the docs. When the bootstrap node tries to download ocp-release from quay.io on the first boot, it accessed xxx.cloudfront.net when "parsing image configuration".

It looks like mirror.openshift.com and storage.googleapis.com are required for the CVO to perform updates

also akamaiedge.net is needed, can you please update, any redirection or CDN that is needed should be also in the list.

Also, which nodes on openshift would require such access? can we limit it only to master nodes if possible, or bastion host? we do not want to open access for all

Hi Remember, that if you use proxy for install and update, manage etc you Openshift cluster, you should set on proxy bypassing SSL decryption for most of this URLs