A new way to access OpenShift (OKD)'s Web components from a domain different from its internal domain (base domain/installation domain)

Latest response

Hi people! =D

Here is a new way to access OpenShift (OKD)'s Web components (especially the Web Console) from a domain different from its internal domain (base domain/installation domain). There is only one small detail to make it 100%. I think this may be interesting for you, so please take a look!

NOTE I: There is no other effective answer to this on the internet... I've tried every possible channel, so I believe only Red Hat can give us an answer!
NOTE II: The deploy was made over Bare Metal/UPI (User Provisioned Infrastructure). I basically follow these steps here: Guide: Installing an OKD 4.5 Cluster.


PROCEDURES:

I found all namespaces that have routes...

[root@okd4-services okd_bare_metal]# oc get routes --all-namespaces
NAMESPACE                  NAME                HOST/PORT                                                   PATH   SERVICES            PORT    TERMINATION            WILDCARD
openshift-authentication   oauth-openshift     oauth-openshift.apps.mbr.okd.local                                 oauth-openshift     6443    passthrough/Redirect   None
openshift-console          console             console-openshift-console.apps.mbr.okd.local                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.mbr.okd.local                     downloads           http    edge/Redirect          None
openshift-ingress-canary   canary              canary-openshift-ingress-canary.apps.mbr.okd.local                 ingress-canary      8080    edge/Redirect          None
openshift-monitoring       alertmanager-main   alertmanager-main-openshift-monitoring.apps.mbr.okd.local          alertmanager-main   web     reencrypt/Redirect     None
openshift-monitoring       grafana             grafana-openshift-monitoring.apps.mbr.okd.local                    grafana             https   reencrypt/Redirect     None
openshift-monitoring       prometheus-k8s      prometheus-k8s-openshift-monitoring.apps.mbr.okd.local             prometheus-k8s      web     reencrypt/Redirect     None
openshift-monitoring       thanos-querier      thanos-querier-openshift-monitoring.apps.mbr.okd.local             thanos-querier      web     reencrypt/Redirect     None

I found all the resources related to each namespace and took note of the route configuration paths...

[root@okd4-services okd_bare_metal]# oc -n openshift-authentication get all
[...]
NAME                                       HOST/PORT                            PATH   SERVICES          PORT   TERMINATION            WILDCARD
route.route.openshift.io/oauth-openshift   oauth-openshift.apps.mbr.okd.local          oauth-openshift   6443   passthrough/Redirect   None
[root@okd4-services okd_bare_metal]# oc -n openshift-console get all
[...]
NAME                                 HOST/PORT                                        PATH   SERVICES    PORT    TERMINATION          WILDCARD
route.route.openshift.io/console     console-openshift-console.apps.mbr.okd.local            console     https   reencrypt/Redirect   None
route.route.openshift.io/downloads   downloads-openshift-console.apps.mbr.okd.local          downloads   http    edge/Redirect        None
[root@okd4-services okd_bare_metal]# oc -n openshift-ingress-canary get all
[...]
NAME                              HOST/PORT                                            PATH   SERVICES         PORT   TERMINATION     WILDCARD
route.route.openshift.io/canary   canary-openshift-ingress-canary.apps.mbr.okd.local          ingress-canary   8080   edge/Redirect   None
[root@okd4-services okd_bare_metal]# oc -n openshift-monitoring get all
[...]
NAME                                         HOST/PORT                                                   PATH   SERVICES            PORT    TERMINATION          WILDCARD
route.route.openshift.io/alertmanager-main   alertmanager-main-openshift-monitoring.apps.mbr.okd.local          alertmanager-main   web     reencrypt/Redirect   None
route.route.openshift.io/grafana             grafana-openshift-monitoring.apps.mbr.okd.local                    grafana             https   reencrypt/Redirect   None
route.route.openshift.io/prometheus-k8s      prometheus-k8s-openshift-monitoring.apps.mbr.okd.local             prometheus-k8s      web     reencrypt/Redirect   None
route.route.openshift.io/thanos-querier      thanos-querier-openshift-monitoring.apps.mbr.okd.local             thanos-querier      web     reencrypt/Redirect   None

