Authentication

Goal: Configure OpenID Connect (OIDC) authentication for the Storage Service stack you have deployed.

Note

Authentication is optional for initial deployment and testing. You can deploy and validate the full Storage APIs stack without OIDC, then add authentication as a follow-up step. OIDC configuration requires coordination with your identity provider administrator, which may take additional time.

The Omniverse Storage Service Adapters have been designed to work with OpenID Connect (OIDC) authentication and is configured using an Envoy proxy with an authentication extension. The authentication extension and Discovery Service are configured to validate the OIDC JWT authentication tokens.

Configure OpenID Connect (OIDC) on your identity provider

Before you deploy your services to work with OIDC authentication you will need to get configuration values from your identity provider. These are used to configure the authentication extension and Discovery Service.

Microsoft Entra ID OIDC Configuration is great sample documentation for how to configure OIDC authentication with Microsoft Entra ID. This us the Identity Provider (IDP) we used in our deployment.

Pulling the Authentication Extension

Pull and unpack the Envoy Auth Extension Helm chart from the NGC catalog. Replace {NGC_API_KEY} with your NGC API key.

# pull the chart from NGC
helm fetch https://helm.ngc.nvidia.com/nvidia/omniverse/charts/envoy-auth-extension-2.3.3.tgz --username='$oauthtoken' --password=${NGC_API_KEY}

# unpack the chart and cd into the directory
tar -xvf envoy-auth-extension-2.3.3.tgz
cd envoy-auth-extension

Create the Authentication Extension values file

Create a envoy-values.yaml file set with the proper pull secret and values for the authentication extension.

# create the file
code envoy-values.yaml

image:
  pullSecrets:
    - name: ngcpull-secret

Create the OIDC Configuration File

To configure OIDC authentication, we will start by creating a oidc-config.yaml file with the required fields. This will be shared across services that need OIDC configuration.

# create the file
code oidc-config.yaml

Below are the fields you will need to configure. Replace the {tenant-id} and {client-id} with the values you obtained from your identity provider.

openId:
enabled: true
description: "My OIDC Configuration"
openIdConfigurationUri: "https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration"
clientRegistrations:
  - name: "default"
    clientId: "{client-id}"
    scope: "openid profile email offline_access {client-id}/.default"

Install the Authentication Extension

Install the authentication extension using the envoy-values.yaml file and the odic-config.yaml file.

# install the authentication extension
helm upgrade --install envoy-auth-extension . -f envoy-values.yaml -f oidc-config.yaml

# validate the pod is running, this may take a bit to start up
kubectl get pods -n storage-apis

Update the Ingress Configuration

Update the ingress-values.yaml file we created earlier to use the authentication extension. As this file is shared by all services, you will need to update it in one place so you can then redeploy all services.

# ingress-values.yaml
httpProxy:
  enabled: true
  fqdn:
      domain: "{DNS_URL}" # e.g. my-company.storage-apis.example.com
  # update the tls section to use the secret name you deployed your certs to.
  tls:
      enabled: true
      secretName: storage-apis-cert
  authExtension:
      enabled: true

Configure the Event Consumer Service for Storage Permissions

When authentication is enabled, the Event Consumer Service can enforce per-user permissions on storage events by querying the Storage API. Add the following to your event-consumer-values.yaml:

permissions:
  content: |-
    storage_permissions_endpoints:
      - http://storage-service.storage-apis.svc.cluster.local:8012

Replace storage-service and storage-apis with the Helm release name and namespace of your Storage Service if different.

The storage_permissions_endpoints setting tells the Event Consumer Service which Storage API to query when checking whether a user has access to files referenced in storage events (e.g., omni.storage.created, omni.storage.deleted). This is required when authentication is enabled and clients consume storage events on non-durable queues.

Redeploy the Services

Redeploy the services to use the authentication extension. The oidc-config.yaml file is passed to services that need to validate tokens internally.

# redeploy the discovery service
helm upgrade --install discovery-service ./discovery-service -f ./discovery-service/discovery-values.yaml -f ./ingress-values.yaml -f ../oidc-config.yaml --namespace storage-apis

# redeploy the storage service
helm upgrade --install storage-service ./storage-service -f ./storage-service/storage-values.yaml -f ./ingress-values.yaml --namespace storage-apis

# if using notifications, redeploy the notification aggregation service
helm upgrade --install event-aggregation-service ./event-aggregation-service -f ./event-aggregation-service/event-aggregation-values.yaml -f ./ingress-values.yaml -f ../oidc-config.yaml --namespace storage-apis

# if using notifications, redeploy the notification consumer service
helm upgrade --install event-consumer-service ./event-consumer-service -f ./event-consumer-service/event-consumer-values.yaml -f ./ingress-values.yaml -f ../oidc-config.yaml --namespace storage-apis

# redeploy the storage navigator
helm upgrade --install storage-navigator ./storage-navigator -f ./storage-navigator/navigator-values.yaml -f ./ingress-values.yaml --namespace storage-apis

# validate the pods are running
kubectl get pods -n storage-apis

Test Authentication

Test authentication by accessing the services via the DNS name you configured.

# curl the auth config endpoint
curl https://{DNS_URL}/api/v1/auth-config

If everything is configured correctly on your identity provider and the services, you should see a response similar to the response below.

{
"_comment": "My OIDC Configuration",
"clients": {
    "client_library": {
    "client_id": "{client-id}",
    "scope": "openid profile email offline_access {client-id}/.default"
    },
    "default": {
    "client_id": "{client-id}",
    "scope": "openid profile email offline_access {client-id}/.default"
    },
    "navigator": {
    "client_id": "{client-id}",
    "scope": "openid profile email offline_access {client-id}/.default"
    }
},
"openid_configuration": "https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration"
}

Validate Authentication is active

You’ve validated you are getting the correct configuration response from the Discovery Service. Now you can validate that authentication is active by accessing the services via the DNS name you configured.

# curl the services endpoint
curl -vvv https://{DNS_URL}/api/v1/services

You should see a response similar to the response below. (Output truncated for brevity)

*   Trying {YOUR_IP}:443...
...
...
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 2147483647)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 401
< vary: Accept-Encoding
< date: Fri, 20 Feb 2026 06:09:31 GMT
< server: envoy
<

Returning a 401 Unauthorized response indicates that authentication is active and working.

Validate Interactive Login

You can also validate that interactive login is working by accessing the services via Storage Navigator. Open an incognito browser window and navigate to https://navigator.{DNS_URL}, then click Add Connection, enter the Discovery Service hostname, then click Connect.

This should redirect you to your identity provider’s login page. Login with your credentials and you should be redirected back to the Storage Navigator.

Potential Issues

If you are not redirected to the Storage Navigator after logging in, you may need to check your identity provider’s configuration. Work with your IdP admin to ensure the correct redirect URI is configured.

What’s Next?

Now that you have your services deployed using authentication, you can now begin to have your users interact with your storage.

We will soon cover the optional deployment of the Permissions Service and Permissions Service UI to allow your users to manage their permissions to your storage and services.