Networking & security¶
This page covers authentication, tenant isolation, and encryption for the Pipelines API.
Authentication¶
Public routes under /api/v2/pipelines/** authenticate two ways, in precedence order:
- Gateway-trusted headers — the API gateway validates the user's DataRobot session and injects the
X-DataRobot-User-Id,X-DataRobot-Tenant-Id, and (optionally)X-DataRobot-Org-Ididentity headers. The Pipelines API trusts these headers, so the gateway is the trust boundary for user traffic: expose the service only through the platform gateway. - Hydra JWT — in-cluster service-to-service callers present a Hydra-signed JWT, validated against Hydra's JWKS. Impersonation tokens carry the acting user's identity.
User, tenant, and org identity comes from the platform on every request. GET /health requires no authentication; Kubernetes probes use it.
Tenant isolation¶
Every user-owned row is scoped by user_id + tenant_id, and object-storage keys are tenant-prefixed; cross-tenant reads are blocked at the query layer.
Encryption at rest (CMEK)¶
AWS S3 only
Tenant CMEK is off by default and applies only to the AWS S3 backend. Enabling config.tenantCmkEncryption.enabled on an Azure Blob or GCS backend fails the pod at startup. On Azure and GCS, configure customer-managed keys at the storage-account or bucket level in the cloud instead.
On AWS, enabling tenant CMEK stamps every S3 PUT with the tenant's SSE-KMS key (by ARN):
pipelines-api:
config:
tenantCmkEncryption:
enabled: true # AWS S3 backend only
Tenant CMEK is fail-open. If the tenant key cannot be resolved (KMS unreachable or misconfigured), the write falls back to the bucket-default SSE-S3 encryption rather than failing, so dispatch stays available. Objects written during a KMS outage therefore land under SSE-S3 rather than the tenant key; account for this in your key-management and compliance posture.
DataRobot API token injection¶
API token injection is off by default. To ensure that import datarobot as dr works natively inside task pods (to reach Storage, Datasets, Deployments, and data connectors), the Pipelines API can inject a per-user DataRobot impersonation token into each task pod:
pipelines-api:
config:
drApiTokenInjection:
enabled: true
Each task pod receives a per-user impersonation token as DATAROBOT_API_TOKEN plus DATAROBOT_ENDPOINT. The token is minted per run; nothing is stored. Impersonation relies on drAuth.userImpersonationEnabled (on by default) and its corresponding Hydra grant.
The injected token carries the invoking user's DataRobot identity, so a task can fetch any credential that user is entitled to. Access is scoped to the user, and all tasks in a pipeline share it.
Secrets¶
Sensitive settings are delivered to the pod from the secret store through the pipelines-api-secrets ExternalSecret—the database password and the HMAC PIPELINES_API_CALLBACK_SIGNING_KEY. On installs without a managed secret store, the chart generates the callback signing key in-cluster.
Development auth bypass¶
Never enable in production
config.auth.disabled: true replaces authentication with a synthetic development identity. It is for local development only. Confirm it is false in every deployed environment.