Configure Server Authentication#

DPS supports Lightweight Directory Access Protocol (LDAP), OpenID Connect (OIDC), service-specific mutual TLS (mTLS), and external authentication and authorization. For evaluation, you can use permissive authentication. Choose the authentication mode before deployment.

This guide is for administrators configuring the server and its UI integration. For client sign-in procedures, refer to Sign In to DPS. For applications and scripts, refer to Service Accounts.

Authentication verifies an identity. Authorization determines whether that identity can access the requested API. Transport Layer Security (TLS) encrypts the connection and verifies the server identity. Configure both access controls and transport security.

Choose an Authentication Mode#

Use the following table to select the server’s authentication mode and prepare the required identity infrastructure.

Authentication mode	Server behavior	Requirements
LDAP	Validates directory credentials and issues DPS tokens.	LDAP directory, bind credentials, access groups, and a persistent signing key.
OIDC	Validates tokens issued by an identity provider.	Issuer, signing keys, API audience, scopes, and registered clients.
Service-specific mTLS	Accepts trusted client certificates for permitted gRPC services.	Server and client certificates, service common name (CN) allowlists, and a TLS path that preserves client identity.
External authentication and authorization	Delegates caller authentication and API access decisions to an external proxy service.	Proxy service, access policies, verified identity headers, and request routing.
Permissive evaluation authentication	Accepts arbitrary username/password credentials and issues tokens.	An isolated evaluation environment.

LDAP and built-in OIDC validation are alternative server modes. Service-specific certificate authentication can accompany either mode. External authentication and authorization delegate both checks to the external integration. This mode controls caller access to DPS; it does not configure credentials for an outbound proxy connection.

The UI uses the HTTP API; dpsctl uses gRPC. A certificate accepted for a gRPC service does not provide a browser sign-in method.

Configure LDAP Mode#

In LDAP mode, the server checks usernames and passwords against your LDAP directory. It then issues access and refresh tokens for the UI and dpsctl. You need a directory bind account, a search base covering your users and groups, and a persistent RSA signing key.

Use the following overlay with the bind and certificate Secret configuration in LDAP Credentials.

Replace the example group names with groups from your directory. For protected API requests, an identity must belong to exactly one group in dps.auth.auth_required_groups. Membership in zero or multiple listed groups fails authorization, even if username/password login succeeds.

Choose the group resolver that matches your directory.

`dps.ldap.groupProfile`	Group membership lookup
Empty or `custom`	Uses your configured `groupFilter` and `groupAttribute`.
`groupOfNames`	Uses groups whose `member` attribute contains the user DN.
`rfc2307`	Resolves POSIX secondary groups through `memberUid` and primary groups through `gidNumber`. Ignores `groupFilter`.
`activeDirectory`	Uses Active Directory groups whose `member` attribute contains the user DN.

For groupOfNames and activeDirectory, a custom groupFilter overrides the profile’s default filter. Match userFilter to your directory’s username attribute. Refer to User Accounts and Service Accounts for account examples.

The default token lifetimes are 15 minutes for access tokens and 24 hours for refresh tokens. Configure them with dps.auth.jwt.accessTokenTTL and dps.auth.jwt.refreshTokenTTL. For client login and refresh behavior, refer to dpsctl login.

Configure OIDC Mode#

In OIDC mode, your identity provider issues tokens. The server validates them against the configured issuer, JSON Web Key Set (JWKS), audience, and required scopes. DPS username/password token issuance is disabled.

Register separate identity-provider clients for the UI, interactive dpsctl, and automation. Configure the provider to issue tokens for your API audience and grant the API scope only to identities that need access.

Register the UI and interactive dpsctl as public clients without a client secret. Neither sends a client secret during token exchange. Register service-account clients separately for the client-credentials grant.

Use the following client registration settings.

Client	Client type	Grant or flow	Client secret
UI	Public	Authorization code with Proof Key for Code Exchange (PKCE).	None.
Interactive `dpsctl`	Public	Device authorization grant.	None.
Applications and scripts	Confidential	OAuth 2.0 client-credentials grant.	Required for the `dpsctl` client-credentials flow.

The following overlay uses scope-based access. It explicitly disables the additional group membership check.

