Configure limited admin permissions¶

Running the DataRobot platform installation with limited admin permissions requires additional setup described on this page. A dedicated Helm chart called admin-privileges creates an installer service account (typically datarobot-installer) with the necessary, but restricted, permissions.

You must perform the following steps with cluster-admin permissions.

Set a DataRobot namespace¶

export NAMESPACE="DATAROBOT_NAMESPACE" 

Create a DataRobot namespace¶

You must create a namespace where the DataRobot charts is installed.

kubectl create namespace ${NAMESPACE} 

Run the admin-privileges Helm chart¶

To deploy and run the admin-privileges Helm chart, follow these steps:

1. Add the DataRobot OSS Helm repository if you haven't already:

   helm repo add datarobot-oss https://datarobot-oss.github.io/helm-charts
   helm repo update 
   

2. Install or upgrade the admin-privileges chart.

   helm upgrade --install admin-privs datarobot-oss/admin-privileges --namespace ${NAMESPACE} --debug 
   

   The release name is admin-privs in this example.

   本機能の提供について

   DataRobot version 11.12 and later requires admin-privileges 1.0.8 or later. Earlier chart versions do not grant the API gateway permissions, and the DataRobot installation fails.

3. (Optional) If you need to download the chart locally before installation, use the following command:

   helm pull datarobot-oss/admin-privileges 
   

Install CRDs and cluster-scoped resources in your cluster¶

DataRobot requires several Custom Resource Definitions (CRDs) and cluster-scoped resources to function properly. When using limited admin permissions, you must install these manually with cluster-admin permissions.

1. Extract the CRD and cluster-scoped resource manifests from the DataRobot application chart template. The --include-crds flag ensures CRDs bundled by subcharts are also included in the output. Replace path/to/datarobot-chart-X.X.X.X.tgz with the path to the DataRobot chart package and X.X.X.X with the correct version. This example uses the yq utility:

   helm template dr path/to/datarobot-chart-X.X.X.X.tgz \
     --namespace ${NAMESPACE} \
     --values values_dr.yaml \
     --set global.installCRDs=true \
     --set global.installClusterRoles=true \
     --set api-gateway.gateways.public.gatewayClass.create=true \
     --set user-metrics-collector.clusterRoleCreation=true \
     --include-crds \
     | yq eval 'select(.kind == "CustomResourceDefinition" or .kind == "ClusterRole" or .kind == "ClusterRoleBinding" or .kind == "GatewayClass" or .kind == "MutatingWebhookConfiguration" or .kind == "ValidatingWebhookConfiguration")' - > cluster-resources.yaml 
   

   Use the same namespace and values file that you use to install DataRobot. The --set flags override the keys from step 3 so that the cluster-scoped resources are rendered for extraction. Several cluster-scoped resources include the namespace in their name or bind service accounts in that namespace. Without --namespace, Helm renders them for the default namespace, and the API gateway can't find its GatewayClass. Optional components, such as the CloudNativePG operator, add cluster-scoped resources only when your values file enables them.

2. Apply the extracted manifests to your cluster. You must perform this step with appropriate cluster-admin permissions. Apply the CRDs first and wait for them to be established; otherwise, resources that use them, such as the GatewayClass, fail with no matches for kind.

   yq eval 'select(.kind == "CustomResourceDefinition")' cluster-resources.yaml | kubectl apply --server-side -f -
   kubectl wait --for=condition=Established crd --all --timeout=120s
   kubectl apply --server-side -f cluster-resources.yaml 
   

   The --server-side flag avoids the client-side annotation size limit on the largest CRDs.

3. To prevent the DataRobot Helm chart from attempting to recreate these resources, add the following keys to your values_dr.yaml file for the main DataRobot application chart:

   global:
     installCRDs: false
     installClusterRoles: false   # skip the pre-created ClusterRole and ClusterRoleBinding
   api-gateway:
     gateways:
       public:
         gatewayClass:
           create: false          # skip the pre-created GatewayClass
   user-metrics-collector:
     clusterRoleCreation: false   # this subchart does not follow global.installClusterRoles 
   

4. When you run helm install or helm upgrade for DataRobot as the installer service account, add the --skip-crds flag. Helm otherwise tries to install or update the CRDs bundled in the chart, which the installer service account isn't allowed to do:

   helm upgrade --install dr path/to/datarobot-chart-X.X.X.X.tgz \
     --namespace ${NAMESPACE} \
     --values values_dr.yaml \
     --skip-crds 
   

Upgrade DataRobot with limited admin permissions¶

New DataRobot versions can add CRDs, cluster-scoped resources, and Role objects that the installer service account must be allowed to create. Before you run helm upgrade for DataRobot, complete the following steps with cluster-admin permissions:

