@ -7,17 +7,17 @@ description: How to manage Roles and Permissions
# Manage Roles and Permissions
[Roles](/docs/concepts/domain-model/roles) in Boundary manage the permissions given to Principals. Roles can be defined at the global, org, or project scopes.
[Roles](/docs/concepts/domain-model/roles) in Boundary manage the permissions given to principals ([Users](/docs/concepts/domain-model/users)/[Groups](/docs/concepts/domain-model/groups)). Roles can be defined at the global, org, or project scopes.
In this example, we're going to show you how to create a role in Boundary, assign that roles grants, and assign Principals to the role.
In this example, we're going to show you how to create a role in Boundary, assign that roles grants, and assign principals to the role.
~> Note that all resource ID's in this example are illustration only - ID's are uniquely generated for every resource upon creation with the exception being
generated resources in `dev mode`. Please make sure to use the resource ID's that are generated when running this example. For example, if you run
~> Note that all resource IDs in this example are illustration only - IDs are uniquely generated for every resource upon creation with the exception being
generated resources in `dev` mode. Please make sure to use the resource IDs that are generated when running this example. For example, if you run
`boundary roles create`, use the resource ID of the role seen in stdout, not the ID in the example command.
# Create a Role
Roles can live in the global, org, or project scopes. In this example we will create a role in the generated org scope in dev mode.
Roles can live in the global, org, or project scopes. In this example we will create a role in the generated org scope in `dev` mode.
<Tabs>
<Tab heading="CLI">
@ -66,7 +66,7 @@ Role information:
resource "boundary_scope" "role" {
name = "my_role"
description = "My first role!"
scope_id = o_1234567890 // sets the role's scope as the default generated org. To change the role's scope provide a different scope id.
Grants give roles permission to perform actions. For more information on how to format grants see [Permission Grant Formats](https://boundaryproject.io/docs/concepts/security/permissions#permission-grant-formats).
Grants describe the actions that the principals should be allowed to perform. For more information on how to format grants see [Permission Grant Formats](https://boundaryproject.io/docs/concepts/security/permissions#permission-grant-formats).
In this example we give a role read and list permissions to all resources.
<Tabs>
@ -202,9 +202,9 @@ Role information:
resource "boundary_scope" "role" {
name = "my_role"
description = "My first role!"
scope_id = o_1234567890 // sets the role's scope as the default generated org. To change the role's scope provide a different scope id.
principals = u_1234567890 // assigns the default generated admin user to the role. To assign a different principal provide a different principal id.
grants = ["id=*;type=*;action=read,list"] // assigns grants for read and list actions on all resources to the role
@ -7,23 +7,37 @@ description: How to manage Boundary scopes
# Manage Scopes
[Scopes](/docs/concepts/domain-model/scopes) are a foundational part of Boundary. They allow users to segregate resources and assign ownership of resources to principals. There are three hierarchies of scopes within Boundary:
[Scopes](/docs/concepts/domain-model/scopes) are a foundational part of Boundary. They allow users to partition resources and assign ownership of resources to principals. There are three types of scopes within Boundary:
1. Global
1. Global (`global`)
2. Org
3. Project
Some resources can only be associated with a specific level of scope. Targets for example can only be project scope. Other resources can be of multiple scopes. For example, users can be created within the `global` scope or an org-level scope. See the [domain model](/docs/concepts/domain-model) for detailed resource specific information.
These are in a hierarchy:
* There is only one single `global` scope. It is meant as the entry point for initial administration/setup and to manage org scopes.
* Under the `global` scope there can be many org scopes. These are used to hold IAM-related resources and project scopes.
* Under each org scope can be many project scopes. These are used to hold infrastructure-related resources.
Some resources can only be associated with a specific level of scope. As an example, [Targets](/docs/concepts/domain-model/targets) can only be contained within a project scope. Other resources can be contained by multiple scopes. For example, users can be created within the `global` scope or an org-level scope. See the [domain model](/docs/concepts/domain-model) for detailed resource specific information.
In this example, we're going to create two scopes, an org and a project.
~> All resource ID's in this example are illustration only - ID's are uniquely generated for every resource upon creation with the exception being
generated resources in `dev` mode. Please make sure to use the resource ID's that are generated when running this example. For example, if you run
~> All resource IDs in this example are illustration only - IDs are uniquely generated for every resource upon creation with the exception being
generated resources in `dev` mode. Please make sure to use the resource IDs that are generated when running this example. For example, if you run
`boundary users create`, use the resource ID of the user seen in stdout, not the ID in the example command.
## Create an Org
An org lives in the global scope. In this example, we're going to create an org. In doing so, we're going to opt for automated role creation during scope generation in order to simplify management of the scope by the user.
In this example, we're going to create an org, which lives in the `global` scope.
~> The CLI and UI will default to having certain administrative roles be created
automatically when a scope is created, so that the user that created the scope
can immediately manage it. The Terraform provider defaults skipping creation of
those roles so that resources are not created outside of Terraform's purview. To
simplify this example, we are telling Terraform to allow these roles to be
created in both this section and in the next section where we create a project