Automation Accounts

Automation Accounts

Overview

Automation accounts are non-interactive service accounts intended for system-to-system authentication with Domain Power Service (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.

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.

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 below. 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 so CLI tools can pick it up:

export DPS_ACCESS_TOKEN=<accessToken>

Alternatively you can pass the token directly to dpsctl:

dpsctl --access-token $DPS_ACCESS_TOKEN topology list

When the access token expires call nvidia.dcpower.v1.AuthService/RefreshToken with the stored refresh token to obtain a new pair.

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

• DPS CLI (dpsctl) installation
• nvidia.dcpower.v1 API documentation