Permissions in Boundary

Boundary’s permissions model is a composable, RBAC, allow-only model that attempts to marry flexibility with usability. This page discusses the permission model’s fundamental concepts, provides examples of the specific forms of allowed grants, and contains a table that acts as an easy cheat sheet to help those new to its grant syntax with crafting roles.

Each grant is a mapping that describes a resource or set of resources and the actions that should be allowed on them. Thus, each grant contains one or more of:

• An id field that indicates a specific resource or a wildcard to match all
• A type field that indicates a specific resource type or a wildcard to match all
• An actions field indicating which actions to allow the client to perform on the resources matched by id and type

Grant strings can be supplied via a human-friendly string syntax or via JSON.

Roles are composable; a user’s final set of grants will be composed of various roles that each contribute grants to a set of principals that include that user or groups of which that user is a member.

Applicable Resource Types

Boundary’s domain model is based on resource types. These can be implemented directly, such as with targets, or they can be abstract types that are implemented by concrete types within the system. As an example of the latter, a host catalog is an abstract type and a Static host catalog is a concrete type.

From a permissions standpoint, however, all actions take place against directly implemented or abstract types. There may be actions that are only implemented by some concrete types (e.g., not all auth methods will support a change-password action), but the permissions model still defines these at the abstract level. This helps keep the overall system relatively simple and predictable.

Scopes are Permission Boundaries

Every role assigns grants within a specific scope: either the scope in which the role exists, or a scope that is a child of the scope in which the role exists. This is controlled by the role’s “grant scope ID”.

When a request is made, the scope in which to discover grants is either provided by the client (if against specific collection types) or is looked up using the resource’s ID. This scope ID, along with the user’s ID and the IDs of the groups the user belongs to, controls which roles are fetched to provide grants for the request.

A role provides grants for a request if the grant scope ID matches the request’s scope ID and one or more of the following are true:

• The user’s ID is contained in the principal IDs set on the role
• A group the user belongs to is contained in the principal IDs set on the role
• The user is logged in and the u_auth user is contained in the principal IDs set on the role
• The role contains the u_anon user in the in the principal IDs set on the role

Permission Grant Formats

Because of the aforementioned properties of the permissions model, grants are relatively simple. All grants take one of four forms. These examples use the canonical string syntax; the JSON equivalents are simply an object with a string id value, a string type value, and a string array actions value.

ID Only

This is the simplest form: for a given specific resource, allow these actions. Example:

id=hsst_1234567890;actions=read,update

This grants read and update actions to that single resource.

Type Only

For a given type, allow these actions. Example:

type=host-catalog;actions=create,list

Because type specifies only a collection as opposed to specific resources within that collection, only collection actions are allowed in this format. Currently, this is create and list.

There is one additional restriction: this is only valid against “top-level” resource types, which currently are:

• Auth Methods
• Auth Tokens
• Groups
• Host Catalogs
• Roles
• Scopes
• Sessions
• Targets
• Users

The reason for this is that other types of resources are contained within one of these resource types; for instance, accounts are instantiated within an auth method. To specify actions against those, you must also specify to which specific containing resource you want the grants to apply. This can be done with the pinned format shown below.

Pinned ID

This form “pins” actions to a non-top-level type within a specific ID. It’s easiest to explain with an example:

id=hcst_1234567890;type=host-set;actions=create,read,update

In this example, the user is able to create, read, or update host sets within the scope, but only the host sets belonging to host catalog hcst_1234567890. Pinning is essentially a way to use top-level resources to create mini permission boundaries for their subordinate resources.

Wildcard ID

Various wildcard possibilities are allowed:

Wildcard ID

When just the ID is *, it matches all IDs of the given type. This can be used with both top-level resource types and not. Example:

id=*;type=host-set;actions=create,read,update,set-hosts

Wildcard Type

For non-top-level resources with pinned IDs, the type can be a wildcard:

id=hcst_1234567890;type=*;actions=create,read,update

This would allow create, read, and update actions for all types of subordinate resources (in this case host sets and hosts) underneath the host catalog with ID hcst_1234567890.

Wildcard ID and Type

If ID and type are both a wildcard, the grant is essentially a catch-all that will match any resource of any type within the scope and allow the given actions.

id=*;type=*;actions=read,list

Wildcard ID, Type, and Actions

Finally, ID, type, and actions can all be wildcards:

id=*;type=*;actions=*

Such a grant is essentially a full administrator grant for a scope.

Templates

A few template possibilities exist, which will at grant evaluation time substitute the given value into the ID field of the grant string:

• {{account.id}}: The substituted value is the account ID associated with the token used to perform the action. As an example, id={{account.id}};actions=read,change-password" is one of Boundary’s default grants to allow users that have authenticated with the Password auth method to change their own password.

• {{user.id}}: The substituted value is the user ID associated with the token used to perform the action.

Resource Table

The following table works as a quick cheat-sheet to help you manage your permissions. Note that it’s not exhaustive; for brevity it does not show wildcard or templated grant strings.