Red Hat OpenShift Container Platform requirements¶

This section describes the OCP cluster requirements for running the DataRobot application. It assumes you have provisioned sufficient hardware resources to run large computational workloads.

OpenShift cluster overview¶

Before beginning, see the Kubernetes versions supported for each DataRobot release.

| OCP Version | Supported Kubernetes Versions |

Cluster reference settings¶

Control Plane

Workers

OIDC provider (for S3 via OIDC)¶

OCP clusters can use OpenID Connect (OIDC) to use AWS S3 for object storage. DataRobot requires an AWS IAM OIDC provider to exist to use AWS Identity and Access Management (IAM) roles for service accounts (IRSA).

To associate an IAM OIDC provider for your cluster, see the AWS documentation: Creating an IAM OIDC provider for your cluster.

IRSA role¶

DataRobot uses AWS IAM Roles for Service Accounts (IRSA) to communicate with AWS APIs. This IAM role is essential for DataRobot to interact with AWS S3 for object storage and data ingestion. To enable this, the role must include a Trust Relationship policy that permits communication with Kubernetes service accounts within the DataRobot application.

The policy below is an example of a Trust Relationship. Replace <AWS ACCOUNT NUMBER> and <OIDC PROVIDER NUM> with your specific values.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<AWS ACCOUNT NUMBER>:oidc-provider/<OIDC PROVIDER NUM>.cloudfront.net"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringLike": {
          "<OIDC PROVIDER NUM>.cloudfront.net:sub": "system:serviceaccount:*",
          "<OIDC PROVIDER NUM>.cloudfront.net:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}
````

This policy allows all configured service accounts in the cluster to perform the `sts:AssumeRoleWithWebIdentity` action. To limit access, adjust the `Condition` block as shown in the examples below.

  * **To only allow service accounts in the `dr-core` namespace:**
    ```json
                "Condition": {
                    "StringLike": {
                        "<OIDC PROVIDER NUM>.cloudfront.net:sub": "system:serviceaccount:dr-core:*"
                    }
                }
    ```
  * **To only allow specific service accounts in the `dr-core` namespace:**
    ```json
                "Condition": {
                    "StringEquals": {
                        "<OIDC PROVIDER NUM>.cloudfront.net:sub": [
                            "system:serviceaccount:dr-core:datarobot-storage-access",
                            "system:serviceaccount:dr-core:build-service",
                            "system:serviceaccount:dr-core:build-service-image-builder",
                            "system:serviceaccount:dr-core:dr-lrs-operator"
                        ]
                    }
                }
    ```

!!! note
    The examples use `StringLike` for wildcards (`*`) and `StringEquals` for specific service accounts. `StringLike` is required for partial string matches. For more information, see [IAM JSON policy elements: Condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html){ target=_blank }.

**Example role:**
*Note: Image paths are retained from the original document.*

### Additional IRSA policies {: #additional-irsa-policies }

In addition to the `Trust Relationship`, if the `IRSA` role will be used to communicate with other AWS APIs or services, the IAM role needs policies that allow those actions. This section provides examples.

#### AWS S3 object storage {: #aws-s3-object-storage }

DataRobot can be configured to use AWS S3 for object storage. See the [Object Storage Configuration](../advanced-configuration/object-storage-configuration.md) section for settings.

The `IRSA` role needs a policy to read from and write to the cluster's S3 Bucket. The example below allows the `datarobot-dev-OCP-IRSA-role` to access the `datarobot-dev-object-storage` bucket.

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAccessToProduction",
            "Effect": "Allow",
            "Action": [
                "s3:DeleteObject",
                "s3:Get*",
                "s3:PutObject",
                "s3:ReplicateDelete",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::datarobot-dev-object-storage/*",
                "arn:aws:s3:::datarobot-dev-object-storage"
            ]
        },
        {
            "Sid": "AllowListBucketsProduction",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:ListBucketVersions",
                "s3:ListAllMyBuckets"
            ],
            "Resource": [
                "arn:aws:s3:::*"
            ]
        }
    ]
}

AWS S3 object storage with KMS encryption¶

If the AWS S3 bucket uses a customer-managed KMS key, the IRSA role must be allowed to use the KMS key. You must set this permission in the Key Policy on the relevant KMS key.

The example Key Policy excerpt below allows an IRSA role (datarobot-dev-OCP-IRSA-role) to use the KMS key. Replace <AWS_ACCOUNT_ID> with your account ID.

        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<AWS_ACCOUNT_ID>:role/datarobot-dev-OCP-IRSA-role"
                ]
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        }

Consult the Server-side encryption settings part of the Object Storage Configuration section for configuring DataRobot to use this KMS key.

Using the IRSA role¶

When the IRSA role is configured, specify it in the datarobot-generic Helm chart values as shown in this excerpt. Replace DATAROBOT_SERVICE_ACCOUNT and AWS_IRSA_ROLE_NAME with your values.

core:
  # -- serviceAccount annotations
  serviceAccount:
    name: DATAROBOT_SERVICE_ACCOUNT
    annotations:
      [eks.amazonaws.com/role-arn](https://eks.amazonaws.com/role-arn){ target=_blank }: AWS_IRSA_ROLE_NAME
    # -- force the creation of a dedicated Service Account
    createNew: true
...

This configuration creates a default ServiceAccount for most datarobot-generic deployments in the DR_CORE_NAMESPACE. The annotations allow the AWS EKS cluster (acting as the OIDC provider for OCP in this context) to recognize that the DATAROBOT_SERVICE_ACCOUNT can assume the IRSA Role.

Refer to the full_datarobot-generic_s3_oidc_values.yaml or minimal_datarobot-generic_s3_oidc_values.yaml files in the installer-tools tarball for all sub-charts that require these annotations.

Docker registry¶

DataRobot requires a Docker registry with basic authentication and TLS configured.

A recommended approach is to run the registry on the provisioner node and place an Application Load Balancer (ALB) with TLS in front of it. Then, a registry-specific FQDN should point to that ALB. The ALB is optional but recommended.

Registry authentication¶

DataRobot charts assume the registry uses basic authentication. A common method is to:

1. Create an .htaccess file with the username and password.
2. Create the /var/lib/registry/auth folder on the provisioner host.
3. Create the /var/lib/registry/data folder on the provisioner host.
4. Launch the registry using a command similar to the following:

   docker run -d \
   --name=registry \
   --restart=always \
   -e REGISTRY_STORAGE_DELETE_ENABLED="true" \
   -e REGISTRY_AUTH="htpasswd" \
   -e REGISTRY_AUTH_HTPASSWD_REALM="EKS registry" \
   -e REGISTRY_AUTH_HTPASSWD_PATH="/auth/.htaccess" \
   -p 5000:5000 \
   -v /var/lib/registry/auth:/auth:z \
   -v /var/lib/registry/data:/var/lib/registry:z \
   registry:2.7
   

Registry Load Balancer and TLS¶

You can create an Application Load Balancer (ALB) in AWS with settings similar to these:

• Scheme: Internal
• HTTP Listener: Listens on Port 80 (HTTP) and redirects to port 443 (HTTPS).
• HTTPS Listener: Listens on Port 443 (HTTPS) and sends traffic to the provisioner host on port 5000.
• ACM Certificate: Use a TLS certificate signed by a well-known Certificate Authority. A wildcard certificate can be used but is not required.

Registry DNS¶

You need to set up a CNAME DNS entry for the registry URL. Some examples:

• Route53 Hosted Zone: company.net
  • You can use your internal DNS or private Route53 zones. The DNS provider must be resolvable by the provisioner host and OCP cluster machines.
• CNAME Record : datarobot-ocp-registry.company.net → CNAME → internal-XXXXXXXXXXXXXXXXXXXXXX-XXXXXXXXXX.us-east-1.elb.amazonaws.com

OpenShift FQDNs for subdomains¶

The OpenShift installer may also create its own records. You may have similar FQDNs, for example:

• api-int.datarobot-ocp.company.net
• api.datarobot-ocp.company.net
• *.apps.datarobot-ocp.company.net

Object storage¶

You must provide an S3-compatible object storage solution (e.g., MinIO, OpenShift Data Foundation).

Installation variations¶

This section documents the installation variants that DataRobot provides. The variants are tracked primarily by hosting type and configured object storage method.

Values:

• override/full_datarobot-generic_minio_values.yaml
• override/full_datarobot-generic_s3_iam_user_values.yaml
• override/full_datarobot-generic_s3_oidc_values.yaml
• override/minimal_datarobot-generic_minio_values.yaml
• override/minimal_datarobot-generic_s3_iam_user_values.yaml
• override/minimal_datarobot-generic_s3_oidc_values.yaml
• override/full_datarobot-pcs-ha_values.yaml
• override/minimal_datarobot-pcs-ha_values.yaml

The installer-tools also contains a script that takes the contents of the variables JSON files and populates the correct YAML files. Execute it using a command similar to the command below:

./installer_tools/scripts/find_and_replace_variables.py --var-file variables/full_datarobot-generic_s3_iam_user.json --values-dir installer_tools/example_umbrella_chart_values/ --output-dir values/