Creating an Ingress resource to use your own TLS certificates

When you deploy IBM® Business Automation Insights in Kubernetes, use your own TLS certificates to expose IBM Business Automation Insights services on the Ingress controller.

About this task

When you deploy IBM Business Automation Insights in Kubernetes, exposing services by using your own TLS certificates involves the following steps.

Set the services type to ClusterIP.
Choose the host names to provide access to the services.
Provide SSL/TLS certificates that match the host names and package them as Kubernetes secrets.
Create your own Ingress resource to expose the ClusterIP services on the host names that you have chosen.

When you deploy IBM Business Automation Insights, three Kubernetes services are created: the IBM Business Automation Insights administration REST API and --if you use embedded Elasticsearch and Kibana rather than an external Elasticsearch installation-- the Elasticsearch REST API and Kibana.

In previous releases, IBM Business Automation Insights services are exposed through a Kubernetes Ingress resource that uses self-signed certificates.

In version 18.0.2, IBM Business Automation Insights provides no Ingress anymore. When you deploy IBM Business Automation Insights, the services are exposed by default as NodePort services.

The three services must be accessed through HTTPS and are protected by self-signed TLS certificates. However, this practice is not a safe in a production environment. Therefore, whichever IBM Business Automation Insights version you work with, you must create your own Ingress and use the HTTPS protocol with your own set of trusted certificates. To do so, you set IBM Business Automation Insights services to the ClusterIP service type and, from the Ingress resource that you create, you reference the ClusterIP services.

Changing the service type to ClusterIP

About this task

To prevent endpoints that are protected with self-signed certificates to be exposed externally, you must change the services type to ClusterIP.

Procedure

If you are updating an existing IBM Business Automation Insights deployment where services are already deployed as NodePort services, first delete the Kubernetes services manually.
```
kubectl delete service <release-name>-bai-admin-service
```
```
kubectl delete service <release-name>-ibm-dba-ek-client
```
```
kubectl delete service <release-name>-ibm-dba-ek-kibana
```
Set the following Helm parameters to ClusterIP.
- admin.serviceType: ClusterIP
- ibm-dba-ek.elasticsearch.client.serviceType: ClusterIP
- ibm-dba-ek.kibana.serviceType: ClusterIP
See also Configuration parameters.
Update the IBM Business Automation Insights release as shown in Updating your Business Automation Insights deployment.

Using IBM Cloud Private 3.1 Ingress controller

About this task

To expose the Kubernetes services, you choose host names, provide TLS/SSL certificates, and create secrets. Then, you create the Ingress resource.

Procedure

Decide which host names to use.
Pick a different hostname for each service that you want to expose on the Ingress. Each host name you choose must refer to the IBM Cloud Private master node IP.
Provide a TLS/SSL certificate for each host name.
Package each certificate in a Kubernetes secret, as documented in the TLS page of the Kubernetes documentation.

Create the Ingress resource.

The example uses the following conventions.

The administration REST API is set to be exposed on the admin.bai.mycluster.icp host name and the matching SSL/TLS certificate is packaged in the bai-ingress-admin-tls secret.
The Elasticsearch REST API is set to be exposed on the es.bai.mycluster.icp host name and the matching SSL/TLS certificate is packaged in the bai-ingress-es-tls secret.
Kibana is set to be exposed on the kibana.bai.mycluster.icp host name and the matching SSL/TLS certificate is packaged in the bai-ingress-kibana-tls secret.
The Helm release is named my-helm-release and is deployed in the bai namespace.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: bai-ingress
 namespace: bai
 annotations:
   ingress.kubernetes.io/ssl-passthrough: "false"
   ingress.kubernetes.io/secure-backends: "true"
spec:
 tls:
 - hosts:
   # fully-qualified domain name of the BAI admin REST service
   - admin.bai.mycluster.icp
   secretName: bai-ingress-admin-tls
 - hosts:
   # fully-qualified domain name of the Elasticsearch service
   - es.bai.mycluster.icp
   secretName: bai-ingress-es-tls
 - hosts:
   # fully-qualified domain name of the Kibana service
   - kibana.bai.mycluster.icp
   secretName: bai-ingress-kibana-tls
 rules:
   # each server block redirects requests to its own backend service
 - host: admin.bai.mycluster.icp
   http:
     paths:
     - backend:
         serviceName: my-helm-release-bai-admin-service
         servicePort: 6892
 - host: es.bai.mycluster.icp
   http:
     paths:
     - backend:
         serviceName: my-helm-release-ibm-dba-ek-client
         servicePort: 9201
 - host: kibana.bai.mycluster.icp
   http:
     paths:
     - backend:
         serviceName: my-helm-release-ibm-dba-ek-kibana
         servicePort: 5602

Note:

The ingress.kubernetes.io/ssl-passthrough parameter must be set to false to ensure that the Ingress certificate is the one exposed.
The ingress.kubernetes.io/secure-backends parameter must be set to true for the Ingress controller to access the ClusterIP services over HTTPS.

Results

You can now access the services through HTTPS URLs.

Table 1. HTTPS URLs for ClusterIP services
Service	URL for 18.0.0 and 18.0.1	URL for 18.0.2
Administration REST API	https://admin.bai.mycluster.icp/	https://admin.bai.mycluster.icp/
Elasticsearch REST API	https://es-ibm-dba-ek-client/elasticsearch-ibm-dba-ek-my-helm-release/	https://es-ibm-dba-ek-client/
Kibana	https://kibana.bai.mycluster.icp/kibana-ibm-dba-ek-my-helm-release/	https://kibana.bai.mycluster.icp/