Configuring Application-level TLS¶

Application-level TLS is required for service-to-service communications within the DataRobot application, in order for authentication materials to be transmitted over a securely encrypted channel.

This includes gRPC-based Service API calls, but does not include TLS for Ingress, Persistent Critical Services (PCS), or connections to external resources outside the cluster.

When configured, TLS certificates will be generated at deploy time for clients and servers, stored as Secrets in Kubernetes and mounted into each service's containers. The CA certificate used for signing these keys will be provided and configured as well, in order to support both Public CA and Private CA use cases.

Alternatively, it is possible to configure Application-level TLS without cert-manager. This is suitable for customers who wish to avoid installing and managing cert-manager, and would like extra control over managing the CA and TLS certificates within the cluster. When using a custom CA issuer, some manual steps are required to setup the CA certificate bundle but generation of TLS certificates is automated as part of the Helm release of DataRobot. Please note that certificate renewal and rotation is not automated and would be the customer's responsibility to manage which will require cluster downtime.

(Option 1) Configuring TLS with cert-manager¶

Follow the cert-manager Installation Guide. We recommend the Helm install option. Version 1.13 has been tested with our application, although newer versions are expected to work as well.

The Helm chart will install cert-manager into the cert-manager namespace. This requires installing some ClusterRoles for RBAC, and several custom resources such as Certificate.

Application-TLS supports both a ClusterIssuer or a namespace-scoped Issuer that coexists with the DataRobot install.

Namespace-scoped Issuer¶

We recommend a namespace-scoped Issuer which has limited scope, and will be installed automatically by the DataRobot umbrella charts.

Update the values.yaml configuration:

global:
  applicationTLS:
    issuerType: Issuer
    issuerName: sdtk-ca
    caCertDuration: "8760h" # 365d (default)
    caCertRenewBefore: "720h" # 30d (default)

The issuerName is configurable, as well as the CA cert duration and renewal frequency.

When installed, the following resources will be created:

An Issuer named sdtk-ca used at deploy time for issuing certificates.
An Issuer named sdtk-ca-bootstrap-issuer which is self-signed root authority for the sdtk-ca issuer. This should not be used directly but is necessary for establishing the root trust chain.
A Secret named sdtk-ca-secret containing the CA certificate and private key used for signing.

ClusterIssuer¶

If using a ClusterIssuer, an issuer must be created before the DataRobot umbrella charts are installed. You may configure this issuer according to your needs, with either a Public CA or Private CA.

Update the values.yaml configuration:

global:
  applicationTLS:
    issuerType: ClusterIssuer
    issuerName: datarobot-sdtk-ca

Specify the issuerName to correspond to the existing ClusterIssuer.

The caCertDuration and caCertRenewBefore settings are not applicable.

No additional resources need to be installed into the DataRobot namespace since these cluster-level resources are generally installed elsewhere (e.g. cert-manager namespace).

(Option 2) Configuring TLS with a Custom Certificate Authority (CA)¶

With this option, skip the cert-manager installation.

You will need to create your own CA using some simple commands and store as a secret in Kubernetes.

IMPORTANT!: The CA secret must be created before the DataRobot Helm release, otherwise the TLS secrets created at deploy time will not pick up the CA correctly and result in TLS verification issues within the cluster.

Creating the CA cert¶

Create the CA private key

Create ca.key using:
```
openssl genpkey -algorithm RSA -out ca.key -aes256 
```
You will be prompted to input a passphrase for the key which must be between 4-1023 characters.
Create the CA self-signed certificate

Create ca.crt using:
```
openssl req -new -x509 -key ca.key -out ca.crt -days 1095 -subj "/C=US/ST=Massachusetts/L=Boston/O=SomeExampleOrg/OU=EngineeringDept/CN=Example CA" 
```
where:
- /C=: Country Name (2 letter code, e.g., "US" for the United States)
- /ST=: State or Province Name (full name, e.g., "Massachusetts")
- /L=: Locality Name (e.g., city, "Boston")
- /O=: Organization Name (e.g., "SomeExampleOrg")
- /OU=: Organizational Unit Name (e.g., "EngineeringDept")
- /CN=: Common Name (e.g., "Example CA")

Inspect the CA certificate

openssl x509 -in ca.crt -text -noout

will output certificate info similar to the following:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            7f:e6:d7:91:d8:5e:99:aa:7a:7e:80:3b:fa:34:8d:3a:ff:14:8c:4a
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Massachusetts, L=Boston, O=SomeExampleOrg, OU=EngineeringDept, CN=Example CA
        Validity
            Not Before: Aug 13 19:25:39 2024 GMT
            Not After : Aug 11 19:25:39 2027 GMT
        Subject: C=US, ST=Massachusetts, L=Boston, O=SomeExampleOrg, OU=EngineeringDept, CN=Example CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b3:99:f7:02:a3:8f:b0:d0:c8:ab:67:94:a7:d3:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                D3:4F:66:E1:A3:CE:9C:E3:0B:7A:62:3E:13:6A:CF:B3:6D:90:E7:8D
            X509v3 Authority Key Identifier:
                D3:4F:66:E1:A3:CE:9C:E3:0B:7A:62:3E:13:6A:CF:B3:6D:90:E7:8D
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        4b:c1:ca:aa:e4:68:d2:88:fd:87:f3:8e:2c:92:0e:39:07:f8:
        ...

注意事項：

The Validity should cover a suitable time range from now to some future date (defaults to 3 years)
The Signature Algorithm uses sha256WithRSAEncryption
The x509v3 extensions have CA:TRUE to indicate this is a CA that can sign and verify certificates.

Create a Kubernetes Secret for the CA cert and key

Make sure your kubectl config current-context is configured for the k8s cluster where DataRobot will be installed, and DR_CORE_NAMESPACE environment variable was set accordingly.

Create the secret:
```
kubectl create secret generic -n $DR_CORE_NAMESPACE custom-sdtk-ca --from-file=Cert=ca.crt --from-file=Key=ca.key 
```
The contents will be base64 encoded when stored.

Inspect the secret

You can verify the secret and inspect the CA certificate using the following, which base64 decodes the data.

kubectl get secret -n $DR_CORE_NAMESPACE custom-sdtk-ca -o jsonpath='{.data.Cert}' | base64 -d | openssl x509 -text

Configuring Custom CA for DataRobot¶

Now that you have the custom-sdtk-ca secret created, update the values.yaml configuration:

global:
  applicationTLS:
    issuerType: Custom
    issuerName: custom-sdtk-ca
    caCertDuration: "26280h" # default

Note that automatical renewal with caCertRenewBefore setting is not supported when using Custom.

You may now proceed with additional steps with the installation.