Keys and recovery
You hold the keys to your cluster. Keep an offline copy and test your backups: a backup cannot be restored without the keys that open it.
Read the docsChoose who gets in and what they may do.
Give people and apps the access their work needs. Keep credentials under your control and keep the recovery keys needed to restore your cluster.
Built-in roles within a tenant: an isolated environment for a team or customer. Each role adds to the one above.
| Role | What it allows |
|---|---|
| Reader | See the tenant and its job summaries. |
| Operator | Also start jobs and decide approvals. |
| Admin | Also change the tenant configuration. |
| Owner | Also decide who is a member. |
Reading the actual input and output of a job needs a separate content permission. A role alone does not grant it.
Access to start work, access to change rules and access to read job content are separate decisions.
What you can do
Secrets
Store credentials per tenant, an isolated team or customer environment. Model-provider keys stay on the server; plugin credentials can use supported injection mechanisms instead of appearing in instructions.
Read the docsSign-in and roles
Use your identity provider or password accounts with an authenticator. Give each person a role; give apps API keys with the scope they need.
Read the docs