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 through https.

You must obtain a certificate from the Certificate Authority used by your organization. This might be an internal certificate authority. Additionally, you must have 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://[***WORKBENCH-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 in the following format: https://[***WORKLOAD-ENDPOINTS***].[***WORKBENCH-SUBDOMAIN***].apps.[***APP_DOMAIN***].com.

As the workload endpoints are randomly generated, for TLS to work, a Cloudera AI Workbench must have a wildcard SAN entry in the TLS certificate and additionally the workbench subdomain SAN must also be provided.

The wildcard SAN entry has the following format: SAN:*.[***WORKBENCH-SUBDOMAIN***].apps.[***APP_DOMAIN***].com.

The workbench subdomain SAN has the following format: [***WORKBENCH-SUBDOMAIN***].apps.[***APP_DOMAIN***].com.

The following elements can be used for creating a Cloudera AI Workbench with static subdomain in Cloudera Embedded Container Service environment:

Table 1. Creating a Cloudera AI Workbench with static subdomain in Cloudera Embedded Container Service
Element	Example value	Origin
User domain	mycompany.com	User-provided
Non-HA deployment master hostname	ecsmst01	Inherited hostname
User control plane deployment	cdp-dev	User-provided
User load-balanced endpoint for the control plane deployment	cdp-lb	User-provided
Application subdomain	apps	Hardcoded
Cloudera AI Workbench ID	ml-1234abc-123	Auto-generated
Cloudera AI static subdomain	cmlstatic	User-provided

With the provided details, the following examples can be created:

Table 2. 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 the user 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 the user 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 the user 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 the user 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 each workload from code injection attacks such as Cross Site Scripting.

Provision the Cloudera AI Workbench.

Follow the procedure in Provisioning a Cloudera AI Workbench.

note
Ensure you select the Enable TLS option.
Obtain the .crt and .key files for the certificate from your Certificate Authority.
The certificate URL has the following format: [***WORKBENCH-SUBDOMAIN***].apps.[***APP_DOMAIN***].com
Example
This example shows an URL for the certificate: cml.apps.cdp.mycompany.com.
Check that the certificate shows the corresponding Common Name (CN) and Subject Alternative Names (SAN) correctly. In this example, the following CN and SANs can be used:
- 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. Multi-level subdomains cannot be secured 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, for example *.sub1.company.com, you must have another wildcard certificate for the*.sub1.company.com subdomain.
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 run the following commands:

cd /opt/cloudera/parcels/ECS/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 the View workbench Details option. 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 WORKBENCH-NAMESPACE***] create -f -
You can replace or update certificates in the secret at any time.
Upload the root CA certificate to Site Administration > Security > Root CA configuration, unless it was already uploaded to Management Console > Settings > CA Certificates > Miscellaneous before provisioning a Cloudera AI Workbench.

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