Validate and Sign In

After you apply the custom resources (see Install on Kubernetes), validate the installation, sign in as the Platform Admin, and optionally federate login to your corporate identity provider.

Validate the Installation

Run all of these checks. Pods in the Running state, or a single HTTP 200, doesn't show that the installation works.

1. Check the custom resources. Each one must report Ready=True, and its status.observedGeneration must equal metadata.generation. A Ready left over from an earlier configuration doesn't count. For each resource, the first command prints the two numbers, and the second lists any condition that isn't True:

   kubectl -n minerva-infra get minervainfra minerva-infra \
     -o jsonpath='{.metadata.generation} {.status.observedGeneration}{"\n"}'
   kubectl -n minerva-infra get minervainfra minerva-infra \
     -o jsonpath='{range .status.conditions[?(@.status!="True")]}{.type}={.status} {.reason}{"\n"}{end}'
   
   kubectl get minervaidentity cluster-identity \
     -o jsonpath='{.metadata.generation} {.status.observedGeneration}{"\n"}'
   kubectl get minervaidentity cluster-identity \
     -o jsonpath='{range .status.conditions[?(@.status!="True")]}{.type}={.status} {.reason}{"\n"}{end}'
   
   kubectl -n minerva-app get minervaapp minerva-app \
     -o jsonpath='{.metadata.generation} {.status.observedGeneration}{"\n"}'
   kubectl -n minerva-app get minervaapp minerva-app \
     -o jsonpath='{range .status.conditions[?(@.status!="True")]}{.type}={.status} {.reason}{"\n"}{end}'
   

   The two numbers must match, and the infrastructure and identity lists must be empty. On the application, the conditions in Expected application conditions aren't faults. In general, a condition with the reason Disabled reports a component that the configuration turns off. Any other False condition is a fault: investigate it from its reason and message with kubectl describe.

   kubectl get minervaidentity shows an in-cluster service address in the ISSUER column. That's expected. It isn't the address browsers use: browsers sign in on the UI hostname.

2. Check the workloads and storage. In each of the four namespaces (minerva-system, minerva-infra, minerva-app, and minerva-identity), run kubectl get pods,pvc. Service pods must show all containers ready (completed jobs may show Completed), and every PVC must be Bound. Run it twice, at least two minutes apart: the restart counts of unchanged pods must not change. A few early Druid restarts that then hold steady are expected.

3. Check that the front door serves. This isolates the platform from your network path. In a second terminal, start a port-forward:

   kubectl -n minerva-app port-forward svc/minerva-app-nginx 18443:443
   

   Once it reports Forwarding from, run the check, and then stop the port-forward with Ctrl-C:

   curl -sk -o /dev/null -w 'nginx -> HTTP %{http_code}\n' https://127.0.0.1:18443/
   

   HTTP 200 confirms that the front door responds. Because of -k, this check doesn't validate certificate trust, the public hostname, or the external network path. You check those from a real browser when you sign in.

4. Check the license. A missing or unusable license doesn't stop the resources from becoming Ready, so always confirm the license state. In a second terminal, start a port-forward to the license service:

   kubectl -n minerva-app port-forward deploy/license 18080:8080
   

   Then query the state:

   curl -s http://127.0.0.1:18080/minerva/api/v1/license/state
   

   Expect state: active with your license's identity and expiry date. "state":"invalid" means the license service found no usable license. Re-check the ConfigMap name minerva-license and the key license.lic, run kubectl -n minerva-app rollout restart deploy/license, and check again. For license states, see Manage Licenses.

5. Check that the collector address answers. From a host on the network your telemetry sources send from, post an empty OTLP request to the external address of the Service minerva-app-otel-data-lb in minerva-app:

   curl -s -o /dev/null -m 10 -w '%{http_code}\n' \
     -H 'Content-Type: application/json' -d '{}' \
     http://<collector-address>:4318/v1/metrics
   

   Expect 200.

   • 000 means that nothing answered. Check the network path and the source ranges (see Reaching the UI and the Collectors).

   • An HTTP error such as 502 or 503 means that the address answers but the collectors behind it aren't serving. Repeat the collector check at the end of Apply the Custom Resources.

Data appears in the product once your telemetry sources send to this address, on the ports listed in Configure the Custom Resources. Setting up those sources is part of onboarding them, not of the installation.

Sign In and Set the Administrator Password

