Credentials and Secrets Configuration#

Overview#

The DPS server requires various secrets for secure operations, including database credentials, authentication details, and BMC credentials depending on the configured store.

Secrets#

Create Secret contents through your approved secret-management workflow. Do not put passwords, tokens, or private keys in Helm values or source control. For Helm deployments, prepare these Secrets as applicable:

  • A gRPC server identity referenced by dps.serverTLS.existingSecret, with tls.crt, tls.key, and ca.crt.

  • API and UI ingress identities referenced by dps.ingress.tls and ui.ingress.tls, with tls.crt and tls.key.

  • PostgreSQL credentials and trust material as described in Database Secrets and Database TLS.

  • LDAP bind, certificate, and JWT signing material as described in LDAP Credentials.

  • Direct Redfish credentials as described in Kubernetes Secret Store.

Database Secrets#

Database Credentials: Essential for the PostgreSQL database connection. These are always file-mounted in the DPS server filesystem.

The DPS server looks for database credentials using the following process:

Username:

  • Read from --db-user command line parameter, or

  • Read from DB_USERNAME environment variable, or

  • Defaults to “dps” if neither is set

Password:

  • Read from file: <DB_SECRET_MOUNT_PATH>/postgres/password

  • If file reading fails, falls back to credentials store (if configured)

  • There is no raw --db-password flag or DB_PASSWORD environment variable.

File Structure:

<DB_SECRET_MOUNT_PATH>/postgres/
└── password    # Database password (required)

Example of the Password File Contents:

# /home/nonroot/secrets/postgres/password
<database-password>

The database connection settings can be configured using command line parameters or environment variables. The password itself is file-mounted.

Command Line Parameters

dps-server \
  --db-host="localhost" \
  --db-port=5432 \
  --db-name="dps" \
  --db-user="dps" \
  --db-secret-mount-path="/home/nonroot/secrets"

Environment Variables

export DB_HOST="localhost"
export DB_PORT=5432
export DB_NAME="dps"
export DB_USERNAME="dps"
export DB_SECRET_MOUNT_PATH="/home/nonroot/secrets"
# Password file expected at: /home/nonroot/secrets/postgres/password
dps-server

For PostgreSQL certificate verification and client-certificate authentication, refer to Database TLS.

Helm Chart Configuration

global:
  postgresql:
    auth:
      database: "dps"
      username: "dps"
      existingSecret: "dps-postgresql"

The DPS server reads the key selected by global.postgresql.auth.secretKeys.passwordKey, which defaults to password. The chart-managed PostgreSQL workload reads the key selected by global.postgresql.auth.secretKeys.userPasswordKey, which defaults to database-password. When chart-managed PostgreSQL is disabled, include the second key only when another enabled chart component requires it.

LDAP Credentials#

LDAP Credentials: Required if LDAP authentication is enabled. These include the bind DN, bind password, and TLS certificates for secure LDAP communication. LDAP configuration allows DPS to authenticate users against an external directory service.

Command Line Parameters

dps-server \
  --ldap-enabled=true \
  --ldap-server-url="ldaps://openldap.dps.svc.cluster.local:636" \
  --ldap-bind-dn="cn=root,dc=cm,dc=cluster" \
  --ldap-bind-password-file="/home/nonroot/secrets/dps-openldap/bind-password" \
  --ldap-default-role="" \
  --ldap-tls-ca-cert="/home/nonroot/secrets/dps-openldap/ca.crt" \
  --ldap-tls-client-cert="/home/nonroot/secrets/dps-openldap/client.crt" \
  --ldap-tls-client-key="/home/nonroot/secrets/dps-openldap/client.key"

Environment Variables

export LDAP_ENABLED=true
export LDAP_SERVER_URL="ldaps://openldap.dps.svc.cluster.local:636"
export LDAP_BIND_DN="cn=root,dc=cm,dc=cluster"
export LDAP_BIND_PASSWORD_FILE="/home/nonroot/secrets/dps-openldap/bind-password"
export LDAP_DEFAULT_ROLE=""
export LDAP_TLS_CA_CERT="/home/nonroot/secrets/dps-openldap/ca.crt"
export LDAP_TLS_CLIENT_CERT="/home/nonroot/secrets/dps-openldap/client.crt"
export LDAP_TLS_CLIENT_KEY="/home/nonroot/secrets/dps-openldap/client.key"
dps-server

Helm Chart Configuration

