Access Control
Team Server authorizes users through roles, access scope, and policy ownership. Roles control the operation; scope and ownership control the resources it may affect. Every applicable layer must allow the request.
How Access Control Works
Every user action is evaluated against two questions:
| Question | Governed by | Applies to |
|---|---|---|
| What operation is this? (read vs. create, edit, delete) | Role | All users |
| Which resource does it touch? | Access scope (pipelines & deployments) and Policy ownership (policies) | Viewers and Operators |
Administrators bypass the resource layers entirely and can act on every pipeline, deployment, and policy in the system. Runtime Sensors are trusted agents and are never scoped.
Roles
Roles control which operations a user can perform:
| Operation | Viewer | Operator | Administrator |
|---|---|---|---|
| View pipelines, builds, deployments, workloads, violations | Yes | Yes | Yes |
| View policies | Yes | Yes | Yes |
| Manage own personal access tokens | Yes | Yes | Yes |
| Create and delete resources | No | Yes | Yes |
| Create and edit owned policies | No | Yes | Yes |
| Manage policy co-owners | No | Yes | Yes |
| Assign policies to pipelines | No | Yes | Yes |
| Permit violations | No | Yes | Yes |
| Manage integrations | No | Yes | Yes |
| Manage users and assign access scope | No | No | Yes |
| Create and rotate Sensors | No | No | Yes |
| View statistics, audit logs, and pipeline settings | No | No | Yes |
New users start with no access
At first sign-in, a user is a Viewer with no access scope. An Administrator must grant scope before the user can see pipelines, deployments, or their child resources.
Access Scope
Access scope determines which pipelines and deployments a Viewer or Operator can reach. Administrators grant individual resources or the all wildcard. The wildcard covers current and future resources of that type.
A Viewer or Operator sees and acts on only the resources in their scope. Everything outside their scope is hidden from lists and returns a forbidden error on direct access.
How Scope Propagates
Access is granted at the pipeline and deployment level and flows down to their related resources:
| Granting access to a… | Also grants access to… |
|---|---|
| Pipeline | Its builds |
| Deployment | Its workloads |
| Pipeline or deployment | The violations reached through that pipeline’s builds or that deployment’s workloads |
A violation is therefore reachable if the user has access to the pipeline behind its build, or to the deployment behind its workload.
Assigning Scope
Administrators manage a user’s role and access scope from the user edit screen in the web UI. Select the individual pipelines and deployments to grant, or choose the “all” option to grant the wildcard.
A command-line task, user_assign, is also available for scripted or bulk assignment. For example:
endura task user_assign id:5 pipelines:1,2 deployments:3 policies:7 all_pipelines:falsePolicy Ownership
Policy ownership is separate from administrator-assigned access scope. The policy creator becomes its first owner.
- Owners and administrators can add or remove co-owners by email address.
- Editing a policy (updating, reverting, deleting, assigning it to pipelines, or permitting violations against it) requires ownership or the Administrator role.
- Reading a policy requires either owning it or having access to a pipeline that the policy governs. Policies that satisfy neither condition are hidden from a non-owner’s policy list and return a forbidden error on direct access.
Administrators can read, edit, and reassign any policy regardless of ownership.
Personal Access Tokens
Any user can create a personal access token (PAT) for API access:
Authorization: Bearer endura_pat_...A token uses its owner’s role and scope and also carries a request capability:
| Capability | Permitted requests |
|---|---|
read | Read-only requests (GET) |
write | Mutating requests (create, update, delete) |
read_write | Both reads and mutations |
A read token owned by an Operator still permits only reads. Owners can rotate or revoke their tokens.
Authentication
Users sign in through Google, Microsoft Entra ID, Oracle, CyberArk, or the non-production username/password provider. See Authentication for provider and domain configuration.