Use your provider’s issuer and JWKS URLs. The server requires a signed JSON Web Token (JWT) with the expected issuer and audience, a nonempty subject, and a valid expiration. Every configured requiredScopes entry must be present. If you set allowedClientIds, the token’s azp claim must match an entry.

To restrict access by groups as well, set dps.auth.auth_required_groups and dps.auth.oidc.groupsClaim. The group claim defaults to groups and supports a dotted path for nested claims. Each identity must match exactly one required group. Group membership does not replace the required API scopes.

For a private certificate authority, mount its CA bundle and set dps.auth.oidc.caCertFile. Keep issuer and JWKS URLs on HTTPS, and keep dps.auth.oidc.allowHTTP disabled outside local development.

Configure the UI Client#

Configure the UI public OIDC client for the authorization code flow with PKCE. Register https://ui.dps.example.com/login/oauth as the redirect URI and https://ui.dps.example.com/login as the post-logout URI. Use your actual UI origin. Override these defaults with ui.auth.redirectUrl and ui.auth.oidc.postLogoutRedirectUrl when needed.

The UI discovers the provider endpoints from dps.auth.oidc.issuer and sends the access token with API requests. For UI sign-in, refer to Sign In to the UI.

Configure the CLI Clients#

Enable the device authorization grant for the public interactive CLI client. For client login and endpoint overrides, refer to dpsctl login.

For scripts and services, enable the OAuth 2.0 client-credentials grant on a separate confidential client. For token acquisition and secret handling, refer to Obtain a Service Account Token.

Some deployments accept an ID token for API access. Use ui.auth.oidc.useIdTokenForApiRequests: true or dpsctl login --id-token only when your API or proxy accepts that token’s audience and other required claims. Access tokens are the default for both clients.

For protected Prometheus metrics, configure the separate dps:metrics:read scope and scrape credentials in Protect the Metrics Endpoint.

Configure Service-Specific mTLS#

You can allow machine clients to authenticate with mutual TLS (mTLS) to specific gRPC services. Configure dps.grpcServiceMTLSCN with each service’s fully qualified name and permitted client certificate common names (CNs).

The following overlay allows a machine client to query the server version and manage topologies. Provision its certificate and private key outside the chart.

dps:
  grpcServiceMTLSCN:
    nvidia.dcpower.v1.VersionService:
      - dps-operator
    nvidia.dcpower.v1.TopologyManagementService:
      - dps-operator

With server transport tls, clients can present either a permitted certificate or a valid bearer token. A verified certificate whose CN matches the requested service permits access without a token. Other requests continue through token validation. A certificate listed for one service does not grant access to unlisted services.

Server transport mtls requires every client to present a trusted certificate during the TLS handshake, including clients that also use tokens. You still need service CN allowlists for clients that authenticate without a token.

The client connection must reach the server without an ingress replacing its certificate identity. For NGINX or Traefik, set dps.ingress.tlsPassthrough: true and configure the controller for TLS passthrough. The server certificate must cover the public API hostname.

For client certificate flags and a connection example, refer to Mutual TLS.

For agents, configure the DPSAgentService allowlist and agent certificate Secret as described in Deployment and Configuration Guide. For human UI access, retain LDAP or OIDC sign-in. A deployment using only machine certificates does not provide DPS username/password login when local token issuance is disabled.

Configure External Authentication and Authorization#

Use this mode to delegate caller authentication and API access decisions to an external proxy service. The proxy applies your access requirements and forwards accepted gRPC requests to DPS. It can perform authentication, authorization, or both, using its own logic or services it calls. The external integration must enforce all required checks because built-in gRPC authentication and authorization are disabled in this mode.

Deploy a custom or platform-provided sidecar in the DPS server Pod. Install and configure the sidecar independently of the DPS chart.

Configure Proxy Access Controls#

Configure your external integration to meet the following requirements.

Apply your authentication and authorization policy to every protected gRPC method, including streaming calls and calls originating from the HTTP gateway.
Strip caller-supplied identity headers and set verified identity metadata. Use the header selected by dps.auth.externalSubjectHeader, default x-user-id, for caller attribution in DPS logs.
Configure TLS, identity-provider trust, and access policies in the proxy or surrounding platform. Configure internal clients, including the agent, to supply credentials accepted by that policy.
Route all client API traffic through the external checks. Keep the backend listener inaccessible to clients that could bypass those checks.

