Self-managed install & maintenance > Install and config > Advanced config > Security & access control > External secrets for DataRobot Kubernetes installation

External secrets for Kubernetes¶

DataRobot supports external secret management through two primary operators: External Secrets Operator (ESO) and Vault Sync Operator (VSO). These operators integrate external secret management systems like AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, and others with Kubernetes, providing a secure way to manage sensitive configuration data without storing secrets directly in your cluster.

For MongoDB and PostgreSQL passwords specifically, DataRobot also supports referencing pre-existing Kubernetes Secrets directly without requiring ESO or VSO. This is useful when secrets are already provisioned in the cluster through tooling such as Sealed Secrets, SOPS, Ansible Vault or Hashicorp Vault and DataRobot is just a consumer of it.

概要¶

Both External Secrets Operator and Vault Sync Operator allow you to:

Fetch secrets from external secret stores
Automatically sync secrets into Kubernetes Secret objects
Maintain separation between your application configuration and sensitive data
Leverage your existing secret management infrastructure

前提条件¶

Before configuring external secret operators for your DataRobot installation:

Kubernetes cluster with External Secrets Operator or Vault Sync Operator installed
Access to an external secret management system (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, etc.)
Appropriate IAM/RBAC permissions for the operator to access your secret store

Configuring external secrets operator¶

To configure External Secrets Operator with DataRobot Helm chart, create an override values file:

# values-override.yaml
auth-server:
  secretManager:
    secretStore:
      # -- Name of external secret store
      name: "external-secret-store"
      useExistingSecretStore: true
auth-token-customization:
  hydra:
    secret:
      enabled: false
  secretManager:
    externalSecret:
      name: auth-server-system-secrets
    secretStore:
      # -- Name of external secret store
      name: "external-secret-store"
      useExistingSecretStore: true
global:
  externalSecretStore:
    # -- Enable external secret store
    enabled: true
    engine: eso
    # -- Kind of external secret store ClusterSecretStore/SecretStore
    kind: "ClusterSecretStore"
    # -- Name of external secret store
    name: "external-secret-store"
    # -- Path to external secret store
    path: "/common/datarobot"
    provider:
      vault:
        auth:
          # - Example of using kubernetes auth engine
          kubernetes:
            mountPath: eso
            role: vault-secrets-operator
            serviceAccountRef:
              name: externalsecrets-sa
        # -- Optional field containing a base64 encoded string of the Certificate Authority to trust the Vault connection
        caBundle: >-
          LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJiekNDQVJhZ0F3SUJBZ0
          ...
          YyZUgyTjVEdzc2bzlySUF0Nkk9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
        path: /kv
        server: https://vault.vault:8200
        version: v2

Configuring Vault sync operator¶

To configure Vault Sync Operator with DataRobot Helm chart, create an override values file:

# values-override.yaml
auth-server:
  secretManager:
    secretStore:
      # -- Name of external secret store
      name: "external-secret-store"
      useExistingSecretStore: true
auth-token-customization:
  hydra:
    secret:
      enabled: false
  secretManager:
    externalSecret:
      name: auth-server-system-secrets
    secretStore:
      # -- Name of external secret store
      name: "external-secret-store"
      useExistingSecretStore: true
global:
  externalSecretStore:
    enabled: true
    engine: vso
    path: "/common/datarobot"
    refreshInterval: "42s"
    vso:
      # -- spec for VaultConnection https://developer.hashicorp.com/vault/docs/deploy/kubernetes/vso/api-reference#vaultconnectionspec
      connection:
        address: https://vault.vault:8200
        skipTLSVerify: true
      # -- spec for VaultAuth https://developer.hashicorp.com/vault/docs/deploy/kubernetes/vso/api-reference#vaultauthspec
      auth:
        name: vault-auth-cfg
        spec:
          # - Example of using kubernetes auth engine
          method: kubernetes
          mount: vso
          kubernetes:
            role: vault-secrets-operator
            serviceAccount: externalsecrets-sa
            audiences:
              - vault

Note Vault Authentication configuration must be defined based on your vault configuration using one of the following methods kubernetes, jwt, appRole, aws, gcp

Using pre-existing Kubernetes secrets¶

If you already manage Kubernetes Secret objects outside the DataRobot Helm chart, you can configure DataRobot to reference those secrets directly. This approach does not require ESO or VSO, and instructs the chart to skip creating its own pcs-mongo, pcs-postgresql, and auth-server-system-secrets secrets.

MongoDB¶

Set global.mongodb.auth.existingSecret to the name of your pre-existing Kubernetes Secret. The chart expects the MongoDB root password to be stored under the key mongodb-root-password by default. If your secret uses a different key name, specify it via global.mongodb.auth.existingSecretKeys.password.

PostgreSQL¶

Set global.postgresql.auth.existingSecret to the name of your pre-existing Kubernetes Secret. The chart expects the PostgreSQL superuser password under the key postgres-password by default. If your secret uses a different key name, specify it via global.postgresql.auth.existingSecretKeys.postgres-password.

