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.

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 --include-crds path/to/datarobot-chart-X.X.X.X.tgz \
     | yq eval 'select(.kind == "CustomResourceDefinition" or .kind == "ClusterRole" or .kind == "ClusterRoleBinding" or .kind == "GatewayClass")' - > cluster-resources.yaml 
   

2. Apply the extracted manifests to your cluster. You must perform this step with appropriate cluster-admin permissions.

   kubectl apply -f cluster-resources.yaml 
   

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 
   

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