In each route I updated the host (there are two) property to a new domain...

oc edit -n openshift-console route.route.openshift.io/console
oc edit -n openshift-console route.route.openshift.io/downloads
oc edit -n openshift-ingress-canary route.route.openshift.io/canary
oc edit -n openshift-monitoring route.route.openshift.io/alertmanager-main
oc edit -n openshift-monitoring route.route.openshift.io/grafana
oc edit -n openshift-monitoring route.route.openshift.io/prometheus-k8s
oc edit -n openshift-monitoring route.route.openshift.io/thanos-querier

In other words, I modified something like this...

apiVersion: route.openshift.io/v1
kind: Route
metadata:
[...]
spec:
  host: route-name.apps.mbr.okd.local
[...]
status:
[...]
    host: route-name.apps.mbr.okd.local
[...]

... to something like this...

apiVersion: route.openshift.io/v1
kind: Route
metadata:
[...]
spec:
  host: route-name.apps.mbr.mydomain.net
[...]
status:
[...]
    host: route-name.apps.mbr.mydomain.net
[...]

In the case of route route.route.openshift.io/oauth-openshift, we will not change it. We will create a new route for its oauth-openshift resource.

Open for editing (but we won't edit it) the route configuration for the oauth-openshift resource...

oc edit -n openshift-authentication route.route.openshift.io/oauth-openshift

... , copy its content and edit the following properties according to your reality modifing from something like this...

[...]
metadata:
[...]
  name: oauth-openshift
[...]
spec:
  host: oauth-openshift.apps.mbr.okd.local
[...]
status:
[...]
    host: oauth-openshift.apps.mbr.okd.local
[...]

... to something like this...

[...]
metadata:
[...]
  name: oauth-openshift-mydomain-net
[...]
spec:
  host: oauth-openshift.apps.mbr.mydomain.net
[...]
status:
[...]
    host: oauth-openshift.apps.mbr.mydomain.net
[...]

... and create the new route...

cat <<EOF | oc create -f -
---
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  creationTimestamp: "2021-06-25T18:45:29Z"
  labels:
    app: oauth-openshift
  name: oauth-openshift-mydomain-net
  namespace: openshift-authentication
  resourceVersion: "6304382"
  uid: 44d8fdcd-42eb-40f8-8312-789dc4bb84df
spec:
  host: oauth-openshift.apps.mbr.mydomain.net
  port:
    targetPort: 6443
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: passthrough
  to:
    kind: Service
    name: oauth-openshift
    weight: 100
  wildcardPolicy: None
status:
  ingress:
  - conditions:
    - lastTransitionTime: "2021-07-10T02:46:57Z"
      status: "True"
      type: Admitted
    host: oauth-openshift.apps.mbr.mydomain.net
    routerCanonicalHostname: apps.mbr.okd.local
    routerName: default
    wildcardPolicy: None
EOF

PROBLEM:

The Web Console and its components ("alertmanager", "grafana", "prometheus", etc) always redirect to this URL...

https://oauth-openshift.apps.mbr.okd.local

... when login is required.

NOTE: The "okd.local" is the cluster's base domain (installation).

Is it possible to configure them to calling another URL? Like this URL below?

https://oauth-openshift.apps.mbr.domain.my

PLUS I: As I said in other spaces of our community, it is very common to have cases where the external domain (internet, WAN) of a company is different from its internal domain (private, LAN) or even cases where a company has several domains (eg: company.com , company.org, company.net...). So I say again that not being able to make web resources (especially the Web Console) work in a domain other than its internal domain is something that can become dramatic if we try to expose OpenShift (OKD) to external access (internet, WAN) a cluster already in use if its internal domain (eg: okd.local) has no external equivalent.

PLUS II:
I - We've already tried this procedure Customizing the web console URL , but it doesn't update all routes and does not update URLs in the Web Console and also has the same login issues above;
II - I also tried this procedure Creating a route through an Ingress object , but equally it doesn't seem to me something that will solve the problems pointed out.

PLUS III: Some discussions directly linked to this thread...
OpenShift/OKD cluster - Use with external/outside domain
A new and (almost) effective way to update routes and allow external access.


Thanks! =D

Responses