Note: global.postgresql.auth.existingSecret only controls whether the chart creates the pcs-postgresql secret. The flag global.postgresql.auth.externalSecret: "true" is reserved for ESO/VSO workflows; when set, it overrides existingSecret and forces the chart to use pcs-postgresql.

Auth server system secrets¶

The auth server needs two keys: secretsSystem, the master key protecting stored application secrets at rest, and secretsCookie, which signs session cookies.

On a standard helm install or helm upgrade the chart generates these for you on the first install and reuses them on every later upgrade, so most installations need no action.

You must supply them yourself when the manifests are rendered without access to the cluster—ArgoCD or any other workflow built on helm template. A renderer with no cluster access cannot distinguish a first install from a later sync, so generating a key there would produce a different value every time and invalidate every issued token. When that happens the chart fails to render with instructions rather than installing a shared default. Alternatively, you can supply these yourself on a standard install, keeping key material in your own secret management system.

Create the Secret before installing, then set auth-token-customization.hydra.secret.enabled: false. The Secret must be in the DataRobot namespace and named to match auth-token-customization.hydra.secret.nameOverride, which defaults to auth-server-system-secrets:

kubectl create secret -n ${NAMESPACE} generic auth-server-system-secrets \
  --from-literal=secretsSystem="$(openssl rand -base64 32)" \
  --from-literal=secretsCookie="$(openssl rand -base64 32)"

Do not reuse these keys across environments, and include the Secret in your backup procedure: it exists only in the cluster, and losing it means losing everything encrypted under it.

ArgoCD installs must supply these keys

ArgoCD renders with helm template, so the chart cannot generate or reuse these keys. Supply them with either the Secret above or the External Secrets configuration, before the first sync. Otherwise the Application fails to render with a message naming both options. Nothing is applied on a render failure, so a running deployment is unaffected until you supply them.

Previewing an install

helm template and helm install --dry-run cannot reach the cluster, so on a fresh install with default values they report that these keys have no safe source. This is expected. Use helm install --dry-run=server to preview, or supply the keys explicitly.

Rotate auth server system secrets¶

The auth server uses two system secrets, secretsCookie and secretsSystem, and they rotate differently.

secretsCookie protects session cookies, so you can replace it outright. On installations that only use the client_credentials grant, there are no login or consent sessions to lose. Once authorization code flows are in use, replacing it signs users out once.

secretsSystem encrypts data at rest, including the auth server's signing keys and trusted issuer keys, so it needs a planned procedure. The rest of this section covers that procedure.

secretsSystem accepts a comma-separated list of values. The auth server encrypts new data with the first value in the list, and tries each value in turn when it decrypts. Each value must be at least 16 characters and must not contain a comma.

To rotate secretsSystem without downtime, add the new value to the front of the list and keep the old value after it. New data is then encrypted under the new value, and data already encrypted under the old value stays readable.

The auth server does not re-encrypt existing data when the list changes. Data encrypted under the old value stays that way until it expires or is replaced. Remove the old value only once none of that data is left, because after that the auth server can no longer read it. How that data gets replaced depends on what it is:

データ	Clears on its own?	What rotation requires
Access token, consent, and grant records.	Yes, when they expire.	Waiting for the access token lifetime (24 hours by default).
The auth server's signing keys.	No. They are reused for the life of the installation.	Adding a new signing key, then deleting the old one.
Trusted issuer keys.	Not in practice. Some are rotated automatically, but on a default installation that happens about once a year.	Registering them again.

Do not remove the old value until the check in step 6 passes

Removing the old value while any signing key or trusted issuer key is still encrypted under it leaves the auth server unable to read that key. Because access tokens are issued as JWTs, the server can then neither issue nor validate tokens, and token exchanges for the affected issuer fail. Waiting longer or restarting does not recover it; adding the old value back to the list does. Leaving the old value in the list forever is not a safe alternative either: until step 6 passes, the signing keys remain recoverable by anyone who can read a database backup or snapshot, and could be used to forge tokens.

This procedure takes at least a day

Steps 1 to 4 take a few minutes and are done together. Step 5 has to wait at least the access token lifetime (24 hours by default) after step 3, and steps 6 and 7 follow as soon as step 5 is done.

Steps 3, 4, and 5 use the auth server's admin API, which is unauthenticated and reachable only inside the cluster. Before each of those steps, forward it to your workstation in a separate terminal. You don't need to keep it running during the wait before step 5:

kubectl -n ${NAMESPACE} port-forward svc/auth-server-hydra-admin 4445:4445

The steps also query the auth server's database, sushihydra. On the bundled PostgreSQL, define this helper, which runs SQL inside the database pod using its own credentials. Define it again in any new terminal. On external PCS, run the same SQL against the sushihydra database with your usual client.