dps:
  auth:
    authenticatorType: "ldap"
    auth_required_groups: "<dps-admin-group>,<dps-automation-group>"
    jwt:
      existingSecret: "dps-jwt-keys"
  ldap:
    enabled: true
    serverUrl: "ldaps://ldap.example.com:636"
    bindDn: "<bind-dn>"
    baseDn: "<base-dn>"
    bindPassword:
      existingSecret: "dps-ldap-bind"
      existingSecretKey: "bind-password"
    defaultRole: ""
    groupRoleMapping: "<dps-admin-group>=admin,<dps-automation-group>=automation"
    certSource: "file"
    tlsCaCert: "/home/nonroot/secrets/dps-openldap/ca.crt"
    tlsClientCert: "/home/nonroot/secrets/dps-openldap/client.crt"
    tlsClientKey: "/home/nonroot/secrets/dps-openldap/client.key"
    volumeMounts:
      - name: ldap-certs
        mountPath: "/home/nonroot/secrets/dps-openldap"
        readOnly: true
    volumes:
      - name: ldap-certs
        secret:
          secretName: "dps-ldap-certs"

Map each permitted identity to exactly one group listed in dps.auth.auth_required_groups. DPS rejects login when an identity matches none or more than one of those groups.

Create dps-ldap-bind with the bind-password data key and dps-ldap-certs with the CA, client certificate, and client key shown. Create dps-jwt-keys with private-key.pem, which must contain an RSA private key in PEM format of at least 2,048 bits. Use your approved Secret workflow; do not put the bind password or private keys in values.yaml.

BMC Redfish API Credentials#

The DPS server requires BMC API credentials for each managed node in the topology. It can read these credentials from BCM, Kubernetes Secrets, or files.

Credentials Store Types#

  • bcm: The Base Command Manager (BCM) is NVIDIA’s cluster management solution that provides centralized management of datacenter resources, including secure storage and retrieval of BMC (Baseboard Management Controller) credentials for Redfish API access. This store uses the BCM API to fetch credentials. Requires BCM version 11. Use this store when your infrastructure is managed by BCM to enable seamless integration and centralized credential management.

  • k8sSecret: Use in Kubernetes environments for native secret management. Supports in-cluster and cross-namespace access.

  • file: Use for secrets stored as files. You can mount these files into a pod or place them directly on the filesystem. Works with static credentials that don’t change often. Can be used in both Kubernetes and bare-metal environments.

Choose based on your environment: BCM for managed clusters, Kubernetes secrets for cloud-native, file for simple file-based setups.

Credentials Store Configuration#

Setting the Credentials Store Type#

The Credentials Store Type can be configured using the --bmc-credentials-store parameter or by setting the BMC_CREDENTIALS_STORE environment variable. This configuration accepts the following values:

  • bcm

  • k8sSecret

  • file

Default Configuration:

  • If no credentials store type is specified, DPS server defaults to k8sSecret

  • This means BMC Redfish API credentials will be fetched from Kubernetes secrets using the native Kubernetes API

  • The server will attempt to retrieve BMC credentials from Kubernetes secrets in the same namespace

  • If no BMC credentials are found in Kubernetes secrets, BMC Redfish API operations will not be available

Below you can find detailed configuration examples for each credentials store type.

Credentials Store Options#
BCM Store#

Create the BCM password and TLS material through an approved Secret workflow. Do not pass the password on the command line or through a shell environment variable.

# Helm Example
dps:
  credentialsStore: "bcm"
  bcm:
    baseURL: "https://master.dps.svc.cluster.local:8443"
    auth:
      basic:
        username: "root"
        passwordSecret:
          existingSecret: "bcm-auth"
          secretKeys:
            passwordKey: "password"
      cert:
        clientCertPath: "/secrets/bcm/client.cert"
        clientKeyPath: "/secrets/bcm/client.key"
        caCertPath: "/secrets/bcm/ca.cert"
  secrets:
    - name: "dps-bcm-certs"
      secretKey: "client.cert"
      mountPath: "/secrets/bcm/client.cert"
    - name: "dps-bcm-certs"
      secretKey: "client.key"
      mountPath: "/secrets/bcm/client.key"
    - name: "dps-bcm-certs"
      secretKey: "ca.cert"
      mountPath: "/secrets/bcm/ca.cert"

Kubernetes Secret Example:

apiVersion: v1
kind: Secret
metadata:
  name: dps-bcm-certs
type: Opaque
data:
  client.cert: <base64-encoded-client-cert>
  client.key: <base64-encoded-client-key>
  ca.cert: <base64-encoded-ca-cert>

