> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensormesh.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Access & Security

> Who can reach the dashboard, how to put SSO in front of it, and why it's safe to run in production.

The UI is safe to run in a production cluster: it is strictly read-only, holds no credentials of
its own, and by default is reachable only from inside the cluster.

***

## Read-Only by Design

The dashboard can look, but never touch:

| It can                                                    | It cannot                                    |
| --------------------------------------------------------- | -------------------------------------------- |
| See your engines and their status                         | Create, change, or delete anything           |
| See pods, nodes, and events                               | Change quotas, restart pods, or clear caches |
| Read engine status and metrics through the Kubernetes API | Reach pods directly over the network         |

Because it can't act, the UI names the problem and the fix (Health → Issues & Fixes); you make the
change with [`tmo-cli`](/v1.0.0/reference/cli), `kubectl`, or Helm.

The UI gets its cluster access from Kubernetes at runtime: no credentials are baked into the image
or the chart, and none ever reach the browser.

***

## How It's Reached

<Steps>
  <Step title="Default — Port-Forward">
    By default the UI is private to the cluster. If you have cluster access, a port-forward
    is all you need:

    ```bash theme={null}
    kubectl -n tensormesh-platform port-forward svc/tmo-ui-tensormesh-operator-ui 8080:80
    ```
  </Step>

  <Step title="Team Access — Ingress Behind SSO">
    For shared access, enable the ingress (`ingress.enabled=true`, with your own hosts and TLS)
    and put single sign-on in front of it (see below).
  </Step>
</Steps>

***

## Single Sign-On

The UI has **no built-in login**. When you expose it to a team, sign-in happens at the
ingress, the standard pattern for in-cluster dashboards. The ingress checks each request
against your identity provider (Okta, Google, Entra, Keycloak, or any OIDC provider) and passes
the signed-in identity to the UI, which shows **Signed in as** the authenticated user.

* Works with any identity provider and any ingress controller.
* Offboarding someone in your identity provider revokes their UI access immediately. There's
  no separate user list to maintain.

***

## Related

* [Installation](/v1.0.0/ui/installation)
* [Configuration](/v1.0.0/ui/configuration)
* [Thresholds & Notifications](/v1.0.0/ui/thresholds-and-notifications)