User Accounts

User Accounts

Overview

User accounts represent individual people who operate Domain Power Service (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}/.config/dpsctl/credentials.yml.

Non-interactive (flags or environment variables)

# Using flags
dpsctl login --username alice --password <password>

# Using environment variables
export DPS_USERNAME=alice
export DPS_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

• Automation Accounts – for non-interactive service accounts.
• dpsctl installation instructions