hydra_sql() {
  kubectl exec -i -n ${NAMESPACE} pcs-postgresql-0 -- \
    sh -c 'export PGPASSWORD="$POSTGRES_POSTGRES_PASSWORD"; psql -U postgres -d sushihydra -tA -F " "'
}

Then, begin the steps:

Add the new value in front of the old one. Generate a new value, then set secretsSystem to <new value>,<old value> wherever you supply it. If the chart manages the auth-server-system-secrets Secret or you created it yourself, patch the Secret. If you set auth-token-customization.hydra.secret.secretsSystem in your values, change it there instead, because the chart writes that value over the Secret on every upgrade. If an external secret store supplies the Secret, update the value in the store.
```
NEW=$(openssl rand -base64 32 | tr -d '\n')
OLD=$(kubectl -n ${NAMESPACE} get secret auth-server-system-secrets -o jsonpath='{.data.secretsSystem}' | base64 -d)
kubectl -n ${NAMESPACE} patch secret auth-server-system-secrets --type merge \
  -p "{\"stringData\":{\"secretsSystem\":\"${NEW},${OLD}\"}}"
kubectl -n ${NAMESPACE} rollout restart deployment auth-server-hydra
kubectl -n ${NAMESPACE} rollout status deployment auth-server-hydra 
```
Wait for the rollout to finish before you continue. A replica still running with only the old value keeps encrypting new data under it, and the check in step 6 cannot detect that.
Record the start time from the database clock rather than your workstation's:
```
START=$(hydra_sql <<SQL
SELECT now() AT TIME ZONE 'utc';
SQL
)
echo "${START}" 
```
The remaining steps use START to find everything written before the new value took effect. Record the value somewhere you can find it again, because the procedure spans more than a day.
Add a new signing key to each of the auth server's two signing key sets:
```
for SET in hydra.jwt.access-token hydra.openid.id-token; do
  curl -s -o /dev/null -w "${SET}: %{http_code}\n" -X POST "http://127.0.0.1:4445/admin/keys/${SET}" \
    -H 'Content-Type: application/json' -d '{"alg":"RS256","use":"sig"}'
done 
```
Each set should return 201. The command discards the response because it contains the new private key. New tokens are signed with the new keys immediately, and the old keys stay published so that tokens already issued remain valid. Until step 5, /.well-known/jwks.json serves four keys instead of two.

List the trusted issuers whose keys are still encrypted under the old value:

hydra_sql <<SQL
SELECT DISTINCT sid FROM hydra_jwk
WHERE sid NOT IN ('hydra.jwt.access-token', 'hydra.openid.id-token')
  AND created_at < '${START}'::timestamp;
SQL

Register every listed issuer again, including internal-token-bridge, so that its key is rewritten under the new value. Some issuers are rotated automatically, but on a default installation that happens about once a year, so don't wait for it. For each listed issuer, set ISSUER to the issuer exactly as listed and run:

ISSUER='https://issuer.example.com'
ADMIN=http://127.0.0.1:4445/admin/trust/grants/jwt-bearer/issuers
for ID in $(curl -s "$ADMIN" | jq -r --arg i "$ISSUER" '.[] | select(.issuer == $i) | .id'); do
  curl -s "$ADMIN/$ID" > registration.json
  SET=$(jq -r '.public_key.set | @uri' registration.json)
  KID=$(jq -r '.public_key.kid' registration.json)
  curl -s "http://127.0.0.1:4445/admin/keys/${SET}/${KID}" | jq '.keys[0]' > key.json
  jq -s '.[0] as $r | {issuer: $r.issuer, scope: $r.scope, expires_at: $r.expires_at, jwk: .[1]}
         + (if $r.allow_any_subject then {allow_any_subject: true} else {subject: $r.subject} end)' \
     registration.json key.json > new-registration.json
  curl -s -o /dev/null -w "delete ${ID}: %{http_code}\n" -X DELETE "$ADMIN/$ID"
  curl -s -o /dev/null -w "create: %{http_code}\n" -X POST "$ADMIN" -H 'Content-Type: application/json' -d @new-registration.json
done

Each registration should return 204 and then 201. The new registration keeps the original subject, scopes, expiry, and public key. The auth server does not accept a second registration of the same key while the first exists, so there is a brief interval between the two calls during which token exchanges for that issuer fail. For internal-token-bridge, that interval affects every token exchange. Run the commands together, without pausing between them.

After the access token lifetime has passed, delete the old signing keys. Wait at least the access token lifetime (24 hours by default) after step 3, so that no unexpired token is still signed with an old key. Then delete every signing key created before START, and restart the auth server so that every replica reloads its keys:

START='<the value you recorded in step 2>'
hydra_sql <<SQL > old-signing-keys.txt
SELECT sid, kid FROM hydra_jwk
WHERE sid IN ('hydra.jwt.access-token', 'hydra.openid.id-token')
  AND created_at < '${START}'::timestamp;
