Update roles and scopes workflow docs (#656)

pull/659/head
Jeff Mitchell 6 years ago committed by GitHub
parent 2fd37b8a88
commit 1a6564db91
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -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.
scope_id = o_1234567890
}
```
@ -76,7 +76,7 @@ resource "boundary_scope" "role" {
# Assign Principals to a Role
Users and groups are given permissions to perform actions by assigning them to a role.
Users and groups are granted permissions to perform actions by assigning them to a role.
<Tabs>
<Tab heading="CLI">
@ -141,7 +141,7 @@ resource "boundary_scope" "role" {
# Assign Grants to a Role
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
scope_id = o_1234567890
principals = u_1234567890
grants = ["id=*;type=*;action=read,list"]
}
```

@ -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
scope.
<Tabs>
<Tab heading="CLI">
@ -68,10 +82,11 @@ Scope information:
```hcl
resource "boundary_scope" "org" {
scope_id = "global"
name = "my_org"
description = "My first org"
auto_create_role = true
scope_id = "global"
name = "my_org"
description = "My first org"
auto_create_default_role = true
auto_create_admin_role = true
}
```
@ -81,7 +96,7 @@ resource "boundary_scope" "org" {
## Create a Project
Next, we're going to add a project scope to our org. Again, we're going to opt for automated role creation to simplify management of this scope.
Next, we're going to add a project scope to our org.
<Tabs>
<Tab heading="CLI">
@ -132,8 +147,9 @@ resource "boundary_scope" "project" {
description = "My first project"
# scope_id is taken from the org resource defined above
scope_id = boundary_scope.org.id
auto_create_role = true
scope_id = boundary_scope.org.id
auto_create_admin_role = true
auto_create_default_role = true
}
```

Loading…
Cancel
Save