Routing OpenShift Component Routes through a custom domain with Google Cloud Armor

This guide extends Using Google Cloud Armor with a Secondary IngressController on OpenShift Dedicated (GCP) to securely route the OpenShift console, downloads, and OAuth endpoints through Cloud Armor. By the end of this guide, users will access the OpenShift web console, downloads server, and OAuth authentication through the Cloud Armor-protected HTTPS Load Balancer.

Prerequisites

Complete the Cloud Armor with Secondary IngressController guide through at least Step 14 (Test the Configuration). You should have:

• A working Cloud Armor HTTPS Load Balancer with a secondary private cloudarmor IngressController
• The hello test application responding through Cloud Armor
• DNS configured for *.${INGRESS_NAME}.${DOMAIN} pointing to the Cloud Armor static IP
• A wildcard TLS certificate for *.${INGRESS_NAME}.${DOMAIN}

You will also need:

• The ocm CLI logged in to your Red Hat account (ocm whoami to verify)

1. Set Environment Variables

If continuing from the Cloud Armor guide, these variables should already be set. Otherwise, set them now:

2. Get OCM Cluster and Ingress IDs

Retrieve the OCM cluster ID and default ingress ID. These are needed to configure component routes through ocm.

Get the default ingress ID:

The default ingress (marked true) is the one you need. For example, v3p7. Set it:

3. Create TLS Secrets for Component Routes

Component routes require TLS secrets in the openshift-config namespace. Create secrets for console, downloads, and OAuth using the same wildcard certificate from the Cloud Armor guide:

Verify the secrets were created:

4. Configure Component Routes via OCM

Use ocm edit ingress to set custom hostnames and TLS secrets for the console, downloads, and OAuth component routes. All three components must be specified in a single command:

This updates the ingresses.config.openshift.io/cluster resource, which tells the console and authentication operators to create routes with the custom hostnames. Wait a minute for the operators to reconcile, then verify the routes were created:

You should see console-custom and downloads-custom in openshift-console, and the existing oauth-openshift route in openshift-authentication.

5. Label Console and Downloads Routes

The operator-managed console-custom and downloads-custom routes need the type=cloudarmor label so the cloudarmor IngressController admits them:

Verify the routes are admitted by the cloudarmor IngressController:

6. Create OAuth Reencrypt Route

The authentication operator creates the OAuth route with passthrough TLS termination. Passthrough routes forward raw TLS directly to the backend pod. This is incompatible with the Cloud Armor HTTPS Load Balancer, which terminates TLS at the Google edge and opens a new HTTPS connection to the backend. When the terminated connection reaches the OpenShift router, there is no raw TLS stream to pass through.

The solution is a reencrypt route. The reencrypt route terminates TLS at the router (accepting the LB’s re-encrypted connection) and opens a new TLS connection to the OAuth pod on port 6443, verifying the pod’s certificate using the service-serving-signer CA.

Extract the service-serving-signer CA:

Create the reencrypt route:

Label the route for the cloudarmor IngressController:

7. Verify Component Routes

Test each component route through Cloud Armor:

Open the console in an incognito/private browser window:

Clicking Log in should redirect to the OAuth endpoint at oauth.<INGRESS_NAME>.<DOMAIN>, authenticate, and return you to the console.

Cleanup

To remove the component route configuration while keeping the base Cloud Armor setup intact:

To remove all Cloud Armor resources including the base setup, follow the cleanup steps in the Cloud Armor guide .

References

• Cloud Armor with Secondary IngressController
• Updating OSD Component Routes
• Google Cloud Armor Documentation
• OpenShift IngressController Documentation