SQL
while read -r SID KID; do
  curl -s -o /dev/null -w "${SID}/${KID}: %{http_code}\n" -X DELETE "http://127.0.0.1:4445/admin/keys/${SID}/${KID}"
done < old-signing-keys.txt
kubectl -n ${NAMESPACE} rollout restart deployment auth-server-hydra
kubectl -n ${NAMESPACE} rollout status deployment auth-server-hydra

Each deletion should return 204.

Confirm that nothing is still encrypted under the old value:
```
hydra_sql <<SQL
SELECT sid, kid FROM hydra_jwk WHERE created_at < '${START}'::timestamp;
SQL 
```
The query must return no rows. If it returns any, go back to the step that covers them. Always run this query against the whole table, not a single key set.

Remove the old value. Set secretsSystem to the new value alone, in the same place you changed it in step 1, and restart the auth server:

CURRENT=$(kubectl -n ${NAMESPACE} get secret auth-server-system-secrets -o jsonpath='{.data.secretsSystem}' | base64 -d)
kubectl -n ${NAMESPACE} patch secret auth-server-system-secrets --type merge \
  -p "{\"stringData\":{\"secretsSystem\":\"${CURRENT%%,*}\"}}"
kubectl -n ${NAMESPACE} rollout restart deployment auth-server-hydra
kubectl -n ${NAMESPACE} rollout status deployment auth-server-hydra

Next, confirm that the auth server can still issue and validate tokens. Request the published keys from https://<your DataRobot host>/.well-known/jwks.json, and sign in to DataRobot. If anything fails, restore <new value>,<old value> and restart; the data becomes readable again.

Finally, back up the auth-server-system-secrets Secret once you finish. The new value exists only in the cluster, and losing it means losing everything encrypted under it.

Example `values-override.yaml`¶

# values-override.yaml
global:
  mongodb:
    auth:
      # Name of the pre-existing Kubernetes Secret containing MongoDB credentials.
      # When set, the chart will NOT create the 'pcs-mongo' secret.
      existingSecret: my-mongo-secret
      existingSecretKeys:
        # Key within the secret that holds the MongoDB root password.
        # Defaults to 'mongodb-root-password' if omitted.
        password: my-mongodb-password-key

  postgresql:
    auth:
      # Name of the pre-existing Kubernetes Secret containing PostgreSQL credentials.
      # When set, the chart will NOT create the 'pcs-postgresql' secret.
      externalSecret: false
      existingSecret: my-postgres-secret
      existingSecretKeys:
        # Key within the secret that holds the PostgreSQL superuser password.
        # Defaults to 'postgres-password' if omitted.
        postgres-password: my-postgres-password-key

If buzok/genAI needs to be enabled, add the following blocks for charts to read existing secret from global block

  buzok-web:
    secrets:
      globalOverridesEnabled: true

  buzok-worker:
    secrets:
      globalOverridesEnabled: true

Required secret contents¶

Your pre-existing secrets must contain the following keys (or the custom names you configure via existingSecretKeys):

MongoDB secret¶

Key (default)	Configurable via	説明
`mongodb-root-username`	—	MongoDB superuser username
`mongodb-root-password`	`existingSecretKeys.password`	MongoDB superuser password
`mongodb-replica-set-key`	—	Shared secret used by MongoDB replica set members

PostgreSQL secret¶

Key (default)	Configurable via	説明
`postgres-password`	`existingSecretKeys["postgres-password"]`	PostgreSQL superuser (`postgres`) password
`username`	—	DataRobot application database username
`password`	—	DataRobot application database password
`database`	—	DataRobot application database name
`repmgr-username`	—	Replication manager username
`repmgr-password`	—	Replication manager password

Auth server system secrets¶

キー	説明
`secretsSystem`	Master key protecting stored application secrets at rest. Random alphanumeric, minimum 32 characters.
`secretsCookie`	Signing and encryption key for authentication cookies. Random alphanumeric, minimum 32 characters.

Secrets¶

Following secrets needs to be populated in the chosen secret management system for ESO/VSO configurations:

/common/datarobot/ui-admin-credentials¶

{
  "fqdn": "DR_WEBPAGE_FQDN",
  "password": "ADMIN_USER_PASSWORD",
  "username": "ADMIN_USER_EMAIL"
}

DR_WEBPAGE_FQDN: The Fully-qualified domain name (FQDN) of the web portal where users log in (e.g., datarobot-app.company-name.com).

ADMIN_USER_EMAIL: The email address for the initial administrative user in the web portal (e.g., admin@datarobot.com).

ADMIN_USER_PASSWORD: The password for the initial administrative user.

/common/datarobot/datarobot-license¶

{
  "license": "DR_LICENSE_CONTENT"
}

DR_LICENSE_CONTENT : The encrypted content of the DataRobot license file.

/common/datarobot/core-credentials¶

