Key concepts
Principal
The principal is the identity attempting an action, typically the canonical identifier for the authenticated OuterProduct user making the request:Action
An action is the operation the principal wants to perform. Examples includeAction::"volume_read" , Action::"volume_write" , Action::"secret_use" , etc.
Actions are specific to a resource type. For example, volume_write applies to volumes, while execute_run applies to runs.
Resource
The resource is the object on which the action is attempted, such as a volume, secret, run, user, or workspace. Resources use typed identifiers. Volumes and Secrets use their immutable UUIDs:Policy
A policy is a rule that either permits or forbids access. The rule contains:- An effect:
permit(to grant access) orforbid(to deny access) - A principal constraint
- An action constraint
- A resource constraint
- Optionally, a
whenorunlesscondition
forbid overrides every matching permit.
Conditions
A policy can use awhen condition to apply only when an additional expression is true:
unless condition has the inverse meaning: the policy applies unless the expression is true.
Creating a policy
A policy belongs to the workspace it was created in and applies only to that workspace and the resources it owns. Policies created in the dashboard cannot grant Account or User actions; those belong to the deployment’s operator policy.Using the visual builder
The visual builder is the simplest way to create a policy. It generates Cedar language based on the selections you make. Open Policies in the dashboard and click New policy, then:- Choose the principals to which the policy applies. A policy can apply to one specific user, a selected set of users, or all users.
- Choose a resource type and one or more actions. The builder offers convenient presets for Read only, Contributor, and Full access.
- Select whether the policy allows or denies those actions. Note that a matching deny overrides access granted by any other policy.
- Choose one resource or all resources of that type.
- Validate to create the policy.
Writing Cedar directly
When you need more control than the visual builder provides, open Policies in the dashboard and click New policy, then select the Cedar editor. The editor is useful for:- Granting access through a workspace role
- Writing additional
whenorunlessconditions - Combining several principal or resource conditions
- Reviewing or editing the exact policy source
Creating policies through the API
Policies can also be created, updated, listed, and deleted through the Policy API. An API-created policy contains the same fields as a dashboard policy (displayName and description are optional).
OuterProduct’s API uses Connect over HTTP. Raw HTTP requests must include Connect-Protocol-Version: 1.
Available actions
The current policy model includes the following major resource-specific actions.| Resource | Actions |
|---|---|
| Account | Account administration and creation or listing of top-level resources |
| User | get_user, update_user, disable_user, list_workspaces, create_workspace, switch_workspace, get_invitation, accept_invitation, and API-key actions |
| Workspace | get_workspace, update_workspace, list_members, update_member, delete_member, list_invitations, create_invitation, delete_invitation, list_policies, create_policy |
| Policy | get_policy, update_policy, delete_policy |
| Volume | volume_read, volume_write, volume_manage |
| Secret | secret_read, secret_manage, secret_use |
| Image | read_image, use_image |
| Run | read_run, execute_run, cancel_run, delete_run |
Built-in access
OuterProduct includes built-in policies for common ownership and self-service behavior. Among other things, these policies allow users to:- Manage their own user information and API keys, and create and switch between their workspaces
- View the workspace, its members, policies, and billing, and the user information of its other members
- Create volumes, secrets, images, and runs in the workspace
- Read, use, and manage every volume, secret, image, and run the workspace owns, not only those they created
- As workspace admins or owner: update the workspace and its members, manage invitations and policies, and top up the balance
Built-in policies are evaluated alongside policies created in the dashboard. They cannot be viewed or edited as ordinary dashboard policies. Dashboard policies never decide who may manage policies.