UsageCloud Private 0.0.6-main.1
Role Ladder
Every route the Designer console serves, and the lowest role that may call it. Generated
from the platform's own authorization policy rather than compiled by hand, so it states what the
running system enforces — including the placements that are not what you would guess.
Run history, quarantine, events and the fleet are served by the separate operations
console, which has its own policy and is not in this table. On the Designer console, those routes
are refused for every role.
the roles are rungs, not categories
pe-viewer reads workflows and schedules
pe-operator + start and stop workflows, create projects
pe-designer + authoring: definitions, mappers, code, secrets
pe-admin + deletes, imports, schedule administration
Each rung contains the one below it.
pe-viewer ⊂ pe-operator ⊂ pe-designer ⊂ pe-admin. So granting design rights
also grants operational ones — a designer can start and stop workflows. Worth confirming against
this table when you plan who gets which role.
Three reasons a route is refused — only one is about capability
The policy test asserts a great many denials. They are not one thing, and only the last
is something an administrator can act on:
Wrong verb (49) — the path exists and works under another method.
GET /api/v1/system-export is allowed; POST and DELETE
are not. PUT /api/v1/projects/{project_name} is refused because PATCH
already covers every mutable field. Nothing to do with roles.Structural (12, not listed in the tables) — the policy is proved to
deny anything it does not recognise, and to refuse a path that merely LOOKS like a sensitive
one: a prefix cannot inherit another route's policy. Worth knowing for a different reason:
/healthz is refused here too, and that is not a permission decision — it
sits outside the gated API prefixes entirely and is gated somewhere else.Closed (9, shown as closed ) — real
capabilities deliberately shut off from every role.
What is closed, and why it is interesting
POST /api/v1/cluster/restart, DELETE /api/v1/cluster/{node_name} —
node lifecycle is not reachable through the platform's API by anyone, at any role. That boundary is
deliberate: cluster lifecycle belongs to Kubernetes.PUT /api/v1/events/retention — retention is a TTL, not a writable field.The legacy ZIP import surface under /api/import/* — note
this is not /api/v1/import/*; the old path is shut.
GET on /api/v1/scripts and /api/v1/schemas —
these are POST-only compiler and inference endpoints; there is nothing to list.
Features that have been withdrawn are shut for
every method rather than left reachable,
and are not listed row by row above:
/api/v1/kpi/alarms,
/api/v1/kpi/alarms/{id}/feedback,
/api/v1/compliance/data-minimization,
/api/v1/compliance/ai-act/scan.
What is not here
The platform holds no user records — it is an OIDC relying party, so users and role assignment live in
your identity provider. There are no groups, no multi-membership, and no per-object permissions:
nothing corresponds to MediationZone's Access Controller, where each workflow or profile carried its
own view/update/use rights. Authorization is deny-by-default; a route absent from this table returns 403.
This table is tied to one release
Authorization is version-specific, so what you see here is true for UsageCloud Private 0.0.6-main.1 and
for no other release. A later release can add routes and can move one between rungs. If you are
running a different version, ask for the reference that matches it rather than reasoning from this
one — and if a placement here does not match what your system does, trust your system.