Mirrors/unleash.unleash
1
0
Fork 0
mirror of https://github.com/Unleash/unleash.git synced 2025-05-31 01:16:01 +02:00
Code Issues Projects Releases Wiki Activity

RBAC page docs fixes (#9276)

Browse Source
This commit is contained in:
Melinda Fekete 2025-02-10 16:54:18 +01:00 committed by GitHub
parent 1ffcfe826f
commit 5c4060d6ae
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 97 additions and 95 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

192
website/docs/reference/rbac.md
View File

@ -9,41 +9,28 @@ title: Role-based Access Control
:::
## Core principles {#core-principles}
Unleash implements role-based access control on two levels:
Unleash has two levels in its hierarchy of resources:
1. **Root resources** - Everything that lives across the entire Unleash instance. Examples of this include:
- activation strategies
- context field definitions
- integration configurations
- applications
- users
2. **Project resources** - Resources which are only available under a project. Today this is only “feature flags” (but
we expect more resources to live under a project in the future). A feature flag will belong to only one single
project. In Unleash-Open source there exists only a single project, the “default” project, while Unleash Enterprise
supports multiple projects.
1. **Root level** - affects resources shared across the entire Unleash instance, for example activation strategies, users, integrations.
2. **Project level** - affects resources specific to a [project](./projects), such as feature flags, change requests, or API tokens.
![RBAC overview](/img/rbac.png)
## Predefined roles
Unleash comes with a set of built-in predefined roles that you can use. The _root roles_ are available to all Unleash
users, while the _project-based roles_ are only available to [Pro](/availability#plans) and [Enterprise](https://www.getunleash.io/pricing) users. The below table lists the roles,
what they do, and what plans they are available in. Additionally, [Enterprise](https://www.getunleash.io/pricing) users can create their
Unleash comes with a set of predefined roles. Root roles are available to all Unleash
users, while the Project roles are only available to [Pro](/availability#plans) and [Enterprise](https://www.getunleash.io/pricing) users. The following table lists the roles, what they do, and what plans they are available in. Additionally, [Enterprise](https://www.getunleash.io/pricing) users can create their
own [custom root roles](#custom-root-roles) and [custom project roles](#custom-project-roles).
When you add a new user, you can assign them one of the root roles listed below.
| Role | Scope | Description | Availability |
|------------|---------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------|
| **Admin** | Root | Users with the root admin role have superuser access to Unleash and can perform any operation within the Unleash platform. | All versions |
| **Editor** | Root | Users with the root editor role have access to most features in Unleash, but can not manage users and roles in the root scope. Editors will be added as project owners when creating projects and get superuser rights within the context of these projects. Users with the editor role will also get access to most permissions on the default project by default. | All versions |
| **Editor** | Root | Users with the root editor role have access to most features in Unleash, but they cannot manage users and roles in the root scope. Editors will be added as project owners when creating projects and get superuser rights within the context of these projects. Users with the editor role will also get access to most permissions on the default project by default. | All versions |
| **Viewer** | Root | Users with the root viewer role can only read root resources in Unleash. Viewers can be added to specific projects as project members. Users with the viewer role may not view API tokens. | All versions |
| **Owner** | Project | Users with the project owner role have full control over the project, and can add and manage other users within the project context, manage feature flags within the project, and control advanced project features like archiving and deleting the project. | [Pro](/availability#plans) and [Enterprise](https://www.getunleash.io/pricing) |
| **Member** | Project | Users with the project member role are allowed to view, create, and update feature flags within a project, but have limited permissions in regards to managing the project's user access and can not archive or delete the project. | [Pro](/availability#plans) and [Enterprise](https://www.getunleash.io/pricing) |
## Custom Root Roles
## Custom root roles
:::note Availability
@ -52,7 +39,7 @@ When you add a new user, you can assign them one of the root roles listed below.
:::
Custom root roles let you define your own root roles with a specific set of root permissions. The roles can then be
assigned to entities (users, service accounts and groups) at the root level. This allows you to control access to
assigned to entities (users, service accounts, and groups) at the root level. This allows you to control access to
resources in a more precise, fine-grained way. For a step-by-step walkthrough of how to create and assign custom root
roles, refer to [_how to create and assign custom root roles_](../how-to/how-to-create-and-assign-custom-root-roles.md).
@ -66,77 +53,92 @@ Each custom root role consists of:
You can assign the following root permissions:
#### Integration permissions
| Permission Name | Description |
|---------------------|------------------------------------|
| Create integrations | Lets the user create integrations. |
| Update integrations | Lets the user update integrations. |
| Delete integrations | Lets the user delete integrations. |
#### API token permissions
| Permission Name | Description |
|----------------------------|-------------------------------------------|
| Read frontend API tokens | Lets the user read frontend API tokens. |
| Create frontend API tokens | Lets the user create frontend API tokens. |
| Update frontend API tokens | Lets the user update frontend API tokens. |
| Delete frontend API tokens | Lets the user delete frontend API tokens. |
| Read client API tokens | Lets the user read client API tokens. |
| Create client API tokens | Lets the user create client API tokens. |
| Update client API tokens | Lets the user update client API tokens. |
| Delete client API tokens | Lets the user delete client API tokens. |
| Read frontend API tokens | View [frontend API tokens](./api-tokens-and-client-keys#frontend-tokens). |
| Create frontend API tokens | Create frontend API tokens. |
| Update frontend API tokens | Update frontend API tokens. |
| Delete frontend API tokens | Delete frontend API tokens. |
| Read client API tokens | View [client API tokens](./api-tokens-and-client-keys#client-tokens). |
| Create client API tokens | Create client API tokens. |
| Update client API tokens | Update client API tokens. |
| Delete client API tokens | Delete client API tokens. |
#### Application permissions
| Permission Name | Description |
|---------------------|------------------------------------|
| Update applications | Lets the user update applications. |
| Update applications | Update [applications](./applications). |
#### Authentication permissions
| Permission Name | Description |
|---------------------|------------------------------------|
| Change authentication settings | Update authentication settings, such as for [single sign-on (SSO)](./sso). |
#### Context field permissions
| Permission Name | Description |
|-----------------------|--------------------------------------|
| Create context fields | Lets the user create context fields. |
| Update context fields | Lets the user update context fields. |
| Delete context fields | Lets the user delete context fields. |
| Create context fields | Create [context fields](./unleash-context#custom-context-fields). |
| Update context fields | Update context fields. |
| Delete context fields | Delete context fields. |
#### Instance maintenance permissions
| Permission Name | Description |
|---------------------|------------------------------------|
| Change instance banners | Change instance [banners](./banners). |
| Change maintenance mode state | Change [maintenance mode](./maintenance-mode) state. |
| Update CORS settings | Update [CORS settings](./front-end-api#cors). |
| Read instance logs and login history | Read instance logs and [login history](./login-history.md). |
#### Integration permissions
| Permission Name | Description |
|---------------------|------------------------------------|
| Create integrations | Create [integrations](./integrations). |
| Update integrations | Update integrations. |
| Delete integrations | Delete integrations. |
#### Project permissions
| Permission Name | Description |
|-----------------|--------------------------------|
| Create projects | Lets the user create projects. |
| Create projects | Create [projects](./projects). |
#### Role permissions
| Permission Name | Description |
|-----------------|---------------------------|
| Read roles | Lets the user read roles. |
| Read roles | View [roles](./rbac). |
#### Segment permissions
| Permission Name | Description |
|-----------------|--------------------------------|
| Create segments | Lets the user create segments. |
| Edit segments | Lets the user edit segments. |
| Delete segments | Lets the user delete segments. |
| Create segments | Create [segments](./segments). |
| Edit segments | Edit segments. |
| Delete segments | Delete segments. |
#### Strategy permissions
| Permission Name | Description |
|-------------------|----------------------------------|
| Create strategies | Lets the user create strategies. |
| Update strategies | Lets the user update strategies. |
| Delete strategies | Lets the user delete strategies. |
| Create strategies | Create [strategies](./activation-strategies). |
| Update strategies | Update strategies. |
| Delete strategies | Delete strategies. |
#### Tag type permissions
| Permission Name | Description |
|------------------|---------------------------------|
| Update tag types | Lets the user update tag types. |
| Delete tag types | Lets the user delete tag types. |
| Update tag types | Update [tag types](./feature-toggles#tags). |
| Delete tag types | Delete tag types. |
## Custom Project Roles
## Custom project roles
:::note Availability
@ -146,7 +148,7 @@ You can assign the following root permissions:
Custom project roles let you define your own project roles with a specific set of project permissions down to the
environment level. The roles can then be assigned to users in specific projects. All users have viewer access to all
projects and resources, but must be assigned a project role to be allowed to edit a project's resources. For a
projects and resources but must be assigned a project role to be allowed to edit a project's resources. For a
step-by-step walkthrough of how to create and assign custom project roles, see [_how to create and assign custom project
roles_](../how-to/how-to-create-and-assign-custom-project-roles).
@ -154,65 +156,65 @@ Each custom project role consists of:
- a **name** (required)
- a **role description** (required)
- a set of **project and / or environment permissions** (required)
- a set of **project and environment permissions** (required)
### Project permissions
You can assign the following project permissions. The permissions will be valid across all of the project's
You can assign the following project permissions. These permissions are valid across all of the [project](./projects)'s
environments.
#### Features and strategies
| Permission Name | Description |
| --- | --- |
| Create feature flags within the project | Lets the user create feature flags within the project and create variants for said flag. Note that they **cannot assign strategies** to flags without having the _create activation strategy_ permission for the corresponding environment. |
| Update feature flags within the project | Lets the user update feature flag descriptions; mark flags as stale / not stale; add, update, and remove flag tags; and update flag variants within the project. |
| Update feature flag dependency | Lets the user update feature flag dependencies within the project. |
| Delete feature flags within the project | Lets the user archive feature flags within the project. |
| Change feature flag project | Lets the user move flags to other projects they have access to. |
| Create/edit variants | Lets the user create and edit variants within the project. (Deprecated with v4.21 in favor of environment-specific permissions for working with variants[^1].) |
| Create/edit project segment | Lets the user create and edit segments within the project. |
#### Project settings
| Permission Name | Description |
|-----------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Update the project | Lets the user update project settings, such as enabling/disabling environments, add users, etc. |
| User access read | Read access to Project User Access (included in "update the project" permission) |
| User access write | Write access to Project User Access (included in "update the project" permission)
| Default strategy read | Read access to default strategy configuration (included in "update the project" permission) |
| Default strategy write | Write access to default strategy configuration (included in "update the project" permission) |
| Read settings | Read access to other project settings (included in "update the project" permission) | |
| Write settings | Write access to other project settings (included in "update the project" permission)
| Delete the project | Lets the user delete the project. |
#### API tokens
| Permission Name | Description |
| --- | --- |
| Read API token | Read API tokens for a specific project |
| Create API token | Create API tokens for a specific project |
| Delete API token | Delete API tokens for a specific project |
| Read API token | View [API tokens](./api-tokens-and-client-keys) for a specific project. |
| Create API token | Create API tokens for a specific project. |
| Delete API token | Delete API tokens for a specific project. |
#### Change requests
| Permission Name | Description |
| --- | --- |
| Read change request | Read access to change request configuration |
| Write change request | Write access to change request configuration |
| Read change request | View [change request](./change-requests) configuration (included in _Update the project_). |
| Write change request | Edit change request configuration (included in _Update the project_). |
#### Features and strategies
| Permission Name | Description |
| --- | --- |
| Create feature flags | Create [feature flags](./feature-toggles) within the project and create feature flag variants. This permission alone does not give access to assigning strategies to a flags. Use the _create activation strategies_ environment permission, if needed. |
| Update feature flags | Update feature flag descriptions, mark flags as stale, add, update, and remove flag tags, and update flag variants within the project. |
| Update feature flag dependency | Update feature flag dependencies within the project. |
| Delete feature flags | Archive feature flags within the project. |
| Change feature flag project | Move flags to other projects they have access to. |
| Create/edit variants | Create and edit [variants](./strategy-variants) within the project. (Deprecated with v4.21. Use environment-specific permissions for working with variants.) |
| Create/edit project segment | Create and edit [segments](./segments) within the project. |
#### Projects
| Permission Name | Description |
|-----------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Update project | Edit all aspects of a [project](./projects), such as enabling or disabling environment or adding new users. |
| User access read | View to user access configuration (included in _Update project_). |
| User access write | Edit user access configuration (included in _Update project_).
| Default strategy read | View the default strategy configuration (included in _Update project_). |
| Default strategy write | Edit the default strategy configuration (included in _Update project_). |
| Read settings | View other project settings (included in _Update project_). | |
| Write settings | Edit other project settings (included in _Update project_).
| Delete the project | Delete the project. |
### Environment permissions
You can assign the following permissions on a per-environment level within the project:
| Permission Name | Description |
|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Create activation strategies | Lets the user assign feature flag activation strategies within the environment. |
| Update activation strategies | Lets the user update feature flag activation strategies within the environment. |
| Delete activation strategies | Lets the user delete feature flag activation strategies within the environment. |
| Enable/disable flags | Lets the user enable and disable flags within the environment. |
| Update variants | Lets the user create, edit and remove variants within the environment. |
| Approve a change request | Lets the user approve [change requests](./change-requests) in the environment. |
| Apply a change request | Lets the user apply change requests in the environment. |
| Skip change requests | Lets the user skip the change request process for a project and environment where change requests are enabled. |
| Create activation strategies | Assign feature flag [activation strategies](./activation-strategies) within the environment. |
| Update activation strategies | Update feature flag activation strategies within the environment. |
| Delete activation strategies | Delete feature flag activation strategies within the environment. |
| Enable/disable flags | Enable and disable flags within the environment. |
| Update variants | Create, edit, and remove variants within the environment. |
| Approve a change request | Approve [change requests](./change-requests) in the environment. |
| Apply a change request | Apply change requests in the environment. |
| Skip change requests | Skip the change request process for a project and environment where change requests are enabled. |
## Multiple Project Roles
## Multiple project roles
:::note Availability
@ -230,7 +232,7 @@ group needs to wear multiple hats. For example, a team member could serve as bot
tester. By combining roles, you simplify the access management process, eliminating the need to create a new, custom
role that encapsulates the needed permissions.
## User Groups
## User groups
:::note Availability
@ -260,9 +262,9 @@ Any user that is a member of a group with a root role will inherit that root rol
While a user can only have one role in a given project, a user may belong to multiple groups, and each of those groups
may be given a role on a project. In the case where a given user is given permissions through more than one group, the
user will inherit most permissive permissions of all their groups in that project.
user will inherit the most permissive permissions of all their groups in that project.
## User Group SSO Integration
## User group SSO integration
:::note Availability