The verified subject header provides log attribution; it does not trigger built-in group or scope checks. Those access decisions belong to the external integration. DPS server token issuance is also disabled in this mode.

Configure Proxy Routing#

The following overlay enables delegation and configures OIDC sign-in for the UI. The issuer supplies UI discovery settings; the proxy validates API tokens.

The chart sends HTTP gateway calls through the sidecar so the UI’s API requests pass through the external access checks. Configure the following routing in your deployment.

Configure a local plaintext HTTP/2 listener on the port selected by dps.auth.external.proxyPort, default 8081. The HTTP gateway uses this listener on loopback.
Forward permitted requests to the DPS loopback listener, default 127.0.0.1:50051, using plaintext HTTP/2.
Redirect the gRPC Service’s targetPort to the proxy’s client-facing listener. Keep the Service port unchanged, default 8080. If the proxy terminates TLS on a separate listener, route the Service to that TLS port and retain the local plaintext listener for HTTP gateway calls.

With a local plaintext proxy listener and the default ports, the path is Service :8080 → proxy :8081 → DPS :50051.

You can use a custom sidecar or one provided by your platform, as long as it meets these requirements. Configure the container and Service routing through your deployment or admission injector.

Enabling dps.auth.external.enabled configures the server integration only. It does not install a proxy or policies, or redirect the Service. Without the proxy integration and routing, clients cannot reach the backend.

Configure UI OIDC client registration as described in Configure OIDC Mode, using scopes and token settings accepted by the proxy. Keep dps.auth.oidc.enabled: false in this mode; the issuer setting supplies UI discovery only. For client access, refer to Sign In to DPS and Service Accounts. DPS username/password login requires a compatible external token endpoint; the server itself does not issue tokens in this mode.

Configure Permissive Authentication for Evaluation#

The Helm chart defaults to alwaysAllow when LDAP is disabled and dps.auth.authenticatorType is empty. This accepts arbitrary username/password credentials and issues DPS tokens. It is suitable only for isolated evaluation and testing. Do not use this setting in production.

Explicitly select permissive authentication in an evaluation overlay:

dps:
  auth:
    authenticatorType: alwaysAllow
  ldap:
    enabled: false
ui:
  auth:
    provider: dps

Keep the chart’s default access group dcpower-users if you retain group checks; evaluation tokens include that membership.

When you run dps-server directly, an unset authenticator requires LDAP to be enabled. To select permissive authentication, explicitly set --authenticator-type=alwaysAllow. Configuring TLS does not make this authenticator suitable for production.

Verify the Configuration#

Before installation, render your chosen overlay together with the deployment values as described in Deployment and Configuration Guide. Check the authentication environment variables, certificate mounts, and UI provider in the rendered resources. For an external proxy, also check the proxy deployment and Service routing in your deployment manifests.

After deployment, complete the following checks:

Confirm the server and any required authentication sidecars are ready. For external authentication and authorization, confirm the sidecar’s listener ports and Service routing match your configuration.
Authenticate an allowed identity by following Sign In to DPS or Service Accounts.
Request the server version to verify authenticated API access. For a token-based client, use the following command with your endpoint and CA.
```
dpsctl --host api.dps.example.com --port 443 \
  --ca-cert-path /path/to/api-ca.crt server-version
```
For certificate clients, use the command in Mutual TLS.
Open the UI and confirm that an allowed API request succeeds after sign-in.
Verify that an identity outside the configured access policy cannot call a protected API. Test authentication and authorization separately; successful sign-in does not prove that access rules are correct.

Use the following checks when connection or access fails:

Symptom	Check
TLS connection fails	Verify the hostname, trusted CA, endpoint port, and any global client-certificate requirement.
LDAP login fails	Verify the directory credentials, bind Secret, search base/filter, and LDAP certificates.
OIDC login fails	Verify the registered client, requested scopes, UI callback URI, or CLI device-grant configuration.
Login succeeds but an API request is denied	Check required groups, scopes, audience, allowed client IDs, or the external proxy policy.
Certificate access fails	Verify the certificate chain, requested service CN allowlist, and TLS passthrough.
External proxy requests cannot connect	Check proxy availability, loopback connectivity, listener ports, and Service routing.

Refer to Cannot Connect or Log In for diagnostic commands and error codes. Share redacted errors and configuration; keep passwords, tokens, cookies, and private keys out of logs and support materials.