Automation Accounts#

Overview#

Automation accounts are non-interactive service accounts intended for system-to-system authentication with Dynamic Power Software (DPS). Typical use cases include cluster services (for example the Power Reservation Steering – PRS), CI/CD jobs, or any automated workflow that needs to call the DPS gRPC or REST API without relying on a human user.

Unlike regular user accounts, automation accounts

  • live in a dedicated organizational unit (OU) – ou=automation-users – within the enterprise directory service (for example LDAP),

  • are members of the automation-users LDAP group, and

  • are granted the automation role inside DPS. This role authorises programmatic access while restricting interactive actions reserved for administrators.

How an automation account authenticates depends on the DPS authentication mode:

  • In the default LDAP-backed mode the account is an LDAP service user that exchanges a username and password for DPS-issued tokens.

  • In OIDC mode the account is an OAuth client that obtains a token from the external identity provider (for example, Keycloak) using the OAuth 2.0 Client Credentials grant.

The remainder of this guide explains how to create an automation account in an LDAP-backed deployment, configure DPS to recognise it, and obtain access tokens for use with dpsctl or any DPS client. A later section summarizes the OIDC client-credentials flow.

Creating an Automation Account in LDAP#

In the reference OpenLDAP chart shipped with DPS the automation tree looks like this:

ou=automation-users,dc=cm,dc=cluster        # Service account organisational unit
cn=automation-users,dc=cm,dc=cluster        # LDAP group for all automation accounts

A minimal LDIF snippet for a new automation user (myservice) is shown in the following example. Adjust UID/GID numbers and the password to suit your environment.

# New automation user
dn: uid=myservice,ou=automation-users,dc=cm,dc=cluster
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
cn: myservice
sn: service
uid: myservice
uidNumber: 20001
gidNumber: 20000                          # Should match the automation group GID
homeDirectory: /home/myservice
loginShell: /usr/sbin/nologin
mail: myservice@cm.cluster
userPassword: ${SSHA_PASSWORD_HASH}

# Add the user to the automation group
dn: cn=automation-users,dc=cm,dc=cluster
changetype: modify
add: member
member: uid=myservice,ou=automation-users,dc=cm,dc=cluster

After applying the LDIF you can verify the account by binding to LDAP, for example:

ldapwhoami \
  -x -H ldaps://openldap.dps.svc.cluster.local:636 \
  -D "uid=myservice,ou=automation-users,dc=cm,dc=cluster" \
  -w <password>

Configuring DPS to Discover Automation Accounts#

DPS authenticates users via its LDAPAuthenticator. To ensure automation users are discovered, the LDAP user filter must include the automation OU. A safe default is:

(|(&(objectClass=inetOrgPerson)(uid={username})(ou=users)) \
  (&(objectClass=inetOrgPerson)(uid={username})(ou=automation-users)))

If your directory contains only users and automation-users OUs you may simply use:

(&(objectClass=inetOrgPerson)(uid={username}))

Note: After changing the DPS configuration restart the dps-server Pod / service for the change to take effect.

Obtaining a DPS Token Using an Automation Account#

Automation accounts authenticate with DPS using the nvidia.dcpower.v1.AuthService/Token gRPC endpoint (or the equivalent REST gateway, if enabled). The request supplies the account’s username and password and returns a short-lived access token plus a long-lived refresh token.

Example using grpcurl:

grpcurl -d '{
  "passwordCredential": {
    "username": "myservice",
    "password": "<password>"
  }
}' \
  -plaintext dps-server.dps.svc.cluster.local:50050 \
  nvidia.dcpower.v1.AuthService/Token

The JSON response contains accessToken and refreshToken fields. Export the access token for clients that accept bearer tokens directly:

export DPS_ACCESS_TOKEN=<accessToken>

For dpsctl, store the automation account credentials with login:

printf '%s\n' '<password>' | dpsctl login --username myservice --password-stdin

dpsctl stores the returned tokens in its credentials file and refreshes them when needed. For other clients, call nvidia.dcpower.v1.AuthService/RefreshToken with the stored refresh token to obtain a new pair when the access token expires.

OIDC / OAuth 2.0 Client Credentials#

When DPS runs in OIDC mode, automation accounts use OAuth clients instead of LDAP service users. dpsctl can obtain a short-lived service-account token from the OIDC provider using the OAuth 2.0 Client Credentials grant.

Provide the token endpoint, client ID, and client secret. Prefer the secret-file form:

DPSCTL_CLIENT_ID=<oauth-client-id> \
DPSCTL_CLIENT_SECRET_FILE=/path/to/client-secret \
DPSCTL_OIDC_TOKEN_URL=https://<keycloak-host>/realms/<realm>/protocol/openid-connect/token \
dpsctl --host <dps-api-host> --port <grpc-port> topology list

dpsctl requests the dps:api scope by default and caches valid client-credentials tokens in the credentials file. The token endpoint must use HTTPS unless local development explicitly enables --oidc-allow-http.

The available flags, environment variables, secret-file option, and cache behavior are documented in the dpsctl flag reference.

Note: Client credentials apply to normal dpsctl commands. They are not used by dpsctl login, which performs interactive username/password authentication for human users.

Best Practices#

  • Minimum privilege – create separate automation accounts for each service and grant only the roles they require.

  • Rotate credentials – periodically change the LDAP password and revoke refresh tokens.

  • Use TLS – always connect to both LDAP and DPS over TLS for production deployments.

  • Store secrets securely – keep passwords and tokens in a secret management system such as Kubernetes Secrets or HashiCorp Vault.

Further Reading#