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. Use the NGC_API_KEY Bash variable set in Requirements.

# pull the chart from NGC
helm fetch https://helm.ngc.nvidia.com/nvidia/omniverse/charts/envoy-auth-extension-2.4.0.tgz --username='$oauthtoken' --password="${NGC_API_KEY:?Set NGC_API_KEY in this Bash session}"

# unpack the chart and cd into the directory
tar -xvf envoy-auth-extension-2.4.0.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#

Before you begin: Open the extracted envoy-auth-extension chart folder. Ensure envoy-values.yaml and oidc-config.yaml are present and the storage-apis namespace exists.

Install: Run the following command:

helm upgrade --install envoy-auth-extension . \
  --namespace storage-apis \
  -f envoy-values.yaml \
  -f oidc-config.yaml \
  --wait --timeout 5m

Verify: Check the release status and the pods:

helm status envoy-auth-extension --namespace storage-apis
kubectl get pods --namespace storage-apis

Confirm the release is deployed and its pods are ready before continuing. If installation times out, inspect the release and pod status before retrying.

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:
  storage_permissions:
    enabled: true
    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 permissions.storage_permissions block controls storage-permission enforcement: when checking whether a user has access to files referenced in storage events (e.g., omni.storage.created, omni.storage.deleted), the Event Consumer Service queries the Storage API at each of the configured endpoints. This is relevant when authentication is enabled and clients consume storage events on non-durable queues.

The permissions.storage_permissions.enabled flag is an independent gate: it controls only the storage-service permission path and does not require permissions.enabled: true. Set permissions.storage_permissions.enabled: true to turn on storage-permission enforcement regardless of whether the broader fine-grained permissions enforcement (permissions.enabled) is on.

For the complete authorization and permissions setup — including the consumer’s principalSource auth modes and permissions.enabled enforcement — see the Authentication and Permissions section of Notification Services Configuration.

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.

Before you begin: Set the following Bash variables to existing absolute paths:

  • DEPLOYMENT_DIR: the directory containing your extracted service chart folders.

  • OIDC_VALUES: the oidc-config.yaml created earlier in this guide.

  • INGRESS_VALUES: the shared ingress-values.yaml updated earlier.

# Replace these example paths with the paths used by your deployment.
DEPLOYMENT_DIR="/absolute/path/to/deployment"
OIDC_VALUES="/absolute/path/to/oidc-config.yaml"
INGRESS_VALUES="/absolute/path/to/ingress-values.yaml"

The commands below use the chart-folder and values-file names shown in the service guides. Adjust those paths if your existing deployment uses different locations. Reuse your existing values files so the upgrade preserves your configuration.

Run only the commands for services already installed in your stack. These commands use helm upgrade to update existing releases. Stop and investigate any failed upgrade before continuing.

# redeploy the discovery service
helm upgrade discovery-service "${DEPLOYMENT_DIR:?Set DEPLOYMENT_DIR}/discovery-service" \
  -f "$DEPLOYMENT_DIR/discovery-service/discovery-values.yaml" \
  -f "${INGRESS_VALUES:?Set INGRESS_VALUES}" \
  -f "${OIDC_VALUES:?Set OIDC_VALUES}" --namespace storage-apis

# redeploy the storage service
helm upgrade storage-service "${DEPLOYMENT_DIR:?Set DEPLOYMENT_DIR}/storage-service" \
  -f "$DEPLOYMENT_DIR/storage-service/storage-values.yaml" \
  -f "${INGRESS_VALUES:?Set INGRESS_VALUES}" --namespace storage-apis

# if using notifications, redeploy the notification aggregation service
helm upgrade event-aggregation-service "${DEPLOYMENT_DIR:?Set DEPLOYMENT_DIR}/event-aggregation-service" \
  -f "$DEPLOYMENT_DIR/event-aggregation-service/event-aggregation-values.yaml" \
  -f "${INGRESS_VALUES:?Set INGRESS_VALUES}" \
  -f "${OIDC_VALUES:?Set OIDC_VALUES}" --namespace storage-apis

# if using notifications, redeploy the notification consumer service
helm upgrade event-consumer-service "${DEPLOYMENT_DIR:?Set DEPLOYMENT_DIR}/event-consumer-service" \
  -f "$DEPLOYMENT_DIR/event-consumer-service/event-consumer-values.yaml" \
  -f "${INGRESS_VALUES:?Set INGRESS_VALUES}" \
  -f "${OIDC_VALUES:?Set OIDC_VALUES}" --namespace storage-apis

# redeploy the storage navigator
helm upgrade storage-navigator "${DEPLOYMENT_DIR:?Set DEPLOYMENT_DIR}/storage-navigator" \
  -f "$DEPLOYMENT_DIR/storage-navigator/navigator-values.yaml" \
  -f "${INGRESS_VALUES:?Set INGRESS_VALUES}" --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
<

Expected result: A request without credentials returns 401 Unauthorized, confirming that this endpoint rejects unauthenticated requests.

Next, complete Validate Interactive Login to confirm that users can sign in successfully.

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?#

To configure authorization, continue with Permissions Service Configuration.

For the sample permission-management application, see Permissions UI in the Overview.