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

# Access & credentials

> Retrieving a tenant cluster's kubeconfig, talosconfig, and SSH password — decrypted server-side, gated by dedicated permissions, and always audited.

Celum can hand out working credentials for any tenant cluster: the Cluster API providers write them as Secrets on the supervisor, and Celum decodes them **server-side only** — base64 payloads never reach the browser undecoded, and nothing is cached client-side. Because these endpoints return real access rather than status, each has its own permission, separate from ordinary cluster reads.

<Note>
  `<supervisor>` and `<cluster>` are placeholders throughout. All endpoints below take `?supervisor=` and `?namespace=` query parameters, like the rest of the `/api/clusters/<cluster>/...` surface.
</Note>

## Kubeconfig

```
GET /api/clusters/<cluster>/kubeconfig
```

Returns the tenant's admin kubeconfig as a YAML download (`<cluster>-kubeconfig.yaml`). The payload comes from the kubeconfig Secret the provider wrote on the supervisor — Celum tries the conventional keys (`value`, then `kubeconfig`) so it works across providers. This is the same kubeconfig Celum itself uses for every [day-2 read](/clusters/day-2-operations), so if those views work, the download will too.

For wizard-installed vcluster instances there is a separate per-instance path — `GET /api/supervisors/<supervisor>/vcluster/<instance>/kubeconfig` — described in [Hosted control planes](/clusters/hosted-control-planes#per-instance-kubeconfig).

## Talosconfig

```
GET /api/clusters/<cluster>/talosconfig
```

For Talos-based clusters, the `talosctl` client configuration, again as a YAML download. Non-Talos clusters return `404` — that is a "this cluster has no talosconfig", not an error to chase.

## SSH password

```
GET /api/clusters/<cluster>/ssh-password
```

Returns `{ "password": "..." }` — the node SSH password decrypted from the provider's Secret on the supervisor. Celum tries the secret keys `ssh-passwordkey`, `password`, and `value` in order, covering the naming conventions of the supported providers.

## Omni cluster config

```
GET /api/supervisors/<supervisor>/omni/cluster-config
```

Not a tenant credential but a supervisor-level view: for Talos supervisors managed by Omni, this returns the Talos-side configuration — pod and service subnets, DNS domain, KubePrism state, and per-node network interfaces. It answers "what does the OS layer think this cluster looks like" when the Kubernetes-side view disagrees. A `503` with a hint means the Omni integration is not configured on this Celum instance; the platform falls back to Kubernetes-side detection wherever it can.

## Permissions and audit

| Credential                   | Action                   |
| ---------------------------- | ------------------------ |
| Kubeconfig                   | `cluster:GetKubeconfig`  |
| Talosconfig                  | `cluster:GetTalosconfig` |
| SSH password                 | `cluster:GetSshPassword` |
| vcluster instance kubeconfig | `vcluster:GetStatus`     |
| Omni cluster config          | `supervisor:GetSummary`  |

The three `cluster:Get*` credential actions are deliberately **excluded from the standard operator and viewer roles** — they hand out working access, so they are granted through the sensitive-read policy to named people. See the warning in the [permissions reference](/reference/permissions#cluster).

Every retrieval passes through the audit middleware like any other API call: who fetched which cluster's credentials, when, and with what result is queryable at **Audit logs** (`/audit-logs`), filterable by resource and actor. Treat a credential download as an event worth being accountable for — the platform already does.

<Note>
  **Celum AI** deliberately has **no tools that return credentials** — the assistant can tell you a cluster's state via `get_guest_cluster` and check who downloaded a kubeconfig via `query_audit_logs`, but the secrets themselves are only served to a permitted human through these endpoints.
</Note>

## Related

<CardGroup cols={2}>
  <Card title="Permissions reference" icon="list-check" href="/reference/permissions">
    Every `cluster:*` action and the sensitive-read policy that gates credentials.
  </Card>

  <Card title="Authentication & IAM" icon="shield-halved" href="/get-started/authentication">
    How identities and groups map onto these policies.
  </Card>

  <Card title="Day-2 operations" icon="gauge-high" href="/clusters/day-2-operations">
    What you can read without ever downloading a credential.
  </Card>

  <Card title="Hosted control planes" icon="boxes-stacked" href="/clusters/hosted-control-planes">
    The vcluster kubeconfig export path and its 404 semantics.
  </Card>
</CardGroup>