Permissions in Boundary

Boundary's permissions model is a composable, RBAC, allow-only model that attempts to marry flexibility with usability. This section discusses the permission model's fundamental concepts, provides examples grant strings, and contains a table that acts as a cheat sheet to help those new to its grant syntax with crafting roles.

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.

At a very high level, permissions within Boundary are declared via grant strings and mapped to users via roles.

Grant strings

A grant string is a mapping that describes a resource or set of resources and the permissions that should be granted on them. Grant strings can be composed of up to 4 parts:

ID
Type
Actions
Output fields

To learn about writing grant strings with examples, see Grant Strings.

Roles

A role maps grant strings to principals (users and groups). 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, as determined by the role's "grant scope ID" value.

When a user makes a request, the scope in which to discover grants is either provided by the client (if against a resource collection itself) 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

Roles are composable; a user's final set of grants will be composed of grants that originate from all matching roles.

To learn more about Boundary's access management system, see Identity and Access Management.