{
  "asymmetrickey": "DATAROBOT_ASYMMETRIC_KEY",
  "drsecurekey": "DATAROBOT_DRSECURE_KEY"
}

DATAROBOT_ASYMMETRIC_KEY: The secure key used by the DataRobot application. Must adhere to the format: aeshex256:<AES-256 key>

DATAROBOT_DRSECURE_KEY: The asymmetric key required by the DataRobot application. Must adhere to the format: aeshex256:<AES-256 keys>

/common/datarobot/mmapp-credentials¶

{
  "password": "MMAPP_PASSWORD"
}

MMAPP_PASSWORD: The password for the MMApp service. Must be a random 42-character string.

/common/datarobot/datarobot-image-pull-secret¶

{
  ".dockerconfigjson": "DOCKER_CONFIG_JSON"
}

DOCKER_CONFIG_JSON: The registry login configuration file in the JSON file that holds an authorization token. For more details see: Interpretation of config.json

/common/datarobot/pcs-redis¶

{
  "redis-password": "REDIS_PASSWORD"
}

REDIS_PASSWORD: The password for the Redis database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-elasticsearch¶

{
  "elasticsearch-password": "ELASTICSEARCH_PASSWORD"
}

ELASTICSEARCH_PASSWORD: The password for the Elasticsearch database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-mongo¶

{
  "mongodb-replica-set-key": "MONGODB_REPLICA_SET_KEY",
  "mongodb-root-password": "MONGODB_ROOT_PASSWORD",
  "mongodb-root-username": "MONGODB_ROOT_USERNAME"
}

MONGODB_REPLICA_SET_KEY: The key for the MongoDB replica set. Must be a random, alphanumeric string with a minimum length of 42 characters.

MONGODB_ROOT_PASSWORD: The password for the MongoDB database. Must be a random, alphanumeric string with a minimum length of 24 characters.

MONGODB_USERNAME: The username for the MongoDB database instance. Example: pcs-mongodb.

/common/datarobot/pcs-rabbitmq¶

{
  "rabbitmq-erlang-cookie": "RABBITMQ_ERLANG_COOKIE",
  "rabbitmq-password": "RABBITMQ_PASSWORD",
  "rabbitmq-username": "RABBITMQ_USERNAME"
}

RABBITMQ_ERLANG_COOKIE: The shared secret (cookie) used by Erlang nodes for inter-node authentication and clustering in the RabbitMQ environment. Must be a random, alphanumeric string with a minimum length of 32 characters.

RABBITMQ_PASSWORD: The password for the RabbitMQ database. Must be a random, alphanumeric string with a minimum length of 24 characters.

RABBITMQ_USERNAME: The username for the RabbitMQ database instance. Example: pcs-rabbitmq.

/common/datarobot/pcs-postgresql¶

{
  "database": "datarobot",
  "password": "POSTGRESQL_PASSWORD",
  "postgres-password": "POSTGRESQL_PASSWORD",
  "postgres-username": "postgres",
  "repmgr-password": "REPMGR_PASSWORD",
  "repmgr-username": "repmgr",
  "username": "datarobot"
}

POSTGRESQL_PASSWORD: The password for the PostgreSQL database. Must be a random, alphanumeric string with a minimum length of 24 characters.

REPMGR_PASSWORD: The password for the PostgreSQL repmgr database user. This user is essential for managing replication and failover in the HA setup. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-pgpool¶

{
  "admin-password": "PGPOOL_PASSWORD",
  "sr-check-password": "POSTGRESQL_PASSWORD"
}

PGPOOL_PASSWORD: The password for the PgPool service user, typically used for connecting to and managing the PostgreSQL cluster. Must be a random, alphanumeric string with a minimum length of 24 characters.

POSTGRESQL_PASSWORD: The password for the PostgreSQL database. Must be the same as set for /common/datarobot/pcs-postgresql.

/common/datarobot/pcs-pgpool-userdb¶

{
  "user.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'postgres') THEN CREATE ROLE postgres; END IF; END $$;\nGRANT postgres TO postgres;\nALTER USER postgres WITH LOGIN PASSWORD 'POSTGRESQL_PASSWORD';\nSELECT 'CREATE DATABASE postgres' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'postgres')\\gexec\nALTER DATABASE postgres OWNER TO postgres;\nGRANT ALL PRIVILEGES ON DATABASE postgres TO postgres;\n",
  "userdb.sh": "#!/bin/bash\nset +e\nIFS=','\nread -ra hosts <<< \"$PGPOOL_BACKEND_NODES\"\nfor host_segment in \"${hosts[@]}\"; do\n    host=\"$( echo $host_segment | cut -d ':' -f2)\"\n    port=\"$( echo $host_segment | cut -d ':' -f3)\"\n    echo \"connecting to $host:$port\"\n    psql_output=$(psql postgres://$POSTGRESQL_INITSCRIPTS_USERNAME:$POSTGRESQL_INITSCRIPTS_PASSWORD@$host:$port -f /opt/bitnami/initscript/user.sql 2>&1)\n    if grep -q \"read-only transaction\" <<< \"$psql_output\"; then\n        echo \" skip read-only node $host:$port\"\n        continue\n    fi\ndone\n"
}

