Service Accounts#

Overview#

Service accounts identify applications, services, and scripts that call Dynamic Power Software (DPS) without an interactive user sign-in. Use a separate identity for each service, such as Power Reservation Steering (PRS) or a deployment job.

Use this guide to connect services and scripts to an already configured DPS server. Your administrator provides the API endpoint, trusted certificates, and account credentials. Administrators configuring server authentication should follow Configure Server Authentication.

DPS supports the following authentication modes for service accounts:

In Lightweight Directory Access Protocol (LDAP) mode, a directory service account exchanges a username and password for DPS tokens.
In OpenID Connect (OIDC) mode, a confidential OAuth client obtains an access token from the identity provider through the client credentials grant.
With mutual TLS (mTLS), a client authenticates with a certificate approved for the requested gRPC service.

Use the mode your administrator configured. When an external service handles authentication and authorization, your administrator specifies the accepted tokens or certificates through Configure External Authentication and Authorization.

LDAP#

Create a Service Account#

Ask your directory administrator to provision a service account with the required group membership. The reference OpenLDAP chart places its PRS service account in ou=users and uses the following group:

cn=automation-users,ou=groups,dc=cm,dc=cluster

If you administer the directory, use the following LDAP Data Interchange Format (LDIF) example to add myservice. Replace the user and group IDs and the password hash with values for your directory.

After applying the LDIF, verify the account with a password prompt:

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

Account Discovery Requirements#

Your server administrator must set dps.ldap.baseDn to a directory subtree that contains the account and configure dps.ldap.userFilter to match its attributes. The preceding example uses dc=cm,dc=cluster as the search base and this user filter:

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

Directory administrators can place service accounts in a dedicated organizational unit (OU) if the search base includes it. An account’s location under an OU does not add an ou attribute. Match attributes present on the user entry.

Ask your server administrator to check group resolution and required API group membership through Configure LDAP Mode. Server administrators apply configuration changes through their deployment workflow and restart the server to load them.

Obtain a DPS Token#

In LDAP mode, nvidia.dcpower.v1.AuthService/Token exchanges a passwordCredential containing username and password for an access token and a refresh token. Send this request over Transport Layer Security (TLS). The response contains accessToken and refreshToken fields.

For dpsctl, use the endpoint and TLS options for your deployment, and enter the service-account password at the prompt:

dpsctl login --username myservice

For unattended provisioning, supply the password to --password-stdin through your secret-management workflow. dpsctl stores the returned tokens in its credentials file and refreshes them when needed.

Other clients call nvidia.dcpower.v1.AuthService/RefreshToken with the stored refresh token when the access token expires. Refer to APIs for request and response definitions. Verify the account’s API access after token issuance through Verify the Configuration.

OIDC#

In OIDC mode, service accounts use OAuth clients. Ask your identity-provider administrator to register a separate confidential client for each service, enable the OAuth 2.0 client credentials grant, and provide its client ID and secret. The UI and interactive dpsctl use separate public clients without client secrets.

Obtain a Service Account Token#

dpsctl can obtain a short-lived service account token from the OIDC provider using the client credentials grant.

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

DPSCTL_OIDC_CLIENT_ID=<oauth-client-id> \
DPSCTL_OIDC_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.

Client credentials apply to normal dpsctl commands. Use dpsctl login for interactive sign-in through LDAP or the OIDC device authorization flow.

Mutual TLS#

Authenticate with a Client Certificate#

Ask your administrator for a trusted client certificate and private key. The certificate common name (CN) must be permitted for each gRPC service you call. For server configuration, refer to Configure Service-Specific mTLS.

Use the following command when the certificate permits VersionService requests. Replace the hostname, port, and certificate paths with your values. Omit --ca-cert-path if the server certificate uses a certificate authority (CA) your system trusts.

dpsctl --host api.dps.example.com --port 443 --auth-mode mtls \
  --ca-cert-path /path/to/api-ca.crt \
  --client-cert-path /path/to/client.crt \
  --client-key-path /path/to/client.key server-version

No dpsctl login step is required. The mtls client mode sends no bearer token. A certificate accepted for one service does not grant access to other services. For certificate options and other client modes, refer to Flags.

Best Practices#

Use the following practices to manage service accounts:

Create separate identities for each service and grant only the permissions they require.
Rotate LDAP passwords, OAuth client secrets, or client certificates through the system that manages each identity.
Encrypt LDAP, identity-provider, and DPS connections in secure deployments.
Keep passwords, tokens, and client keys in a secret management system such as Kubernetes Secrets or HashiCorp Vault.