-
Notifications
You must be signed in to change notification settings - Fork 37
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: DOC-1479 DOC-1481 DOC-462 User Management Refactor (#4712)
* docs: DOC-1479 * docs: updated content * docs: cleaned up project scope page * chore: fix broken links * docs: DOC-1481 * docs: improve resource role intro * docs: fix broken URL * docs: updated content * docs: added guide for resource filer * docs: added create a custom role guide * docs: added resource keys and scopes * docs: add permissions page * docs: updated roles section * docs: updated index page * chore: added new def * save * docs: added guides for user and team management * chore: update * docs: fix broken URL * docs: fix broken URLs * docs: added role assignment guide * docs: updated main index page for user management * docs: added ABAC guide * docs: minor updates * chore: fix broken URL * chore: ready for review * chore: fix eslint error * docs: vale feedback * Optimised images with calibre/image-actions * docs: more vale feedback * Optimised images with calibre/image-actions * Optimised images with calibre/image-actions * docs: apply suggestions from code review Co-authored-by: caroldelwing <[email protected]> Co-authored-by: Lenny Chen <[email protected]> * ci: auto-formatting prettier issues * docs: apply suggestions from code review Co-authored-by: Lenny Chen <[email protected]> Co-authored-by: caroldelwing <[email protected]> * docs: apply suggestions from code review Co-authored-by: caroldelwing <[email protected]> * ci: auto-formatting prettier issues * docs: apply suggestions from code review Co-authored-by: caroldelwing <[email protected]> * ci: auto-formatting prettier issues --------- Co-authored-by: vault-token-factory-spectrocloud[bot] <133815545+vault-token-factory-spectrocloud[bot]@users.noreply.github.com> Co-authored-by: caroldelwing <[email protected]> Co-authored-by: Lenny Chen <[email protected]> Co-authored-by: karl-cardenas-coding <[email protected]>
- Loading branch information
5 people
authored
Nov 22, 2024
1 parent
699cbf1
commit 38a1cc4
Showing
62 changed files
with
3,558 additions
and
2,001 deletions.
There are no files selected for viewing
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
242 changes: 242 additions & 0 deletions
242
docs/deprecated/user-management/palette-rbac/palette-rbac.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,242 @@ | ||
| --- | ||
| sidebar_label: "Roles" | ||
| title: "Roles" | ||
| description: "Palette User Access control using RBAC" | ||
| icon: "" | ||
| hide_table_of_contents: false | ||
| tags: ["user-management", "rbac"] | ||
| --- | ||
|
|
||
| RBAC stands for Role-Based Access Control. RBAC allows a single user to have different types of access control based on | ||
| the resource being accessed. RBAC is the scenario that allows the Tenant Admin to grant full and unrestricted access to | ||
| some parts of the system and withhold it for some others. | ||
|
|
||
| Palette enforces a very well-structured RBAC design on how to grant granular access to resources and their operations | ||
| within our management console. We maintain precise Roles and Resource Access Control List. Role-based access control | ||
| primarily focuses on assigning permissions to roles instead of individual users and then assigning these roles to users. | ||
| Multiple roles can be assigned to a user, which defines the permitted actions on the resource. This module lists and | ||
| enumerates all the roles available within the Palette console within specific scopes. | ||
|
|
||
| Palette enables: | ||
|
|
||
| - A role can have multiple permissions. We encourage custom role creation, coupling the wide range of Palette | ||
| permissions. | ||
|
|
||
| - Multiple roles can be assigned to a single user, defining the permitted actions on a Palette resource. | ||
|
|
||
| ## Palette RBAC Model | ||
|
|
||
| The Palette RBAC Model, is based on the following three components: | ||
|
|
||
| - Scopes | ||
| - Permissions | ||
| - Roles | ||
|
|
||
| ### Scopes | ||
|
|
||
| A Scope defines the resources on which the role has coverage. The scope will be either `Tenant` or `Project`. For | ||
| example, a role within the scope project can operate within the projects. The combination of user and roles indicates | ||
| the totality of the accessibility available to that user. Scopes are structured in a parent-child relationship. Each | ||
| level of hierarchy makes the Scope more specific. The roles are assigned at any of these levels of Scope. The level you | ||
| select determines how widely the role is applied. Lower levels inherit role permissions from higher levels. | ||
|  | ||
|
|
||
| The following are the major properties of Palette driven Scopes: | ||
|
|
||
| - Scopes control the visibility of the resource. | ||
|
|
||
| - Resource created in the higher scope will be visible in the lower scope as read-only. The cluster profiles created by | ||
| a tenant will be available to all the projects created by that tenant. | ||
|
|
||
| - Resource Isolation: Resources within the same scope will be restricted to the respective scope entity. | ||
|
|
||
| - Cluster Profile created in project-1 will not be available in project-2 of the same tenant | ||
|
|
||
| - Resource with the same name can co-exist across scopes and will be distinguished with scope prefix (icon) | ||
| - A profile with the same name can be created in tenant and project scope. The resource will have the scope | ||
| information, which helps to distinguish them. | ||
|
|
||
| Palette resources can be allocated to roles under **Three Scopes**: | ||
|
|
||
| - **System** (The system admin internal to Palette) | ||
|
|
||
| - **Tenant** | ||
|
|
||
| - **Project** | ||
|
|
||
|  | ||
|
|
||
| ### Permissions | ||
|
|
||
| Permissions determine the type of operations allowed on a resource. Permissions can be defined in the following format: | ||
|
|
||
| `resourceKey.operation` | ||
|
|
||
| Examples: | ||
|
|
||
| - `cluster.create` | ||
| - `cluster.edit` | ||
| - `cluster.delete` | ||
|
|
||
| Each permission has a defined scope. The role creation is based on scope, type and permissions. | ||
|
|
||
| #### Palette Permissions | ||
|
|
||
| Palette has a wide range of permissions and these permissions can be combined in any combination as per the user | ||
| requirements to create a role. If the Palette built-in roles does not meet the specific needs of your organization, | ||
| custom roles can be created using different combination of these permissions. Just like built-in roles, you can assign | ||
| custom roles to users or teams within a specific scope (Tenant or Project). Refer to the available set of permissions in | ||
| the [Permissions](permissions.md) page. | ||
|
|
||
| ### Roles | ||
|
|
||
| A Role is a collection of permissions. When a role is assigned to a user, it means all the permissions the role contains | ||
| are assigned to that user. The Role will have a **Scope**. The Type signifies the creator's scope and the Scope | ||
| signifies the role visibility. The permissions will be restricted to the permission's scope list based on the role's | ||
| scope. The ProfileEditor will be visible under Tenant, but neither the Tenant nor the Project admins are allowed to | ||
| modify the Project Scopes. | ||
|
|
||
| ## Access Modes | ||
|
|
||
| - Tenant | ||
| - Project | ||
|
|
||
| ### Tenant | ||
|
|
||
| Tenant is an isolated workspace within the Palette. `Users` and `Teams` with specific `Roles` can be associated with the | ||
| Tenant(s) you create. Palette provides a [wide set of permissions](tenant-scope-roles-permissions.md) under the scope of | ||
| a Tenant. Everyone is a user and there should be at least one user with Tenant Admin privilege to control the product | ||
| operations. | ||
|
|
||
| ### Project | ||
|
|
||
| The Global Project Scope holds a group of resources, in a logical grouping, to a specific project. The project acts as a | ||
| namespace for resource management. Users and Teams with specific roles can be associated with the project, cluster, or | ||
| cluster profile you create. Users are members of a tenant who are assigned | ||
| [project scope roles](./project-scope-roles-permissions.md) that control their access within the platform. | ||
|
|
||
| ## Default Palette Roles | ||
|
|
||
| Palette RBAC has several built-in roles that can be assigned to users and teams. Role assignments are the way you | ||
| control access to Palette resources. | ||
|
|
||
| ### Tenant Scope Default Roles | ||
|
|
||
| Global Tenant roles are scoped at the tenant level. Palette has several built-in tenant roles that can be assigned to | ||
| users and teams. Refer to [Tenant Scope Roles](./tenant-scope-roles-permissions.md) for a detailed list of all the roles | ||
| available in Palette. | ||
|
|
||
| ### Project Scope Default Roles | ||
|
|
||
| The Project scope roles can be assigned to users and teams at the project scope. Palette has several built-in project | ||
| scoped roles that can be assigned to users and teams. Refer to | ||
| [Project Scope Roles](./project-scope-roles-permissions.md) for a detailed list of all the roles available Pallete. | ||
|
|
||
| ## Assign Palette Specific Roles to Users | ||
|
|
||
| The Default (built-in) roles of Palette can be directly assigned to a user. The roles needs to be assigned based on who | ||
| needs the access. The roles can be assigned to Users or Teams. The appropriate role needs to be selected from the list | ||
| of several built-in roles. If the built-in roles are not meeting the specific needs of your organization, you can | ||
| [create your own custom roles](./create-custom-role.md). | ||
|
|
||
| 1. Login to Palette console as `Tenant Admin`. | ||
|
|
||
| 2. Select **Users and Teams** from the left **Main Menu** to list the created users. | ||
|
|
||
| 3. From the list of users **select the user** to be assigned with role to open the role addition wizard. | ||
|
|
||
| 4. Make the choice of role category from the top tabs: | ||
|
|
||
| - Project Role | ||
| - Tenant Role | ||
| - Workspace Role | ||
|
|
||
| 5. Once the choice of category is made Click on **+ New Role**. | ||
|
|
||
| 6. In the **Add Roles to User-name** wizard, select the project name from the drop down and select the roles from the | ||
| list. | ||
|
|
||
| 7. Confirm to complete the wizard. | ||
|
|
||
| 8. The role user association can be edited and deleted from the **left Main Menu**. | ||
|
|
||
| ### Assign Custom Roles to Users | ||
|
|
||
| 1. Login to Palette console as `Tenant Admin`. | ||
|
|
||
| 2. Select **Users and Teams** from the left ribbon menu to list the [created users](../user-management.md). | ||
|
|
||
| 3. From the list of users **select the user** to be assigned with role to open the role addition wizard. | ||
|
|
||
| 4. Make the choice of role category from the top tabs: | ||
|
|
||
| - Project Role | ||
| - Tenant Role | ||
| - Workspace Role | ||
|
|
||
| 5. Once the choice of category is to br made by clicking on **+ New Role**. | ||
|
|
||
| 6. In the **Add Roles to User-name** wizard, select the project name from the drop down and select the roles from the | ||
| list. | ||
|
|
||
| 7. Confirm to complete the wizard. | ||
|
|
||
| 8. The role user association can be edited and deleted from the `kebab menu`. | ||
|
|
||
| ## Example Scenario: | ||
|
|
||
| Palette has a number of permissions that you can potentially include in your custom role. Here is an example scenario | ||
| enumerating the minimum permissions required for a user to **Create a Cluster** in Palette platform. | ||
|
|
||
| #### 1. Decide the actions, scopes and permissions required by the user to Create a Cluster. | ||
|
|
||
| The role creation is done from the `Tenant Admin` console. For the above scenario, two roles needs to be created under | ||
| `Project` and `Tenant` scope and attached to the user. | ||
|
|
||
| #### 2. Identify the Permissions required under `Project Scope`: | ||
|
|
||
| - Add the minimum `Project` management permissions | ||
|
|
||
| - project.list | ||
| - project.get | ||
|
|
||
| - Add the minimum permissions required for `Cloud Account` creation | ||
|
|
||
| - cloudaccount.create | ||
| - cloudaccount.get | ||
| - cloudaccount.list | ||
|
|
||
| - Add the `ClusterProfile` permissions | ||
|
|
||
| - clusterProfile.create | ||
| - clusterProfile.delete | ||
| - clusterProfile.get | ||
| - clusterProfile.list | ||
| - clusterProfile.publish | ||
| - clusterProfile.update | ||
|
|
||
| - Add the `Cluster` permissions (for creating and listing the cluster) | ||
|
|
||
| - cluster.create | ||
| - cluster.list | ||
| - cluster.get | ||
|
|
||
| - Add the `Location` permission. | ||
|
|
||
| - location.list | ||
|
|
||
| - Add the `Cloud Configuration` permissions for node pool management | ||
| - cloudconfig.create | ||
|
|
||
| #### 3. Identify the Permissions required under `Tenant Scope`: | ||
|
|
||
| To attach the Packs and Integrations from Palette public repository, add the `Registry Permissions`. The minimum | ||
| permission required in this scenario is: | ||
|
|
||
| - packRegistry.get | ||
|
|
||
| #### 4. Attach Roles to the User and Create the Cluster | ||
|
|
||
| - Once both the roles are created with the above scopes, attach them to the user. | ||
|
|
||
| - Login to Palette console using the user credentials to create the cluster profile and the cluster. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,72 @@ | ||
| --- | ||
| sidebar_label: "User & Role Management" | ||
| title: "User Management" | ||
| description: | ||
| "Learn how to manage users and roles in Palette. Palette has a rich RBAC system that allows you to manage user access | ||
| to resources." | ||
| hide_table_of_contents: false | ||
| sidebar_custom_props: | ||
| icon: "roles" | ||
| tags: ["user-management"] | ||
| --- | ||
|
|
||
| This section touches upon the initial login aspects for Tenant Admins and non-admin users and the RBAC setup within | ||
| Palette. | ||
|
|
||
| ## User Login | ||
|
|
||
| For a Tenant admin, the password shall be set upon the initial login. The Tenant admin can add non-admin users. For all | ||
| users, login can be made available using the following options: | ||
|
|
||
| - Using Palette credentials on the login page. | ||
| - SSO using Identity Providers that use SAML 2.0: | ||
| - Azure Active Directory | ||
| - Okta | ||
| - Keycloak | ||
| - OneLogin | ||
| - Microsoft ADFS | ||
| - Others | ||
|
|
||
| ## RBAC | ||
|
|
||
| Palette allows the users that have been added to be allowed or restricted access to resources based on the roles set by | ||
| the tenant admin. This Role-Based Access Control is explained in detail on the RBAC | ||
| [page](palette-rbac/palette-rbac.md#permissions). | ||
|
|
||
| ## Roles and Permissions | ||
|
|
||
| The Tenant admin can allow or restrict access of resources to users which can differ as per the scenario. A user can | ||
| have complete access to a specific project but can be restricted access to other projects in which there is no | ||
| involvement. An intermediate stage is also possible where read-only access can be provided in some projects. The Roles | ||
| and Permissions sections on the [RBAC](./palette-rbac/palette-rbac.md) page provide more details on this. | ||
|
|
||
| To add a user to a project: | ||
|
|
||
| 1. Sign in as a Tenant admin and navigate to the **Users and Teams** section of the Tenant settings Menu. | ||
|
|
||
| 1. Click on the user that you want to enable access to. | ||
|
|
||
| 1. In the **Role** editor that opens to the side, find the **Project Roles** section and click **Add Role**. | ||
|
|
||
| 1. Select the required **Project** from the dropdown menu and enable the **Roles** as needed. | ||
|
|
||
| ## Multi-Organization Support for Users | ||
|
|
||
| Palette is incorporating multi-organization support for its users. With this feature, we provide our users with the | ||
| flexibility of having a unique email address ID across multiple organizations. Hence, the users can maintain SSO | ||
| credentials across multiple organizations/tenants. | ||
|
|
||
| The key benefits of this feature are: | ||
|
|
||
| - The use of a single email address ID across multiple organizations. | ||
| - Within an organization, maintain a unique email ID. | ||
| - In the case of password-based authentication, the same password is applicable across multiple organizations. The | ||
| change of password, made under a particular organization, is applied across other organizations to maintain a single | ||
| password across all organizations. | ||
| - The password policy stays independent of organizations/tenants. Each tenant retains individual password policy. | ||
| - For SSO-based authentication, for each organization/tenant, the individual identity provider client application can be | ||
| configured. Hence, allowing the configuration of a single SSO with multiple identity providers across multiple | ||
| tenants/organizations mapping each client app to a tenant. | ||
| - However, for self-sign-up, the unique email address ID is enforced across tenants to avoid conflicts. | ||
| - In the Palette console, the users can switch between the organizations/tenants using the Organization drop down menu | ||
| of the login page. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.