Deploying a Cloudera AI Workbench with support for TLS

You can provision a Cloudera AI Workbench with TLS enabled both on Cloudera Embedded Container Service and on OpenShift Container Platform (OCP), so that it can be accessed via https.

You need to obtain a certificate from the Certificate Authority used by your organization. This may be an internal certificate authority. Additionally, you need a computer with CLI access to the cluster, and with kubectl installed.

The workbench subdomain is either the static subdomain the user elects or it can also be a workbench endpoint name that the deployment autogenerates. Also note that app_domain is defined at the Data Services deployment.

A workbench name has the following format: https://[***WORKSPACE-SUBDOMAIN***].APPS.[***APP_DOMAIN***].com.

Workloads created in a Cloudera AI Workbench are containers provisioned in Kubernetes and must be addressable to the user. To do this, Cloudera AI creates a unique subdomain.

The URL for the workload is structured as: https://[***WORKLOAD-ENDPOINTS***].[***WORKSPACE-SUBDOMAIN***].APPS.[***APP_DOMAIN***].com.

As the workload endpoints are randomly generated, for TLS to work, a Cloudera AI Workbench needs to have a wildcard SAN entry in the TLS certificate and additionally we need a workbench subdomain SAN as well:

Wildcard SAN entry: SAN:*.[***WORKSPACE-SUBDOMAIN***].APPS.[***APP_DOMAIN***].com.

Workspace subdomain SAN: [***WORKSPACE-SUBDOMAIN***].APPS.[***APP_DOMAIN***].com.

See the following example for creating a Cloudera AI Workbench with static subdomain in Cloudera Embedded Container Service environment:

the user's domain is: mycompany.com (user-provided)
a non-HA deployment's master's hostname is: ecsmst01 (inherits hostname)
the user's control plane deployment is: cdp-dev (user-provided)
the user's load-balanced endpoint for the control plane deployment is: cdp-lb (user-provided)
the apps subdomain is hard-coded as: apps (hardcoded)
the Cloudera AI Workbench ID is generated as: ml-1234abc-123 (auto-generated)
the Cloudera AI static subdomain is set as: cmlstatic (user-provided)

With the above details, consider the following examples:

Table 1. Cloudera AI Workbench environment examples
Network topology	Domain set	Example
Control Plane	High Availability (HA)	HA: app_domain = cdp-lb.mycompany.com
	High Availability (HA)	HA applications: *.apps.cdp-lb.mycompany.com
	Non-HA, with custom deployment domain set	non-HA with the custom Cloudera Embedded Container Service domain: app_domain = cdp-dev.mycompany.com
	Non-HA, with custom deployment domain set	non-HA with the custom Cloudera Embedded Container Service applications: *.apps.cdp-dev.mycompany.com
	Non-HA, with no custom deployment domain set	non-HA without custom Cloudera Embedded Container Service domain: app_domain = ecsmst01.mycompany.com
	Non-HA, with no custom deployment domain set	non-HA without custom Cloudera Embedded Container Service domain applications: .apps.ecsmst01.mycompany.com.
Cloudera AI Workbench without static subdomain	High Availability (HA)	Cloudera AI Workbench on HA Cloudera Embedded Container Service without static subdomain: [*.]ml-1234abc-123.apps.cdp-lb.mycompany.com
	Non-HA with user's domain	Cloudera AI Workbench on non-HA Cloudera Embedded Container Service without custom Cloudera Embedded Container Service domain without Cloudera AI Workbench static subdomain: [*.]ml-1234abc-123.apps.cdp-dev.mycompany.com
	Non-HA without user's domain	Cloudera AI Workbench on non-HA Cloudera Embedded Container Service without custom Cloudera Embedded Container Service domain without Cloudera AI Workbench static subdomain: [*.]ml-1234abc-123.apps.ecsmst01.mycompany.com
Cloudera AI Workbench with static subdomain	High Availability (HA)	Cloudera AI Workbench on HA Cloudera Embedded Container Service with Cloudera AI Workbench static subdomain: [*.]cmlstatic.apps.cdp-lb.mycompany.com
	Non-HA with user's domain	Cloudera AI Workbench on non-HA Cloudera Embedded Container Service with custom Cloudera Embedded Container Service domain with Cloudera AI Workbench static domain: [*.]cmlstatic.apps.cdp-dev.mycompany.com
	Non-HA without user's domain	Cloudera AI Workbench on non-HA Cloudera Embedded Container Service without custom Cloudera Embedded Container Service domain with Cloudera AI Workbench static domain: [*.]cmlstatic.apps.ecsmst01.mycompany.com

By using unique subdomains, the Cloudera AI Workbench is able to securely serve each interactive workload with proper isolation and protect it from code injection attacks such as Cross Site Scripting.

Provision the Cloudera AI Workbench.

Follow the procedure in Provisioning an Cloudera AI Workbench.

note
Ensure you select Enable TLS.
Obtain the .crt and .key files for the certificate from your Certificate Authority.
The certificate URL follows the following format: [***WORKSPACE-SUBDOMAIN***].APPS.[***APP_DOMAIN***].com
Example
An example URL for the certificate shall be as: cml.apps.cdp.mycompany.com.
Check that the certificate shows the corresponding Common Name (CN) and Subject Alternative Names (SAN) correctly:
- CN: cml.apps.cdp.mycompany.com
- SAN: *.cml.apps.cdp.mycompany.com
- SAN: cml.apps.cdp.mycompany.com
note
If you want to install a new signed certificate, you must regenerate a new certificate from your Certificate Authority. It is not possible to secure multi-level subdomains with a single wildcard certificate. If a wildcard certificate is issued for *.company.com, it can secure only the first-level subdomains of *.company.com. If you want to secure another subdomain, *.sub1.company.com, you will need another wildcard certificate for *.sub1.company.com.
Create a Kubernetes secret inside the previously provisioned Cloudera AI Workbench namespace.
- Embedded Container Service
- OpenShift Container Platform
The certificate is automatically uploaded. Login to the Cloudera Embedded Container Service to accomplish these steps:

cd /opt/cloudera/parcels/Cloudera Embedded Container Service/bin/

./cml_utils.sh -h
Optional: A helper prompt appears, with explanation for the next command.

./cml_utils.sh upload-cert -n [***NAMESPACE***] -c <path_to_cert> -k <path_to_key>
For example: ./cml_utils.sh upload-cert -n bb-tls-1 -c /tmp/ws-cert.crt -k /tmp/ws-key.key
note
To find the [***NAMESPACE***] of the workbench, go to the Cloudera AI Workbenches UI, and in the Actions menu for the workbench, select View workbench Details. Namespace is shown on the Details tab.
Name the secret cml-tls-secret.

Run this command on a machine with access to the .crt and .key files, and access to the cluster: kubectl create secret tls cml-tls-secret --cert=<pathtocrt.crt> --key=<pathtokey.key> -o yaml --dry-run | kubectl -n [***CML WORKSPACE-NAMESPACE***] create -f -
You can replace or update certificates in the secret at any time.
In Site Administration > Security > Root CA configuration, add the root CA certificate to the workbench.
For example: https://cml.apps.cdp.mycompany.com.

The procedure creates routes to reflect the new state of ingress and secret, and enables TLS.