POSTGRESQL_PASSWORD: The password for the PostgreSQL database. Must be the same as set for /common/datarobot/pcs-postgresql.

/common/datarobot/pcs-db-apigateway¶

{
  "database": "apigateway",
  "password": "APIGATEWAY_PASSWORD",
  "username": "apigateway"
}

APIGATEWAY_PASSWORD: The password for the apigateway database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-buildservice¶

{
  "database": "buildservice",
  "password": "BUILDSERVICE_PASSWORD",
  "username": "buildservice"
}

BUILDSERVICE_PASSWORD: The password for the buildservice database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-computejobs¶

{
  "database": "computejobs",
  "password": "COMPUTEJOBS_PASSWORD",
  "username": "computejobs"
}

COMPUTEJOBS_PASSWORD: The password for the computejobs database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-covalent¶

{
  "database": "covalent",
  "password": "COVALENT_PASSWORD",
  "username": "covalent"
}

COVALENT_PASSWORD: The password for the covalent database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-cspspark¶

{
  "database": "cspspark",
  "password": "CSPSPARK_PASSWORD",
  "username": "cspspark"
}

CSPSPARK_PASSWORD: The password for the cspspark database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-memoryservice¶

{
  "database": "memoryservice",
  "password": "MEMORYSERVICE_PASSWORD",
  "username": "memoryservice"
}

MEMORYSERVICE_PASSWORD: The password for the memoryservice database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-secretmgmt¶

{
  "database": "secretmgmt",
  "password": "SECRETMGMT_PASSWORD",
  "username": "secretmgmt"
}

SECRETMGMT_PASSWORD: The password for the secretmgmt database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-entitlement¶

{
  "database": "entitlement",
  "password": "ENTITLEMENT_PASSWORD",
  "username": "entitlement"
}

ENTITLEMENT_PASSWORD: The password for the entitlement database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-identityresourceservice¶

{
  "database": "identityresourceservice",
  "password": "IDENTITYRESOURCESERVICE_PASSWORD",
  "username": "identityresourceservice"
}

IDENTITYRESOURCESERVICE_PASSWORD: The password for the identityresourceservice database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-messagequeue¶

{
  "database": "messagequeue",
  "password": "MESSAGEQUEUE_PASSWORD",
  "username": "messagequeue"
}

MESSAGEQUEUE_PASSWORD: The password for the messagequeue database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-modmon¶

{
  "database": "modmon",
  "password": "MODMON_PASSWORD",
  "username": "modmon"
}

MODMON_PASSWORD: The password for the modmon database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-oauthproviders¶

{
  "database": "oauthproviders",
  "password": "OAUTHPROVIDERS_PASSWORD",
  "username": "oauthproviders"
}

OAUTHPROVIDERS_PASSWORD: The password for the oauthproviders database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-predenv¶

{
  "database": "predenv",
  "password": "PREDENV_PASSWORD",
  "username": "predenv"
}

PREDENV_PASSWORD: The password for the predenv database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-sushihydra¶

{
  "database": "sushihydra",
  "password": "SUSHIHYDRA_PASSWORD",
  "username": "sushihydra"
}

SUSHIHYDRA_PASSWORD: The password for the sushihydra database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-db-pipelines¶

{
  "database": "pipelines",
  "password": "PIPELINES_PASSWORD",
  "username": "pipelines"
}

PIPELINES_PASSWORD: The password for the pipelines database. Must be a random, alphanumeric string with a minimum length of 24 characters.

/common/datarobot/pcs-pgpool-custom-users¶

{
  "passwords": "POSTGRESQL_PASSWORD,MODMON_PASSWORD,CSPSPARK_PASSWORD,COMPUTEJOBS_PASSWORD,BUILDSERVICE_PASSWORD,MESSAGEQUEUE_PASSWORD,PREDENV_PASSWORD,SUSHIHYDRA_PASSWORD,IDENTITYRESOURCESERVICE_PASSWORD,ENTITLEMENT_PASSWORD,OAUTHPROVIDERS_PASSWORD,COVALENT_PASSWORD,APIGATEWAY_PASSWORD,MEMORYSERVICE_PASSWORD,SECRETMGMT_PASSWORD,PIPELINES_PASSWORD",
  "usernames": "postgres,modmon,cspspark,computejobs,buildservice,messagequeue,predenv,sushihydra,identityresourceservice,entitlement,oauthproviders,covalent,apigateway,memoryservice,secretmgmt,pipelines"
}

POSTGRESQL_PASSWORD: The password for the PostgreSQL database. Must be the same as set for /common/datarobot/pcs-postgresql.

