User Accounts#

Overview#

User accounts represent individual people who operate Dynamic Power Software (DPS) through the command-line interface (dpsctl), the web UI, or directly via the gRPC / REST API. These accounts are interactive and are expected to authenticate with a username and password.

In a standard DPS deployment backed by OpenLDAP, user accounts:

  • reside in the ou=users organisational unit (OU);

  • are usually members of one or more LDAP groups such as rogroup (read-only) or dcpower-users (full control);

  • map to DPS roles via their group membership – for example users in the dcpower-users group receive the admin role, those only in rogroup receive read privileges.

This guide covers how to create a user account in LDAP, how to sign-in using dpsctl, and general best practices.

LDAP Groups and Roles#

The reference OpenLDAP chart creates the following groups:

  • rogroup – Basic read-only access to LDAP (all users should be members)

  • dcpower-users – Full access to DPS functionality (located in ou=groups)

  • automation-users – Special group for automation accounts (located in ou=groups)

Users must be members of dcpower-users to access DPS functionality. Users who are only members of rogroup will have limited access.

Default Users#

The reference OpenLDAP chart creates the following example users for development and testing:

  • root / root – LDAP administrator with full access

  • testuser / testuser – Regular user with DPS access (member of both rogroup and dcpower-users)

  • non-dcpower-user / non-dcpower-user – Test user without DPS access (member of rogroup only)

Creating a User Account in LDAP#

Below is a minimal LDIF example that adds a new human user (alice). Update UID/GID numbers and the password hash as appropriate for your directory.

# New user
dn: uid=alice,ou=users,dc=cm,dc=cluster
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
cn: Alice
sn: Example
uid: alice
uidNumber: 15001
gidNumber: 15000                      # primary group id (e.g. rogroup)
homeDirectory: /home/alice
loginShell: /bin/bash
mail: alice@example.com
userPassword: ${SSHA_PASSWORD_HASH}

# Add to read-only group
dn: cn=rogroup,dc=cm,dc=cluster
changetype: modify
add: member
member: uid=alice,ou=users,dc=cm,dc=cluster

# Add to dcpower-users group (for full DPS access)
# (comment out if user should only have read-only access)
dn: cn=dcpower-users,ou=groups,dc=cm,dc=cluster
changetype: modify
add: member
member: uid=alice,ou=users,dc=cm,dc=cluster

After applying the LDIF you can verify the new account:

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

Signing-in to DPS (dpsctl login)#

The preferred way for human users to obtain DPS tokens is the dpsctl login command. It exchanges the username/password for an access token (short-lived) and a refresh token (long-lived) which are stored securely in ${HOME}/.dpsctl/credentials.yaml.

Non-interactive (standard input or environment variables)#

# Using standard input
printf '%s\n' '<password>' | dpsctl login --username alice --password-stdin

# Using environment variables
export DPSCTL_USERNAME=alice
export DPSCTL_PASSWORD=<password>
dpsctl login

Interactive prompt#

If no credentials are supplied, dpsctl login will prompt for them and then write the tokens to the credentials file.

Once logged in you can run any dpsctl sub-command:

dpsctl topology list

Behind the scenes dpsctl automatically refreshes the access token when it expires using the stored refresh token.

Programmatic Token Retrieval#

Applications that need to authenticate programmatically (for example scripts) can call the gRPC endpoint directly, mirroring the automation-account flow:

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

Best Practices#

  • Principle of least privilege – assign users only to the groups (roles) they require.

  • Password policy – enforce strong passwords and rotate them periodically.

  • MFA – integrate LDAP with an MFA solution when possible.

  • TLS everywhere – ensure both LDAP and DPS connections are encrypted in production.

  • Account lifecycle – deactivate or remove accounts when users leave the organisation.

Further Reading#