> ## 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 built to be 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`](/operator/reference/cli), `kubectl`, or Helm.

<Note>
  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.
</Note>

***

## 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-operator 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 — 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](/operator/ui/installation)
* [Configuration](/operator/ui/configuration)
* [Thresholds & Notifications](/operator/ui/thresholds-and-notifications)