Permissions
The full casbin permission catalog. Every permission gates one or more API endpoints + UI affordances. Roles (built-in or custom) are collections of these permissions.
How to read the table
Each row is a (object, action) pair. The object names a resource
class; the action names a verb against it. UI elements are
described as buttons / drawer entries that won't render unless
the user's role grants the permission for the active organization.
The matcher is (user, org_id, object, action) — every check
runs in an org context. Super-admins bypass.
Org-scoped permissions
| object | action | What it gates |
|---|---|---|
edge-instances | create | "Add Edge" button on Edge Instances page; backend rejects POST otherwise |
edge-instances | read | Edge Instances list + detail; nodes tab; health tab; VM console (vm:console is folded into this read perm) |
edge-instances | update | Edit drawer save button |
edge-instances | delete | Remove action in row menu |
edge-instances | read-health | Health tab content (separate from list read so you can grant "see edges" without "see why they're broken") |
helm | install | Install button on marketplace + reinstall |
helm | upgrade | Upgrade drawer save |
helm | uninstall | Uninstall action |
helm | list-releases | Applications page list + force-sync |
helm | status | Detail page status tab |
helm | resources | Resources tab + view/edit YAML |
registries | create / read / update / delete | Registry CRUD |
registries | upload | Push artifacts (chart / image tar) into the registry |
marketplace | create / read / update / delete | Marketplace CRUD |
marketplace | install | Install button (separate from helm:install so a role can browse marketplace + use direct helm but not "marketplace install" if you ever need that distinction; in practice both are usually granted together) |
members | create / read / update / delete | Org Members tab — invite, list, change role, remove |
roles | create / read / update / delete | Org Roles tab — define + manage custom roles |
org | update | Org settings (rename, etc.) |
org | delete | Soft-delete the org |
audit-logs | read | Audit Logs page |
observability | read | Metrics + logs tabs in release detail; PromQL test query |
webhooks | create / read / update / delete | Org Webhooks page |
provisioner | read | View provisioner-managed cluster lifecycle |
provisioner | provision | Provision-new-cluster path in Add Edge |
provisioner | manage | SSH keys + presets management |
alarms | create / read / update / delete | Alarms CRUD |
velero | create / read / update / delete | Backups + Restores |
backup-locations | create / read / update / delete | External S3 backup targets. Any of create / update / delete makes the Backup Locations tab appear on the Organizations page; update also gates the per-row Test action. Global locations (defined by the platform admin) are testable but never editable from an org. |
vm | action / console | VM start/stop/restart + VNC |
Public-resource permissions (admin/super-admin only)
These only surface in the casbin catalog when the active license carries the corresponding cap > 0:
| object | gating cap |
|---|---|
public-edges:* | MaxPublicEdges > 0 |
public-registries:* | MaxPublicRegistries > 0 |
public-marketplace:* | MaxPublicMarketplacePackages > 0 |
If the cap is 0, the perms are filtered out of
AvailablePermissions and the corresponding admin pages don't
render — you can't grant a perm for a feature the license doesn't
expose.
Built-in roles vs permissions
Default mappings (your install may have customised these via Admin → Settings → Roles defaults):
| Role | Permissions |
|---|---|
| viewer | All read permissions |
| developer | viewer + helm:*, registries:*, marketplace:* (excluding delete on marketplace by default), webhooks:* |
| operator | developer + alarms:*, velero:*, vm:* |
| admin | operator + members:*, roles:*, org:* |
Adding a permission to a custom role
Org → Roles → Add role → permission grid is grouped by object. Tick the actions you want; save.
A user assigned that role gets the permissions immediately on their next request — no logout needed.
Testing what a permission grants
If you're unsure what a permission gates, the audit log usually helps. Take an action with a privileged role; observe which endpoints + UI buttons appeared. Then strip the permission from a custom role and try the same action — the difference is what the permission gates.
See also
- How-to: manage members and roles
- Tutorial 4 — Onboard your team
- Backend docs: Concept → RBAC (Casbin)