Access Control
Roles control operations; resource scope and policy ownership control what they affect. Every applicable check must pass. Administrators bypass resource scope and ownership checks. Sensors are trusted agents, not scoped users.
How Access Control Works
Grant a role, then pipeline/deployment scope and any policy ownership. New users start as Viewers with no resource scope; an Administrator must grant access.
Roles
| Operation | Viewer | Operator | Administrator |
|---|---|---|---|
| Read authorized pipelines, builds, deployments, workloads, violations, policies, and their variables | Yes | Yes | Yes |
| Manage own personal access tokens | Yes | Yes | Yes |
| Delete in-scope pipelines, builds, deployments, workloads, and violations | No | Yes | Yes |
| Create policies; edit/delete owned policies and their variables | No | Yes | Yes |
| Manage policy co-owners, assignments, and permit proposals | No | Yes | Yes |
| Manage integrations and inspect discovery run history | No | Yes | Yes |
| View, edit, and delete Sensors | No | Yes | Yes |
| Create Sensors and rotate their tokens | No | No | Yes |
| Manage users and resource scope | No | No | Yes |
| View dashboards, statistics, and application/audit logs | No | No | Yes |
| Manage system variables, log retention, and pipeline settings | No | No | Yes |
Access Scope
Administrators grant individual pipelines/deployments or all, covering current and future resources of that type. Unscoped resources are hidden from lists and forbidden on direct access.
How Scope Propagates
| Grant | Includes |
|---|---|
| Pipeline | Its builds and their violations |
| Deployment | Its workloads and their violations |
Either applicable parent grant permits access to a violation.
Assigning Scope
Use the user edit screen to select resources or all. For scripted/bulk changes:
endura task user_update id:5 pipelines:1,2 deployments:3 policies:7 all_pipelines:falseSee user task replacement semantics before changing existing scope.
Policy Ownership
The creator becomes the first owner. Owners and Administrators can manage co-owners by email, edit/revert/delete policies, assign pipelines, and permit violations. Operators need ownership for these policy changes.
Readers must own the policy or have access to a pipeline it governs. Otherwise it is hidden and direct access is forbidden. Administrators can read and manage every policy.
Variables follow policy permissions: authorized readers see used system/policy variables; owners manage policy variables. Administrators manage shared system variables. See Policy Variables.
Personal Access Tokens
Create PATs under Settings > Access Tokens and send their one-time secret as a bearer token:
curl -H "Authorization: Bearer $ENDURA_PAT" https://team-server.example.com/api/pipelinesPATs inherit owner role, scope, and policy ownership, with an additional HTTP-method restriction:
| Capability | Methods |
|---|---|
read | GET, HEAD |
write | All other methods |
read_write | All methods |
A validation/test/sync POST still requires write capability. Token creation, rotation, and deletion require interactive sign-in; PATs can only read their owner’s token metadata. Privileged local tasks provide administrator automation.
The UI offers 30, 60, 90, 180, or 365 days, default 90; API requests accept any whole 1–365 days. New/rotated secrets appear once. Rotation immediately invalidates the old value.
Authentication
Sign in through Google, Microsoft Entra ID, Oracle, CyberArk, or the non-production username/password provider. See provider configuration.