Secrets Management Service (SMS)¶

The Secrets Management Service (SMS) acts as a broker between the DataRobot platform and a client-managed secret storage backend, ensuring the following:

• Stores only secret metadata (identifiers and schema references) in DataRobot's database.
• Routes all secret values, such as credentials, API keys, and secure configurations, to and from the client's own secret storage.
• Ensures sensitive data is never stored in the DataRobot platform.

The Secrets Management Service is available starting with DataRobot 11.9.

Requirements¶

Before enabling the Secrets Management Service, you must fulfill the following requirements:

• A supported secret storage backend is deployed and reachable over HTTPS from the DataRobot cluster.
• Credentials or an authentication method for the backend are provisioned for DataRobot.

For backend-specific requirements, see the sections below

HashiCorp Vault¶

If you are using HashiCorp Vault as your backend service, you must meet the following requirements:

• A HashiCorp Vault (OSS or Enterprise) instance is deployed and accessible over HTTPS from the DataRobot cluster.
• The KV v2 secrets engine is enabled.

• An authentication method is configured for DataRobot:

  • For AppRole authentication, the auth method is enabled in Vault, and a Role ID and Secret ID are provisioned.
  • For Kubernetes or JWT authentication, the auth method must be enabled in Vault before use.

• A base path is allocated in Vault for DataRobot secrets.

• (Optional) If Vault uses a private CA, the CA certificate is available in PEM format.
• (Optional) If using Vault Enterprise, the target namespace is identified. If not set, this defaults to the Vault root namespace.

Vault policy¶

HashiCorp Vault operates on a deny-by-default model, so you must attach a policy that grants the following permissions to the Vault role configured for SMS (or the token, if using token authentication):

If you plan to enable scoped token support, also grant:

The following HCL policy satisfies these requirements. Replace <kv-base-path> with the mount path allocated for DataRobot secrets:

path "<kv-base-path>/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "auth/token/lookup-self" {
  capabilities = ["read"]
}

path "auth/token/renew-self" {
  capabilities = ["update"]
}

Attach this policy to your auth method role (AppRole, Kubernetes, or JWT) or directly to the token before proceeding with enablement.

Enablement¶

SMS is disabled by default. To enable it, set global.secret-mgmt-service.enabled: true and configure the Vault connection under storage.vault:

global:
  secret-mgmt-service:
    enabled: true

secret-mgmt-service:
  storage:
    vault:
      addr: "https://<vault-address>:<vault-port>"
      auth_method: <auth-method>  # approle | k8s | jwt | token
      mount_path: "<kv-base-path>/"
      # namespace: "<vault-enterprise-namespace>"  # optional: Vault Enterprise only

When SMS is enabled, the chart automatically sets ENABLE_SECRET_MGMT_SERVICE_INTEGRATION: true on the core service, which causes DataRobot to route all credentials, API keys, and other sensitive configuration through SMS for storage in the configured backend. If you need to keep the SMS service running without activating this routing — for example, to retain access to secrets already stored in a backend — you can disable the integration explicitly:

core:
  config_env_vars:
    ENABLE_SECRET_MGMT_SERVICE_INTEGRATION: false

If Vault uses a private CA, provide the CA certificate via a Kubernetes Secret; see Custom CA certificate.

Then add the auth-method-specific configuration described in the following sections.

AppRole authentication¶

Add the approle block under storage.vault:

secret-mgmt-service:
  storage:
    vault:
      approle:
        role_id: "<role-id>"
        mount_path: "approle/"
        token_wrapping: "false"

The AppRole Secret ID is sensitive credential material. The recommended approach is to provide it via a Kubernetes Secret, referencing it under app.secrets as the VAULT_APPROLE_SECRET_ID environment variable:

secret-mgmt-service:
  app:
    secrets:
      - name: VAULT_APPROLE_SECRET_ID
        valueFrom:
          secretKeyRef:
            name: <approle-credentials-secret>
            key: secret-id

