Configuring a cluster-wide proxy

If you are using an existing Virtual Private Cloud (VPC), you can configure a cluster-wide proxy during cluster installation or after the cluster is installed. When you enable a proxy, the core cluster components are denied direct access to the internet, but the proxy does not affect user workloads.

Note

Only cluster system egress traffic is proxied, including calls to the cloud provider API.

If you use a cluster-wide proxy, you are responsible for maintaining the availability of the proxy to the cluster. If the proxy becomes unavailable, then it might impact the health and supportability of the cluster.

Prerequisites for configuring a cluster-wide proxy

To configure a cluster-wide proxy, you must meet the following requirements. These requirements are valid when you configure a proxy during installation or postinstallation.

General requirements

• You are the cluster owner.

• Your account has sufficient privileges.

• The proxy can access the VPC for the cluster and the private subnets of the VPC. The proxy must also be accessible from the VPC for the cluster and from the private subnets of the VPC.

• You have added the following endpoints to your VPC endpoint:

  • ec2.<aws_region>.amazonaws.com

  • elasticloadbalancing.<aws_region>.amazonaws.com

  • s3.<aws_region>.amazonaws.com

    These endpoints are required to complete requests from the nodes to the AWS EC2 API. Because the proxy works at the container level and not at the node level, you must route these requests to the AWS EC2 API through the AWS private network. Adding the public IP address of the EC2 API to your allowlist in your proxy server is not enough.

    Important

    When using a cluster-wide proxy, you must configure the s3.<aws_region>.amazonaws.com endpoint as type Gateway.

Network requirements

If your proxy re-encrypts egress traffic, you must create exclusions to several domain and port combinations required by OpenShift.

Your proxy must exclude re-encrypting the following OpenShift URLs:

Table 1. URLs to exclude from egress traffic re-encryption

Address	Protocol/Port	Function
observatorium-mst.api.openshift.com	https/443	Required. Used for Managed OpenShift-specific telemetry.
sso.redhat.com	https/443	The https://console.redhat.com/openshift site uses authentication from sso.redhat.com to download the cluster pull secret and use Red Hat SaaS solutions to facilitate monitoring of your subscriptions, cluster inventory, and chargeback reporting.

Responsibilities for additional trust bundles

If you supply an additional trust bundle, you are responsible for the following requirements:

• Ensuring that the contents of the additional trust bundle are valid

• Ensuring that the certificates, including intermediary certificates, contained in the additional trust bundle have not expired

• Tracking the expiry and performing any necessary renewals for certificates contained in the additional trust bundle

• Updating the cluster configuration with the updated additional trust bundle

Configuring a proxy during installation

Configuring a proxy after installation