XingLu WangandDan Heath
4fc872fc15
* docs: Create grants topic * Update grants * Restructuring of permissions docs * Fixing links Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com> * Update website/content/docs/concepts/security/permissions/index.mdx * Update website/content/docs/concepts/security/permissions/index.mdx * Update website/content/docs/concepts/security/permissions/advanced.mdx * Apply suggestions from code review Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com> * docs: Add redirect for deleted file --------- Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
67 lines
2.7 KiB
Plaintext
67 lines
2.7 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Permissions Overview
|
|
description: |-
|
|
Boundary's permissions model
|
|
---
|
|
|
|
# Permissions in Boundary
|
|
|
|
## Overview
|
|
|
|
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](/boundary/docs/concepts/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](/boundary/docs/concepts/security/permissions/grants) 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](/boundary/docs/concepts/security/permissions/grants).
|
|
|
|
## Roles
|
|
|
|
A [role](/boundary/docs/concepts/domain-model/roles) 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](/boundary/docs/concepts/iam). |