Configuration Parameters:

  • BMC_CREDENTIALS_STORE: Set to “bcm”

  • BCM_BASE_URL: BCM server headnode API URL (required)

  • BCM_USERNAME: Username for basic authentication (optional if using cert auth)

  • BCM_PASSWORD: Password for basic authentication (optional if using cert auth)

  • BCM_CLIENT_CERT: Path to client certificate (optional if using basic auth)

  • BCM_CLIENT_KEY: Path to client key (optional if using basic auth)

  • BCM_CA_CERT: Path to CA certificate (optional)

Kubernetes Secret Store#
# Environment Variables Example
BMC_CREDENTIALS_STORE=k8sSecret
# No additional parameters needed - secrets configured in cluster

# Command Line Example
dps-server --bmc-credentials-store=k8sSecret

# Helm Example
dps:
  credentialsStore: "k8sSecret"
  k8sSecret:
    labelSelector: "app.kubernetes.io/component=bmc-credentials"

Configuration Parameters:

  • BMC_CREDENTIALS_STORE: Set to “k8sSecret”

  • Each BMC Secret must match the configured label selector. The default is app.kubernetes.io/component=bmc-credentials.

  • The Secret name must match Redfish.SecretName in the topology, and its bmc data field must contain a JSON or YAML map with username and password.

Create one Secret for each credential boundary in the same namespace as DPS. Replace the placeholders through your approved Secret workflow, and do not commit a populated manifest.

Kubernetes BMC Secret example
apiVersion: v1
kind: Secret
metadata:
  name: node001-bmc
  namespace: dps
  labels:
    app.kubernetes.io/component: bmc-credentials
type: Opaque
stringData:
  bmc: |
    {
      "username": "<bmc-user>",
      "password": "<bmc-password>"
    }

Keep dps.k8sSecret.labelSelector at its restrictive default or replace it with an equally restrictive site label. When a Redfish proxy provides backend BMC authentication, follow Redfish Proxy Configuration instead of creating a direct BMC Secret for DPS.

File Store#

The File Store reads BMC credentials from a specific filesystem structure. When you set SECRET_MOUNT_PATH="/secrets", the store expects the following directory structure:

/secrets/
└── baremetal/
    ├── node1/
    │   └── bmc
    └── node2/
        └── bmc

Where:

  • node1, node2 are the hostnames of your BMC nodes

  • bmc is a file containing Redfish API credentials in JSON or YAML format

Deployment Options:

  • Kubernetes: Mount secrets as volumes using Helm (recommended for containerized deployments)

  • Bare Metal: Create directory structure directly on filesystem (for non-containerized deployments)

Example of the bmc file content:

{
  "username": "<bmc-user>",
  "password": "<bmc-password>"
}

Or in YAML format:

username: <bmc-user>
password: <bmc-password>

# Environment Variables Example
BMC_CREDENTIALS_STORE=file
SECRET_MOUNT_PATH="/secrets"

# Command Line Example
dps-server \
  --bmc-credentials-store=file \
  --secret-mount-path="/secrets"

# Helm Example
dps:
  credentialsStore: "file"
  dbSecretsMountPath: "/secrets"
  extraVolumeMounts:
    - name: bmc-credentials-node1
      mountPath: "/secrets/baremetal/node1"
      readOnly: true
    - name: bmc-credentials-node2
      mountPath: "/secrets/baremetal/node2"
      readOnly: true
  extraVolumes:
    - name: bmc-credentials-node1
      secret:
        secretName: "redfish-node1"
        items:
          - key: "bmc"
            path: "bmc"
            mode: 0400
    - name: bmc-credentials-node2
      secret:
        secretName: "redfish-node2"
        items:
          - key: "bmc"
            path: "bmc"
            mode: 0400

Kubernetes Secret Examples:

apiVersion: v1
kind: Secret
metadata:
  name: redfish-node1
type: Opaque
data:
  bmc: <base64-encoded-bmc-credentials>

---
apiVersion: v1
kind: Secret
metadata:
  name: redfish-node2
type: Opaque
data:
  bmc: <base64-encoded-bmc-credentials>

Configuration Parameters:

  • BMC_CREDENTIALS_STORE: Set to “file”

  • SECRET_MOUNT_PATH: Base directory where secrets are mounted (required)

Best Practices#

  • Use Kubernetes Secrets for sensitive data.

  • Keep certificate verification enabled under the relevant integration, such as dps.redfish.tls.insecureSkipVerify: false for direct Redfish.

  • Regularly rotate secrets.