At its first start, the NVIDIA Minerva UI creates a default Platform Admin account, as in a Docker Swarm installation. The username is admin and the initial password is ChangeMe123!. The account belongs to the default tenant and has the global Platform Admin role.

1. Make sure your UI hostname points at the UI address (see Apply the Custom Resources).

2. Open the UI through that path in a browser and sign in as admin with the initial password.

3. Set a new password when the UI asks for one. The UI requires it at the first sign-in with the initial password.

4. Confirm that sign-in works from a real client. In a fresh browser session, open your UI hostname, log in, load a page, and log out. Reaching the login page alone isn't a pass. Your workstation and browser must trust the CA that signed the UI certificate: creating ca-certs in the cluster does not establish that trust.

5. Continue with the initial configuration, as for any NVIDIA Minerva installation: create tenants, users, and role assignments (see Configure Tenants and Manage Users and Roles).

Don't delete the admin account to disable it: the UI creates it again, with the initial password, at its next start. Keep it, with the password you set, as your recovery path.

The Keycloak administration credential. The generated Secret minerva-keycloak-admin in minerva-identity, with the keys username and password, is the credential for the Keycloak administration console. It isn't an NVIDIA Minerva UI login. The application also uses this credential, so never delete or rotate it yourself.

The Keycloak administration console isn't published outside the cluster. To open it, run this port-forward in a second terminal, and then browse to http://localhost:18081/identity/admin/:

kubectl -n minerva-identity port-forward svc/minerva-keycloak-service 18081:8080

If sign-in to the UI fails after the password prompt, open the Keycloak administration console with that credential, switch to the minerva realm, and under Clients open ui-react. Confirm that https://<ui-hostname>/* is an accepted redirect URI and https://<ui-hostname> an accepted web origin, and add them if they're missing. The UI provisions this client when it starts, and it's usually already permissive. The check is worth repeating after an upgrade. To read the credential's password:

kubectl -n minerva-identity get secret minerva-keycloak-admin -o jsonpath='{.data.password}' | base64 -d

(Optional) Federate Login to Your Corporate Identity Provider

You can keep the platform's Keycloak and add a broker to your OIDC provider, so that users log in with their corporate accounts:

browser -> NVIDIA Minerva UI -> platform Keycloak -> your identity provider -> back

1. In your identity provider, create a confidential OIDC client with the standard authorization-code flow and the scopes openid profile email. Its only redirect URI must be exactly https://<ui-hostname>/identity/realms/minerva/broker/default/endpoint. Note the client ID and the client secret. The broker alias must be exactly default: the UI always provisions the broker under that name, and any other value breaks the callback. If your provider's configuration is managed from a Git source, add the client there too, or the next reconcile removes it.

2. Store the client secret:

   kubectl -n minerva-identity create secret generic customer-oidc-client-secret \
     --from-literal=clientSecret='<the-secret>'
   

3. In customer-minervaidentity.yaml, uncomment the identityBrokers block under spec.provider.keycloak (the file ships it commented out), and replace its two placeholders with your provider's issuer URL and the client ID you created:

   identityBrokers:
     - alias: default            # must be exactly "default"
       enabled: true
       providerType: oidc
       issuerURL: "${MINERVA_OIDC_ISSUER_URL}"
       clientID: "${MINERVA_OIDC_CLIENT_ID}"
       clientSecretRef:
         name: customer-oidc-client-secret
         key: clientSecret
       defaultScopes: ["openid", "profile", "email"]
       syncMode: import
       firstBrokerLoginFlow: "first broker login"
   

   Apply the file again and keep it: it's your configuration of record. If your provider presents a privately signed certificate, its CA must already be in the trust bundle (see Create the Certificates, Trust Bundle, and License).

4. Wait for minervaidentity/cluster-identity to reconcile to Ready and for the UI deployment in minerva-app to roll out. Restart it if it hasn't:

   kubectl -n minerva-app rollout restart deploy/ui
   

5. Confirm that, in a fresh browser session, logging in to your UI hostname goes through your identity provider and returns authenticated.

By default, a federated user gets read-only access (the Viewer role) in the default tenant at the first login. Assign other roles in the NVIDIA Minerva UI (see Manage Users and Roles). Keep the local admin account, tested, as your recovery path. When you rotate the client secret, update the Secret, and then restart the UI deployment.

Last updated: October 30, 2026