Alternatively, you can set it directly in your values file:

secret-mgmt-service:
  storage:
    vault:
      approle:
        secret_id: "<secret-id>"

Kubernetes authentication¶

SMS presents its Kubernetes service account token; Vault verifies it by calling the Kubernetes API server directly. This authentication method is recommended for Kubernetes-native Vault deployments.

Add the k8s block under storage.vault:

secret-mgmt-service:
  storage:
    vault:
      k8s:
        mount_path: "kubernetes/"
        role: "<vault-role-name>"

JWT authentication¶

SMS presents its Kubernetes service account token; Vault verifies it independently using public keys from the Kubernetes OIDC discovery endpoint without a live call to the Kubernetes API server per request.

Add the jwt block under storage.vault:

secret-mgmt-service:
  storage:
    vault:
      jwt:
        mount_path: "jwt/"
        role: "<vault-role-name>"

Token authentication¶

Provide a static Vault token via a Kubernetes Secret, referencing it under app.secrets as the VAULT_TOKEN environment variable:

secret-mgmt-service:
  app:
    secrets:
      - name: VAULT_TOKEN
        valueFrom:
          secretKeyRef:
            name: <vault-credentials-secret>
            key: token

Alternatively, you can set it directly in your values file:

secret-mgmt-service:
  storage:
    vault:
      token: "<vault-token>"

Custom CA certificate¶

If your Vault instance uses TLS signed by a private CA, provide the PEM-encoded CA certificate via a Kubernetes Secret, referencing it under app.secrets as the VAULT_CA_CERT environment variable:

secret-mgmt-service:
  app:
    secrets:
      - name: VAULT_CA_CERT
        valueFrom:
          secretKeyRef:
            name: <vault-ca-cert-secret>
            key: ca-cert

Alternatively, you can set it directly in your values file as a single-line PEM string with \n-escaped newlines:

secret-mgmt-service:
  storage:
    vault:
      ca_cert: "-----BEGIN CERTIFICATE-----\n<base64-encoded-certificate>\n-----END CERTIFICATE-----"

Scoped token support¶

By default, SMS authenticates to Vault once and reuses the resulting token for all secret operations. Enabling scoped token support changes this behavior: SMS creates a short-lived child token with a limited TTL and only the policies required for each individual operation, discarding it immediately after use. This limits the blast radius if a token is ever compromised, but increases load on the Vault token API because a new token is created and revoked for every secret operation.

Enable this option only if your security requirements justify the additional Vault overhead.

To enable scoped tokens, ensure the Vault policy includes auth/token/create permissions, then add the following to your values override:

secret-mgmt-service:
  storage:
    vault:
      scoped_token_enabled: true
      scoped_token_policies:
        - "<policy-name>"  # policy to attach to each scoped token

Apply the configuration¶

After updating your values override file, perform a Helm upgrade:

helm upgrade datarobot datarobot/datarobot-prime \
  -f your-values-override.yaml \
  --namespace datarobot

Verification¶

After the upgrade completes, verify that the SMS pod is running:

kubectl get pods -n datarobot -l role=secret-mgmt-service-app

Confirm the pod has passed its readiness probe:

kubectl get pod -n datarobot -l role=secret-mgmt-service-app -o jsonpath='{.items[0].status.conditions[?(@.type=="Ready")].status}'

The output should be True. If the pod is not ready, check the logs for Vault connectivity errors:

kubectl logs -n datarobot -l role=secret-mgmt-service-app

Post-enablement¶

Once the service is running, DataRobot routes all secret operations through SMS:

• New secrets created in DataRobot are automatically stored in the configured Vault.

• DataRobot performs a "lazy migration" of pre-existing secrets to Vault lazily on first access. No manual migration is required and consuming services observe no change in behavior. The migration follows these steps:

  1. DataRobot reads the secret from its previous internal store.
  2. The secret is written to Vault via SMS.
  3. The internal reference is updated to point to Vault.
  4. The secret is removed from legacy storage.