Skip to main content
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.
<supervisor> and <cluster> are placeholders throughout. All endpoints below take ?supervisor= and ?namespace= query parameters, like the rest of the /api/clusters/<cluster>/... surface.

​
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, 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.

​
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

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

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

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

Permissions reference

Every cluster:* action and the sensitive-read policy that gates credentials.

Authentication & IAM

How identities and groups map onto these policies.

Day-2 operations

What you can read without ever downloading a credential.

Hosted control planes

The vcluster kubeconfig export path and its 404 semantics.