Configuring external access

There are three mechanisms by which you can define external access to your Operational Decision Manager instances in a Certified Kubernetes cluster.

OpenShift routes

The Red Hat® OpenShift Container Platform (OCP) uses the concept of route to direct external traffic to applications deployed on a cluster.

You can delegate the route registration to the Helm chart by creating the routes automatically.

To automate the creation of the routes, set the following chart parameters:

• service.enableRoute=true
• service.enableTLS=true (default value)
• service.type=ClusterIP

In addition, you can specify the hostname that is used by the created routes by setting the service.hostname parameter. If this parameter is empty, OpenShift automatically generates a hostname of the form <route-name>.<suffix>, where the hostname suffix is the default routing subdomain of your cluster, according to the OpenShift documentation .

OpenShift uses the Ingress Operator to create an internal certificate authority (CA) and issue a wildcard certificate that is valid for applications under the .apps sub-domain. Both the web console and the command line interface (CLI) use this certificate. For more information, see Replacing the default ingress certificate

If you deploy an Operational Decision Manager instance with the default self-signed certificate, you might get a certificate validation error when you try to invoke an Operational Decision Manager runtime service from a Java™ application:

An error occurred obtaining a list of services from the specified URL. CWTBG0019E: Unexpected exception during execution. Exception information: 'Certificate for <ds-runtime-odm-helm.apps.X.X.X.X.nip.io> doesn't match any of the subject alternative names: []'

To avoid this error, the Operational Decision Manager route must expose the OpenShift Router Certificate. You can get the Transport Layer Security (TLS) private key (tls.key) and public key (tls.crt) of the OpenShift Router Certificate from the router-certs-default secret of the openshift-ingress project, or through the following command line:

oc get secret router-certs-default -n openshift-ingress -o "jsonpath={.data['tls\.crt']}" | base64 -d > tls.crt
oc get secret router-certs-default -n openshift-ingress -o "jsonpath={.data['tls\.key']}" | base64 -d > tls.key

Then follow the instructions in Defining the security certificate to use these keys in the Operational Decision Manager container.

If you browse both the Business console and Rule Execution Server console in the same window, you might reach the wrong console and it might fail to respond correctly.

This situation occurs under the following conditions:

• The consoles are behind passthrough routes, which are the default TLS termination when routes are created by the Helm chart.
• The consoles are configured to use a TLS key pair by using customization.securitySecretRef, whose certificate is created with a subjectAltName extension that matches the URL of both console routes, either from a wildcard or a listing of both URLs.
• This certificate is trusted because it either has a signed trusted certificate authority or is self-signed but was marked as trusted in the system or in the browser.

This problem occurs because the browser reuses the same HTTP/2 connection when connecting to the two consoles.

If a new private window is opened to access the second console, or a different browser used, the expected content is shown.

The solution however is to create reencrypt routes.

Here is an example how to create reencrypt routes:

CONSOLES_URL=odm-consoles-${NAMESPACE}.apps.${CLUSTER_FQN}

oc create route reencrypt dsc-common-route \
    --service=${RELEASE}-odm-decisionserverconsole \
    --path=/res \
    --port=443 \
    --hostname=${CONSOLES_URL} \
    --cert=tls.crt --key=tls.key \
    --dest-ca-cert=odm-tls.crt

oc create route reencrypt dc-common-route \
    --service=${RELEASE}-odm-decisioncenter \
    --path=/decisioncenter \
    --port=443 \
    --hostname=${CONSOLES_URL} \
    --cert=tls.crt --key=tls.key \
    --dest-ca-cert=odm-tls.crt 

This example uses the following parameters:

• tls.crt and tls.key are the certificate and private key of the ingress controller for the routes (see how to retrieve those files above).
• odm-tls.crt is the certificate used to configure TLS in Operational Decision Manager by using customization.securitySecretRef.

Learn more about reencrypt routes at OpenShift documentation .

Ingress

Kubernetes Ingress controllers are the original mechanism for exposing your cluster to external access. Each controller implementation is platform-specific.

For more information about Ingress, see the Kubernetes documentation .

For more information about Ingress on OpenShift, see Configuring ingress cluster traffic using an Ingress Controller .

To add Ingress to Operational Decision Manager services, delegate the Ingress and associated routes registration to the Helm chart by creating the Ingress automatically, as described below.

1. Create a secret (ingress-tls) from a key and a digital certificate file for the Ingress front end.
2. Set the following chart parameters.
   • service.enableTLS=true (default value)
   • service.type=ClusterIP
   • service.ingress.enabled=true
   • service.ingress.host=dev.mycompany.com
   • service.ingress.tlsHosts=dev.mycompany.com
   • service.ingress.tlsSecretRef=ingress-tls
   • service.ingress.annotations=<annotation list> (optional, depends on the platform)
3. Declare the domain name *.mycompany.com in the Domain Name System (DNS) infrastructure.

NodePort

A NodePort service is exposed on each node IP at a non-standard static port (default range: 30000-32767). NodePort is a simple way to expose external access to a workload for initial development and testing. However, NodePort entails extra security concerns and is hard to manage from both an application and a networking infrastructure perspective.

NodePort is the default configuration.

In addition to these three options, you can configure an extra path, which is called the context root, to access the Operational Decision Manager web applications.

For example, to use the OpenShift routes access option and the context root for the Decision Server console, code as follows:

service.enableRoute=true
decisionServerConsole.contextRoot="/devres"
service.enableTLS=true (default value)
service.type=ClusterIP