MODMON_PASSWORD: The password for the modmon database. Must be the same as set for /common/datarobot/pcs-db-modmon.

CSPSPARK_PASSWORD: The password for the cspspark database. Must be the same as set for /common/datarobot/pcs-db-cspspark.

COMPUTEJOBS_PASSWORD: The password for the computejobs database. Must be the same as set for /common/datarobot/pcs-db-computejobs.

BUILDSERVICE_PASSWORD: The password for the buildservice database. Must be the same as set for /common/datarobot/pcs-db-buildservice.

MESSAGEQUEUE_PASSWORD: The password for the messagequeue database. Must be the same as set for /common/datarobot/pcs-db-messagequeue.

PREDENV_PASSWORD: The password for the predenv database. Must be the same as set for /common/datarobot/pcs-db-predenv.

SUSHIHYDRA_PASSWORD: The password for the sushihydra database. Must be the same as set for /common/datarobot/pcs-db-sushihydra.

IDENTITYRESOURCESERVICE_PASSWORD: The password for the identityresourceservice database. Must be the same as set for /common/datarobot/pcs-db-identityresourceservice.

ENTITLEMENT_PASSWORD: The password for the entitlement database. Must be the same as set for /common/datarobot/pcs-db-entitlement.

OAUTHPROVIDERS_PASSWORD: The password for the oauthproviders database. Must be the same as set for /common/datarobot/pcs-db-oauthproviders.

COVALENT_PASSWORD: The password for the covalent database. Must be the same as set for /common/datarobot/pcs-db-covalent.

APIGATEWAY_PASSWORD: The password for the apigateway database. Must be the same as set for /common/datarobot/pcs-db-apigateway.

MEMORYSERVICE_PASSWORD: The password for the memoryservice database. Must be the same as set for /common/datarobot/pcs-db-memoryservice.

SECRETMGMT_PASSWORD: The password for the secretmgmt database. Must be the same as set for /common/datarobot/pcs-db-secretmgmt.

PIPELINES_PASSWORD: The password for the pipelines database. Must be the same as set for /common/datarobot/pcs-db-pipelines.

/common/datarobot/pcs-postgresql-initdb¶