1. If you are upgrading from DataRobot version 10.x or earlier, remove the admin-privileges release that was installed from the DataRobot package. That release is usually named dr-admin-privs and installed in the default namespace. It owns the datarobot-installer service account, Role, and RoleBinding, so the datarobot-oss/admin-privileges chart can't be installed while it exists. Removing it doesn't affect the running DataRobot installation.

   helm list -A --filter admin-priv
   helm uninstall dr-admin-privs --namespace default 
   

   Replace dr-admin-privs and default with the release name and namespace from the helm list output. Skip this step if the listed release is already admin-privs in your DataRobot namespace with chart version 1.0.x. Uninstalling the release deletes the installer service account, so generate a new kubeconfig for it after the next step.

2. Upgrade the admin-privileges chart to the latest version:

   helm repo update
   helm upgrade --install admin-privs datarobot-oss/admin-privileges --namespace ${NAMESPACE} 
   

3. Repeat the steps in Install CRDs and cluster-scoped resources in your cluster using the chart package of the version you are upgrading to.

Generate generic kubeconfig¶

To generate a kubeconfig file for the datarobot-installer ServiceAccount that's portable for generic Kubernetes clusters, use the following commands:

Replace SERVICE_ACCOUNT_NAME if it differs from datarobot-installer, and SERVICE_ACCOUNT_NAMESPACE if it differs from dr-app. The kubeconfig file is created at /tmp/datarobot-installer-kubeconfig.

CONTEXT_NAME=$(kubectl config current-context)
CURRENT_CLUSTER=$(kubectl config view -o=jsonpath="{.contexts[?(@.name==\"${CONTEXT_NAME}\")].context.cluster}")
CLUSTER_CA=$(kubectl config view  --raw -o=jsonpath="{.clusters[?(@.name==\"${CURRENT_CLUSTER}\")].cluster.certificate-authority-data}")
CLUSTER_SERVER=$(kubectl config view -o=jsonpath="{.clusters[?(@.name==\"${CURRENT_CLUSTER}\")].cluster.server}")

if [ -z "$CURRENT_CLUSTER" ] || [ -z "$CLUSTER_CA" ] || [ -z "$CLUSTER_SERVER" ]; then
  echo "Error: Unable to retrieve cluster information from the current context."
  exit 1
fi

export SERVICE_ACCOUNT_NAME="${SERVICE_ACCOUNT_NAME:-datarobot-installer}"
export SERVICE_ACCOUNT_NAMESPACE="${SERVICE_ACCOUNT_NAMESPACE:-dr-app}"
export SERVICE_ACCOUNT_TOKEN=$(kubectl -n "$SERVICE_ACCOUNT_NAMESPACE" get secret "$SERVICE_ACCOUNT_NAME" -o jsonpath="{.data.token}"  | base64 --decode)

cat << EOF > /tmp/datarobot-installer-kubeconfig
apiVersion: v1
kind: Config
current-context: ${CONTEXT_NAME}
contexts:
- name: ${CONTEXT_NAME}
  context:
    cluster: ${CONTEXT_NAME}
    user: ${SERVICE_ACCOUNT_NAME}
    namespace: ${SERVICE_ACCOUNT_NAMESPACE}
clusters:
- name: ${CONTEXT_NAME}
  cluster:
    certificate-authority-data: ${CLUSTER_CA}
    server: ${CLUSTER_SERVER}
users:
- name: ${SERVICE_ACCOUNT_NAME}
  user:
    token: ${SERVICE_ACCOUNT_TOKEN}
EOF
` 

To use this kubeconfig, make it available to your kubectl commands. The easiest option is to set an environment variable:

export KUBECONFIG=/tmp/datarobot-installer-kubeconfig 

Generate kubeconfig for OpenShift (OCP)¶

For OpenShift Container Platform (OCP) environments, you need to grant the datarobot-installer ServiceAccount the necessary permissions within your created namespace. DataRobot recommends using the existing admin role, limited to this namespace.

Apply built-in admin role (OpenShift)¶

To apply the admin role to the datarobot-installer ServiceAccount for your DataRobot namespace, use the OpenShift CLI (oc):

oc adm policy add-role-to-user admin -z datarobot-installer -n ${NAMESPACE} 

After granting permissions, you need to generate a kubeconfig file for this ServiceAccount and log in.

Generate kubeconfig and log in¶

1. Obtain the ServiceAccount token and log in to the OpenShift cluster. Replace api.example.com:6443 with your cluster's API server. The kubeconfig is saved to ~/.kube/datarobot-installer-kubeconfig.

   TOKEN=$(oc get secret -n ${NAMESPACE} datarobot-installer -o jsonpath="{.data.token}" | base64 --decode)
   oc login --server=api.example.com:6443 --token="$TOKEN" --kubeconfig=~/.kube/datarobot-installer-kubeconfig 
   

2. Set the KUBECONFIG environment variable to use this new configuration file.

   export KUBECONFIG=~/.kube/datarobot-installer-kubeconfig