Define access rules with policies

Policies define the access rules that roles reference. Each policy contains one or more statements that specify what actions to allow, on what scope, and under what conditions.

Automation orchestrator ships built-in policies only. You cannot create, update, or delete policies. Create custom roles that reference built-in policies when you need a different permission bundle.

View policies

Navigate to Access Management > Policies tab. The table displays built-in policies with columns: Name, Description, Scope, and Statements. The Statements column summarizes each statement's effect, actions, and scope. Filter policies by name or description.

Policy statement structure

Each statement defines:

Table 1. Policy statement fields
Field Values Description
effect allow Grants access when the statement matches. All policies use theallow effect.
actions ["workflow:read", "workflow:create"] List ofresource_type:action strings. Wildcardresource_type:* matches all actions on a resource type.
scope any,self, orproject any = all resources;self = resources owned by or associated with the current user (matchesuser anduser_identity resources whereresource.id == user.id, andgroup resources where the user is a member);project = resources within the assigned project
conditions {} Optional attribute-based conditions (see below)

Supported condition types:

  • resource_labels: key-value match on resource labels
  • resource_labels_not: negative key-value match on resource labels
  • user_labels: key-value match on user labels
  • user_labels_not: negative key-value match on user labels (deny access when user lacks a specific label)
  • resource_metadata: key-value match on resource metadata
  • user_metadata: key-value match on user metadata
  • group_labels: key-value match on group labels

Built-in policy names use the form resource:action:scope. Examples include workflow:read:project and execution:run:project.

How policy evaluation works

The authorization system evaluates your request against all applicable policies:

  • If at least one allow policy matches the request, the system grants access.
  • If no allow policy matches, the system denies the request (deny-by-default).

All policies use the allow effect. There are no deny-effect policies. You control access by choosing which allow policies to assign through roles. Access that no policy explicitly grants is denied by default.

Note:

Manage access restrictions by choosing which built-in allow policies to include in a role. Access that no policy explicitly grants is denied by default.