{
  "buildservice.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'buildservice') THEN CREATE ROLE buildservice; END IF; END $$;\nGRANT buildservice TO postgres;\nALTER USER buildservice WITH LOGIN PASSWORD 'BUILDSERVICE_PASSWORD';\nSELECT 'CREATE DATABASE buildservice' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'buildservice')\\gexec\nALTER DATABASE buildservice OWNER TO buildservice;\nGRANT ALL PRIVILEGES ON DATABASE buildservice TO buildservice;\n",
  "computejobs.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'computejobs') THEN CREATE ROLE computejobs; END IF; END $$;\nGRANT computejobs TO postgres;\nALTER USER computejobs WITH LOGIN PASSWORD 'COMPUTEJOBS_PASSWORD';\nSELECT 'CREATE DATABASE computejobs' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'computejobs')\\gexec\nALTER DATABASE computejobs OWNER TO computejobs;\nGRANT ALL PRIVILEGES ON DATABASE computejobs TO computejobs;\n",
  "covalent.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'covalent') THEN CREATE ROLE covalent; END IF; END $$;\nGRANT covalent TO postgres;\nALTER USER covalent WITH LOGIN PASSWORD 'COVALENT_PASSWORD';\nSELECT 'CREATE DATABASE covalent' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'covalent')\\gexec\nALTER DATABASE covalent OWNER TO covalent;\nGRANT ALL PRIVILEGES ON DATABASE covalent TO covalent;\n",
  "cspspark.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'cspspark') THEN CREATE ROLE cspspark; END IF; END $$;\nGRANT cspspark TO postgres;\nALTER USER cspspark WITH LOGIN PASSWORD 'CSPSPARK_PASSWORD';\nSELECT 'CREATE DATABASE cspspark' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'cspspark')\\gexec\nALTER DATABASE cspspark OWNER TO cspspark;\nGRANT ALL PRIVILEGES ON DATABASE cspspark TO cspspark;\n",
  "entitlement.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'entitlement') THEN CREATE ROLE entitlement; END IF; END $$;\nGRANT entitlement TO postgres;\nALTER USER entitlement WITH LOGIN PASSWORD 'ENTITLEMENT_PASSWORD';\nSELECT 'CREATE DATABASE entitlement' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'entitlement')\\gexec\nALTER DATABASE entitlement OWNER TO entitlement;\nGRANT ALL PRIVILEGES ON DATABASE entitlement TO entitlement;\n",
  "identityresourceservice.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'identityresourceservice') THEN CREATE ROLE identityresourceservice; END IF; END $$;\nGRANT identityresourceservice TO postgres;\nALTER USER identityresourceservice WITH LOGIN PASSWORD 'IDENTITYRESOURCESERVICE_PASSWORD';\nSELECT 'CREATE DATABASE identityresourceservice' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'identityresourceservice')\\gexec\nALTER DATABASE identityresourceservice OWNER TO identityresourceservice;\nGRANT ALL PRIVILEGES ON DATABASE identityresourceservice TO identityresourceservice;\n",
  "messagequeue.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'messagequeue') THEN CREATE ROLE messagequeue; END IF; END $$;\nGRANT messagequeue TO postgres;\nALTER USER messagequeue WITH LOGIN PASSWORD 'MESSAGEQUEUE_PASSWORD';\nSELECT 'CREATE DATABASE messagequeue' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'messagequeue')\\gexec\nALTER DATABASE messagequeue OWNER TO messagequeue;\nGRANT ALL PRIVILEGES ON DATABASE messagequeue TO messagequeue;\n",
  "modmon.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'modmon') THEN CREATE ROLE modmon; END IF; END $$;\nGRANT modmon TO postgres;\nALTER USER modmon WITH LOGIN PASSWORD 'MODMON_PASSWORD';\nSELECT 'CREATE DATABASE modmon' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'modmon')\\gexec\nALTER DATABASE modmon OWNER TO modmon;\nGRANT ALL PRIVILEGES ON DATABASE modmon TO modmon;\n",
  "oauthproviders.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'oauthproviders') THEN CREATE ROLE oauthproviders; END IF; END $$;\nGRANT oauthproviders TO postgres;\nALTER USER oauthproviders WITH LOGIN PASSWORD 'OAUTHPROVIDERS_PASSWORD';\nSELECT 'CREATE DATABASE oauthproviders' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'oauthproviders')\\gexec\nALTER DATABASE oauthproviders OWNER TO oauthproviders;\nGRANT ALL PRIVILEGES ON DATABASE oauthproviders TO oauthproviders;\n",
  "predenv.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'predenv') THEN CREATE ROLE predenv; END IF; END $$;\nGRANT predenv TO postgres;\nALTER USER predenv WITH LOGIN PASSWORD 'PREDENV_PASSWORD';\nSELECT 'CREATE DATABASE predenv' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'predenv')\\gexec\nALTER DATABASE predenv OWNER TO predenv;\nGRANT ALL PRIVILEGES ON DATABASE predenv TO predenv;\n",
  "sushihydra.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'sushihydra') THEN CREATE ROLE sushihydra; END IF; END $$;\nGRANT sushihydra TO postgres;\nALTER USER sushihydra WITH LOGIN PASSWORD 'SUSHIHYDRA_PASSWORD';\nSELECT 'CREATE DATABASE sushihydra' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'sushihydra')\\gexec\nALTER DATABASE sushihydra OWNER TO sushihydra;\nGRANT ALL PRIVILEGES ON DATABASE sushihydra TO sushihydra;\n",
  "secretmgmt.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'secretmgmt') THEN CREATE ROLE secretmgmt; END IF; END $$;\nGRANT secretmgmt TO postgres;\nALTER USER secretmgmt WITH LOGIN PASSWORD 'SECRETMGMT_PASSWORD';\nSELECT 'CREATE DATABASE secretmgmt' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'secretmgmt')\\gexec\nALTER DATABASE secretmgmt OWNER TO secretmgmt;\nGRANT ALL PRIVILEGES ON DATABASE secretmgmt TO secretmgmt;\n",
  "memoryservice.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'memoryservice') THEN CREATE ROLE memoryservice; END IF; END $$;\nGRANT memoryservice TO postgres;\nALTER USER memoryservice WITH LOGIN PASSWORD 'MEMORYSERVICE_PASSWORD';\nSELECT 'CREATE DATABASE memoryservice' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'memoryservice')\\gexec\nALTER DATABASE memoryservice OWNER TO memoryservice;\nGRANT ALL PRIVILEGES ON DATABASE memoryservice TO memoryservice;\n",
  "apigateway.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'apigateway') THEN CREATE ROLE apigateway; END IF; END $$;\nGRANT apigateway TO postgres;\nALTER USER apigateway WITH LOGIN PASSWORD 'APIGATEWAY_PASSWORD';\nSELECT 'CREATE DATABASE apigateway' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'apigateway')\\gexec\nALTER DATABASE apigateway OWNER TO apigateway;\nGRANT ALL PRIVILEGES ON DATABASE apigateway TO apigateway;\n",
  "pipelines.sql": "DO $$ BEGIN IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'pipelines') THEN CREATE ROLE pipelines; END IF; END $$;\nGRANT pipelines TO postgres;\nALTER USER pipelines WITH LOGIN PASSWORD 'PIPELINES_PASSWORD';\nSELECT 'CREATE DATABASE pipelines' WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'pipelines')\\gexec\nALTER DATABASE pipelines OWNER TO pipelines;\nGRANT ALL PRIVILEGES ON DATABASE pipelines TO pipelines;\n"
}