diff --git a/content/docs/administration/access-identity/access-tokens.md b/content/docs/administration/access-identity/access-tokens.md index 0980703348da..ccf35bf4e36a 100644 --- a/content/docs/administration/access-identity/access-tokens.md +++ b/content/docs/administration/access-identity/access-tokens.md @@ -36,29 +36,9 @@ When using tokens, be mindful of the following security best practices: * Tokens can optionally be assigned an expiration period of up to two years, at which point the token will no longer be valid for any Pulumi operation. Expired tokens cannot be refreshed or reactivated. It's strongly recommended that you assign an expiration to your token to encourage token rotation and improve your organization's security posture. * Access tokens can create stacks if the organization's access management settings permit all members to do so, or if the token's assigned role includes the `stack:create` scope. Admin organization tokens always have this capability. The stack creator will automatically become its owner and will have all stack permissions, including deletion. See [RBAC](/docs/administration/access-identity/rbac/) for more on how org-wide settings and role scopes interact. -## Access token permissions - -### Personal tokens - -Personal access tokens carry the same permissions as the user who created them. This includes all organization memberships, team memberships, and role assignments that apply to the user across every Pulumi Cloud organization they belong to. - -### Organization tokens - -Organization tokens act on behalf of the organization itself. Rather than mapping to a fixed set of capabilities, organization tokens derive their permissions from the [RBAC role](/docs/administration/access-identity/rbac/roles/) assigned to them at creation time. This means you can tailor the exact level of access an organization token has—from read-only access to a subset of stacks, to full administrative control—by assigning the appropriate role. - -Organization tokens that are assigned no explicit role receive the organization's [default member role](/docs/administration/access-identity/rbac/roles/). The token's access is automatically limited to the single organization it was created in, unlike a personal token which spans all of a user's organizations. - -### Team tokens - -Team tokens act on behalf of a specific team within the organization. A team token's effective permissions are determined by the [roles assigned to that team](/docs/administration/access-identity/rbac/teams/) at the time each request is evaluated. If a team's role assignments change, those changes are immediately reflected in what the team token can do. - -Team tokens are useful for CI/CD pipelines that should be scoped to only the resources a particular team manages, without requiring a personal token from any individual team member. - -For a detailed reference on how permissions are structured and evaluated, see [Role-Based Access Control (RBAC)](/docs/administration/access-identity/rbac/). - ## Personal access tokens -Personal access tokens have the same permissions as your Pulumi Cloud user. This includes your respective permissions for all Pulumi Cloud organizations in which your user is a member. +Personal access tokens carry the same permissions as your Pulumi Cloud user. This includes all organization memberships, team memberships, and role assignments that apply to you across every Pulumi Cloud organization you belong to. ### Creating personal access tokens @@ -142,7 +122,7 @@ Both token types continue to work. The admin/standard distinction maps directly ## OIDC issued tokens -OIDC-issued access tokens generated in CI/CD workflows (such as GitHub Actions) do not receive admin privileges by default. To perform operations that require elevated access—such as creating or deleting stacks—you must explicitly request the admin scope when exchanging the OIDC token. +OIDC-issued access tokens generated in CI/CD workflows (such as GitHub Actions) do not receive admin privileges by default. To perform operations that require elevated access—such as creating or deleting stacks—you must explicitly request the admin scope when exchanging the OIDC token. For how to register and configure an issuer for these tokens, see [OIDC Issuers](/docs/administration/access-identity/oidc-issuers/). For example: diff --git a/content/docs/administration/access-identity/rbac/1-abac-rule.png b/content/docs/administration/access-identity/rbac/1-abac-rule.png deleted file mode 100644 index ff169e519a3b..000000000000 Binary files a/content/docs/administration/access-identity/rbac/1-abac-rule.png and /dev/null differ diff --git a/content/docs/administration/access-identity/rbac/1-create-role.png b/content/docs/administration/access-identity/rbac/1-create-role.png deleted file mode 100644 index 17dbf16c53e7..000000000000 Binary files a/content/docs/administration/access-identity/rbac/1-create-role.png and /dev/null differ diff --git a/content/docs/administration/access-identity/rbac/1-create-token-role.png b/content/docs/administration/access-identity/rbac/1-create-token-role.png deleted file mode 100644 index 880f16471799..000000000000 Binary files a/content/docs/administration/access-identity/rbac/1-create-token-role.png and /dev/null differ diff --git a/content/docs/administration/access-identity/rbac/2-create-role.png b/content/docs/administration/access-identity/rbac/2-create-role.png deleted file mode 100644 index e44d7940a27f..000000000000 Binary files a/content/docs/administration/access-identity/rbac/2-create-role.png and /dev/null differ diff --git a/content/docs/administration/access-identity/rbac/2-create-token-role.png b/content/docs/administration/access-identity/rbac/2-create-token-role.png deleted file mode 100644 index a5c5a8b3f574..000000000000 Binary files a/content/docs/administration/access-identity/rbac/2-create-token-role.png and /dev/null differ diff --git a/content/docs/administration/access-identity/rbac/3-create-role.png b/content/docs/administration/access-identity/rbac/3-create-role.png deleted file mode 100644 index a8bde0ac4328..000000000000 Binary files a/content/docs/administration/access-identity/rbac/3-create-role.png and /dev/null differ diff --git a/content/docs/administration/access-identity/rbac/4-create-role.png b/content/docs/administration/access-identity/rbac/4-create-role.png deleted file mode 100644 index eb4b9019d15b..000000000000 Binary files a/content/docs/administration/access-identity/rbac/4-create-role.png and /dev/null differ diff --git a/content/docs/administration/access-identity/rbac/5-create-role.png b/content/docs/administration/access-identity/rbac/5-create-role.png deleted file mode 100644 index ff87644913b8..000000000000 Binary files a/content/docs/administration/access-identity/rbac/5-create-role.png and /dev/null differ diff --git a/content/docs/administration/access-identity/rbac/_index.md b/content/docs/administration/access-identity/rbac/_index.md index 2facb5597fe0..dbec12ef2919 100644 --- a/content/docs/administration/access-identity/rbac/_index.md +++ b/content/docs/administration/access-identity/rbac/_index.md @@ -13,49 +13,52 @@ menu: identifier: administration-access-identity-rbac --- -Role-Based Access Control (RBAC) in Pulumi Cloud provides a flexible and secure way to manage access to your organization's resources. This allows you to exercise fine-grained control over who can access what resources in your organization and what actions they can perform. +Role-Based Access Control (RBAC) in Pulumi Cloud controls who can access which resources in your organization and what actions they can take. You compose access from reusable building blocks — scopes, permission sets, and roles — and assign it to users, teams, and machine tokens. -Leveraging Pulumi's RBAC features empower Enterprise organizations to follow best practices: +This model lets you: -- **Granular Access Control**: Define precise access levels for different resources. -- **Simplified Management**: Easily manage access as they grow by building out reusable RBAC elements. -- **Security**: Enforce least privilege access to resources. - -## Principals - -Roles can be assigned to three kinds of principals in Pulumi Cloud: - -- **Users**: Organization members can have a baseline organization role (Admin, Member, Billing Manager, or a custom role). When your organization has custom roles and "Assign custom roles to users" is enabled, admins can assign any custom role to individual members. -- **Teams**: Teams can be assigned one or more roles. Members of a team receive the union of the team's roles and their own user role. Team role assignments are available when the organization has custom roles enabled. -- **Organization access tokens**: Machine tokens can be assigned one role that defines the token's permissions across the organization. +- Define precise access levels for each type of resource. +- Reuse permission sets and roles instead of configuring access one resource at a time. +- Enforce least-privilege access across the organization. ## Where roles apply -- **User role**: Each member has a single baseline organization role (Admin, Member, Billing Manager, or a custom role). When "Assign custom roles to users" is enabled, admins can override this per user. -- **Organization default role**: When your organization has custom roles, you can set a **default role for members**. That custom role becomes the baseline for members who have the Member organization role and have not been given an explicit custom role. -- **Team roles**: Teams can have **role assignments** (one or more roles). Members of a team effectively get the union of those roles plus their own user role in the organization. See [Teams](/docs/administration/access-identity/rbac/teams#team-role-assignments) for details. +Roles apply to these kinds of principals in Pulumi Cloud: -## How permissions accumulate +- **Users**: Each organization member has exactly one organization role (Admin, Member, Billing Manager, or a custom role). +- **[Teams](/docs/administration/access-identity/rbac/teams/)**: A team can be assigned one or more roles. Members of a team receive the union of the team's roles and their own user role. +- **[Team tokens](/docs/administration/access-identity/access-tokens/#team-access-tokens)**: Machine tokens that act on behalf of a team. A team token's permissions are the union of the roles assigned to its team — they are not assigned a role directly. +- **[Organization access tokens](/docs/administration/access-identity/access-tokens/#creating-an-organization-access-token)**: Machine tokens that are assigned exactly one role defining the token's permissions across the organization. + +## How permissions accumulate for users Access in Pulumi Cloud is built up progressively. A user's effective permissions are the union of every grant that applies to them — from the broadest organizational constraints down to the most resource-specific automatic grants. -### Organization-wide settings {#organization-wide-settings} +{{% notes "info" %}} +All grants are strictly **additive**: no rule can revoke access that another rule provides. +{{% /notes %}} -The outermost layer is a set of **organization-wide access settings** at **Settings** > **Access Management**. These on/off toggles cover capabilities such as creating or deleting stacks, creating teams, and creating Insights accounts. When a setting is **enabled**, that capability is granted to all members unconditionally, regardless of their role. When a setting is **disabled**, only members whose role explicitly includes the corresponding RBAC scope retain the capability. These settings are distinct from RBAC scopes: RBAC scopes (e.g. `stack:create`, `team:create`) are granted per-role, while org-wide settings apply to everyone when enabled. +For example, a member who belongs to two teams accumulates the permissions of their own user role plus every role assigned to each of those teams: -### Team roles +```mermaid +flowchart LR + UR["User role
(e.g. Member)"] --> EFF["Effective permissions
(union of all grants)"] + TA["Team A roles"] --> EFF + TB["Team B roles"] --> EFF + CG["Creator grants
(Stack Admin on
stacks they create)"] --> EFF +``` -Members who belong to teams inherit all roles assigned to those teams, on top of their own individual role. Users in multiple teams accumulate permissions from all of them. Team roles can include tag-based (ABAC) rules that automatically apply a permission set to any resource whose tags match specified conditions, without requiring per-resource grants. +### User role -### Organization role +Every member of a Pulumi organization has a user role — a built-in role (Admin, Member, or Billing Manager) or, where enabled, a custom role assigned by an admin. An explicitly assigned custom role applies in place of the default. Members with the Member organization role who have not been assigned a custom role receive the Member role's baseline permissions, which an admin configures in [Organization-wide role settings](/docs/administration/access-identity/rbac/roles#organization-wide-role-settings). -Every member has a baseline organization role (Admin, Member, Billing Manager, or a custom role). Members with the Member organization role who have not been assigned an explicit custom role inherit the organization's default custom role, if one has been configured. +### Team roles -### Creator grants +Members who belong to teams inherit all roles assigned to those teams, on top of their own individual role. Users in multiple teams accumulate permissions from all of them. -Any user who creates a stack is automatically granted the Stack Admin permission set on that stack, regardless of their organization role or team memberships. +### Creator grants -All grants are strictly **additive**: no grant can reduce what another provides. +Any user who creates a stack is automatically granted the Stack Admin permission set on that stack, regardless of their organization role or team memberships. A stack's owner can be changed after creation from the stack's details page, under **Access** > **Settings** > **Change owner**. ## RBAC Constructs @@ -63,11 +66,9 @@ Pulumi Cloud's RBAC system is built on these core concepts: - [**Scopes**](/docs/administration/access-identity/rbac/scopes): Granular access rights that define specific actions on resources - [**Permission sets**](/docs/administration/access-identity/rbac/permission-sets): Predefined bundles of scopes that are commonly used together -- [**Roles**](/docs/administration/access-identity/rbac/roles): Collections of permission sets applied to resources and assigned to principals -- [**Teams**](/docs/administration/access-identity/rbac/teams): Groups of users that can be assigned roles +- [**Entities**](/docs/administration/access-identity/rbac/permission-sets#entities): The Pulumi Cloud objects that permission sets are granted on — stacks, environments, and insights accounts. (Pulumi uses "entity" rather than "resource" here to avoid confusion with cloud infrastructure resources.) +- [**Roles**](/docs/administration/access-identity/rbac/roles): Collections of permission sets applied to entities and assigned to principals. Entities to which a permission set applies may be explicitly selected, or may be selected via [tag-based (ABAC) rules](/docs/administration/access-identity/rbac/roles#tag-based-abac-rules). -Custom roles can also include **tag-based (ABAC) rules**: when resource tags match a rule's conditions, the role grants a chosen permission set on that resource. Details are in [Roles](/docs/administration/access-identity/rbac/roles#tag-based-abac-rules). - -### Customization +- [**Teams**](/docs/administration/access-identity/rbac/teams): Groups of users that can be assigned roles -Enterprise organizations have access to manage and create their own teams. They also can manage and create their own custom permission sets and roles, on top of the defaults available to every organization in Pulumi. +These constructs build on one another. Scopes are bundled into permission sets; a permission set applied to a set of entities forms an entity access rule; and a role combines one or more entity access rules with an organization access level. The completed role is then assigned to principals. See [Roles](/docs/administration/access-identity/rbac/roles) for a diagram of how a role is composed. diff --git a/content/docs/administration/access-identity/rbac/permission-sets.md b/content/docs/administration/access-identity/rbac/permission-sets.md index fe006b989be2..ea6156c24d27 100644 --- a/content/docs/administration/access-identity/rbac/permission-sets.md +++ b/content/docs/administration/access-identity/rbac/permission-sets.md @@ -8,7 +8,7 @@ menu: administration: name: Permission sets parent: administration-access-identity-rbac - weight: 3 + weight: 4 identifier: pulumi-cloud-access-management-rbac-permission-sets aliases: - /docs/administration/access-identity/rbac/permissions/ @@ -57,7 +57,7 @@ There are four qualified entity types in Pulumi, these are: * Integration configurations {{% notes "info" %}} -**Organization settings permission sets vs. org-wide access toggles**: The Organization settings entity type covers RBAC scopes (e.g. `stack:create`, `team:create`) that you grant through a role. These are separate from the organization-wide access toggles at **Settings** > **Access Management** (e.g. "Members can create stacks"), which apply unconditionally to all members regardless of their role. See the [RBAC overview](/docs/administration/access-identity/rbac/#organization-wide-settings) for details. +**Organization settings permission sets vs. org-wide capability toggles**: The Organization settings entity type covers RBAC scopes (e.g. `stack:create`, `team:create`) that you grant through a role. These are separate from the capability toggles in [Organization-wide role settings](/docs/administration/access-identity/rbac/roles#organization-wide-role-settings) (e.g. "Allow organization members to create stacks"), which apply to members on the Member role. {{% /notes %}} ## Default permission sets @@ -100,7 +100,7 @@ To learn more about editions visit the [pricing page](/pricing/). To create a custom permission set, you must be an organization admin. -Visit **Settings** > **Access Management** and select the **Permission sets** tab. +Visit **Settings** > **Access management** and select the **Permission sets** tab. ![View all organization permission sets](/docs/administration/access-identity/rbac/1-create-permission.png). diff --git a/content/docs/administration/access-identity/rbac/roles.md b/content/docs/administration/access-identity/rbac/roles.md index 1a2cb707339a..60613574b56b 100644 --- a/content/docs/administration/access-identity/rbac/roles.md +++ b/content/docs/administration/access-identity/rbac/roles.md @@ -8,7 +8,7 @@ menu: administration: name: Roles parent: administration-access-identity-rbac - weight: 2 + weight: 3 identifier: pulumi-cloud-access-management-rbac-roles aliases: - /docs/administration/access-identity/rbac/roles/ @@ -18,24 +18,85 @@ aliases: A role in Pulumi Cloud is the primary way to define what resources a principal (user, team, or machine token) can access and what they can do with them. Roles allow you to apply [permission sets](/docs/administration/access-identity/rbac/permission-sets) to a set of [entities](/docs/administration/access-identity/rbac/permission-sets#entities) and assign this access to a principal. -## Default roles +A role is composed of [scopes](/docs/administration/access-identity/rbac/scopes) bundled into permission sets, each applied to a set of entities to form an entity access rule, plus an organization access level for org-wide operations. The completed role is then assigned to principals. -Pulumi Cloud provides several default roles that you can use to quickly get started: +```mermaid +flowchart LR + SC["Scopes
(e.g. stack:read,
stack:write)"] --> PS["Permission sets
(bundles of scopes)"] + PS --> EAR["Entity access rule
(permission set
applied to entities)"] + ENT["Entities
(stacks, environments,
accounts)"] --> EAR + EAR --> ROLE["Role"] + ROLE --> PR["Assigned to principals
(users, teams, tokens)"] +``` -### Organization roles +## Pulumi-defined roles + +Pulumi Cloud provides several roles that you can use to quickly get started: |
Role
| Description | |------|-------------| | `Admin` | Full access to all organization resources and settings. Can manage members, roles, and organization-wide configurations. | -| `Member` | Basic access to view organization resources and participate in stack operations. Cannot modify organization settings. When your organization has custom roles, you can set an **organization default role** — a custom role that applies to all members who have the Member organization role and have not been given an explicit custom role. To set the default role, navigate to **Settings** > **Roles**, open a custom role, and choose **Set as default role**. | +| `Member` | Basic access to view organization resources and participate in stack operations. Cannot modify organization settings. The baseline permissions every member receives are configured in [Organization-wide role settings](#organization-wide-role-settings). | | `Billing Manager` | Access to view and manage billing information. Cannot modify other organization settings or resources. | +{{% notes type="info" %}} +By default, new members of a Pulumi Cloud organization will have the Member role. To can change this, click on a role and select **Actions** > **Set as organization default role**. Changing this setting will only affect new members - existing members of your Pulumi Cloud organization will not be affected. +{{% /notes %}} + +### Organization-wide role settings + +Organization-wide role settings configure the built-in **Member** role: its default access levels for stacks, environments, and accounts, plus a few org-wide capabilities. They adjust part of the Member role — the role also carries a fixed baseline of permissions that this panel doesn't expose. These settings apply only to members on the Member role who have not been given an explicit custom role; a member with an assigned custom role uses that role instead. + +Only organization admins can change these settings. To open them, navigate to **Settings** > **Access management**, select the **Roles** tab, and choose **View organization-wide role settings**. + +#### Stack permissions + +The **Stack permissions** dropdown sets the access level that members on the Member role have to all [stacks](/docs/iac/concepts/stacks/) in the organization: + +- **None** — Members have no default access to stacks. They can only access stacks granted to them through a role, team, or creator grant. +- **Read** — Members can view stacks, including their resources and state. +- **Write** — Members can view stacks and run updates on them, including `pulumi up` and `pulumi destroy`. Removing a stack itself (`pulumi stack rm`) is *not* included — that requires the `stack:delete` [scope](/docs/administration/access-identity/rbac/scopes/stacks), which is granted by the Stack Admin permission set and gated by the **Allow stack admins to delete stacks** toggle below. + +This group also includes the following capability toggles: + +- **Allow organization members to create stacks and transfer stacks to this organization** — When enabled, members on the Member role can create new stacks and transfer existing stacks into the organization. When disabled, only members whose role includes the `stack:create` scope can do so. +- **Allow stack admins to transfer stacks to another organization** — When enabled, stack admins can move stacks out of the organization. +- **Allow stack admins to delete stacks** — When enabled, stack admins can delete the stacks they administer. + +#### Environment permissions + +The **Environment permissions** dropdown sets the access level that members on the Member role have to all [environments](/docs/esc/) (Pulumi ESC): + +- **None** — Members have no default access to environments. +- **Read** — Members can view environment definitions. +- **Open** — Members can open environments, resolving and decrypting their values for use. +- **Write** — Members can create and edit environment definitions. + +#### Account permissions + +The **Account permissions** dropdown sets the access level that members on the Member role have to all [Pulumi Insights accounts](/docs/insights/): + +- **None** — Members have no default access to accounts. +- **Read** — Members can view accounts, their scan configurations, and scan results. +- **Write** — Members can update existing accounts and run and manage their scans (start, cancel, pause, and resume). Write does *not* include creating or deleting accounts: creating is governed by the **Allow organization members to create accounts** toggle below, and deleting requires **Admin**. +- **Admin** — Full control: everything **Write** allows, plus deleting accounts and managing who else can access them. + +This group also includes a capability toggle: + +- **Allow organization members to create accounts** — When enabled, members on the Member role can create new Insights accounts. When disabled, only members whose role includes the `insights_account:create` scope can do so. + +#### Team permissions + +This group includes a single capability toggle: + +- **Allow organization members to create teams** — When enabled, members on the Member role can create new [teams](/docs/administration/access-identity/rbac/teams). When disabled, only members whose role includes the `team:create` scope can do so. + ## Custom roles {{% notes "info" %}} Custom roles are only available to organizations using Pulumi Enterprise Edition and Pulumi Business Critical Edition. To learn more about editions, visit the [pricing page](/pricing/). -To assign custom roles to **individual users**, the **Assign custom roles to users** setting must be enabled for your organization (**Settings** > **Access Management**). When your organization has custom roles, you can also set an **organization default role** — a custom role that serves as the baseline for all members who have the Member organization role and have not been given an explicit custom role. The default role is set from **Settings** > **Roles** (not from the Access Management page). +The baseline permissions for members who have not been given an explicit custom role are configured in [Organization-wide role settings](#organization-wide-role-settings). {{% /notes %}} You can create and manage custom roles to define more granular access controls for your organization. Custom roles combine entity access rules (direct, global, or tag-based) with an organization access level. @@ -44,9 +105,7 @@ You can create and manage custom roles to define more granular access controls f To create a custom role, you must be an organization admin. -Visit the **Roles** page under **Settings** to see your organization roles - -![View all organization roles](/docs/administration/access-identity/rbac/1-create-role.png). +Navigate to **Settings** > **Access management** and select the **Roles** tab to see your organization's roles. To create a new role, click **Create custom role**. Provide a unique name and, optionally, a description to contextualize the role's purpose. @@ -58,16 +117,10 @@ A custom role can include any combination of the following entity access rule ty Direct rules grant a permission set to individually selected entities. Choose the entity type (stack, environment, or insights account), select **Select specific [type]**, then click **Choose [type]** to open a searchable list. -![Configuring an entity access rule for stacks](/docs/administration/access-identity/rbac/2-create-role.png). - A dialog lists the entities in your organization. You can search by name to filter the list. -![Browsing available stacks in the rule criteria dialog](/docs/administration/access-identity/rbac/3-create-role.png). - Check the entities to include in the rule, then click **Confirm selection**. -![Selecting stacks to include in the rule](/docs/administration/access-identity/rbac/4-create-role.png). - After confirming, click **Save rule**. The **Entity Access** section displays a table of all configured rules, and you can add more with **Add rule**. ##### Global entity access @@ -88,47 +141,31 @@ Tag-based rules (also called ABAC — attribute-based access control) grant a pe To configure a tag-based rule, choose the entity type and select **Set conditions**, then enter one or more tag key/value conditions and choose a permission set. -![Configuring a tag-based (ABAC) rule with entity type Stacks, tag condition sensitivity=critical, and Stack Admin permission](/docs/administration/access-identity/rbac/1-abac-rule.png). - In the Pulumi Cloud UI and API, these rules may be labeled "tag rules" or "tag-based access control rules"; ABAC (attribute-based access control) is the general industry term. **Organization access** sets the permission level for organization-level operations (e.g. creating stacks, managing billing, audit logs). This applies to the organization as a whole and is separate from the entity-based rules above. -![Entity access rules and organization access configured, ready to create the role](/docs/administration/access-identity/rbac/5-create-role.png). - When done, click **Create role**. You can now assign this role to principals in your organization. -### Managing custom roles - -To update or delete a custom role, simply click on the ellipsis icon next to the role on the Roles page. - ## Role assignment Roles can be assigned to organization access tokens, users, and teams. Effective permissions are the **union** of the user's organization role and all roles assigned to the teams they belong to (composability). ### Organization access tokens -[Organization access tokens](/docs/administration/access-identity/access-tokens/#organization-access-tokens) can be assigned one role (default or custom) that defines the token's permissions across the organization. - -Follow the process to [create an organization token](/docs/administration/access-identity/access-tokens/#creating-an-organization-access-token). - -![Create an organization access token, a role field is available](/docs/administration/access-identity/rbac/1-create-token-role.png). - -Choose a default or custom role to assign to the token. - -![Assign a role to your organization token](/docs/administration/access-identity/rbac/2-create-token-role.png). +[Organization access tokens](/docs/administration/access-identity/access-tokens/#organization-access-tokens) can be assigned exactly **one** role (default or custom) that defines the token's permissions across the organization. -The token's access is limited to the permissions of that role within your organization. +Follow the process to [create an organization token](/docs/administration/access-identity/access-tokens/#creating-an-organization-access-token), then choose a default or custom role to assign to the token. The token's access is limited to the permissions of that role within your organization. ### Users -Each organization member has one **organization role** (Admin, Member, Billing Manager, or a custom role). When your organization has custom roles and **Assign custom roles to users** is enabled (in **Settings** > **Access Management**), admins can assign any custom role to individual members. Members who have the Member organization role and have not been given an explicit custom role use the **organization default role** if one is set; otherwise they use the built-in Member role. +Each organization member has exactly **one** organization role (Admin, Member, Billing Manager, or a custom role). When your organization has custom roles enabled, admins can replace a member's role with any custom role. Members who have the Member organization role and have not been given an explicit custom role receive the baseline permissions defined in [Organization-wide role settings](#organization-wide-role-settings). ### Teams -When your organization has custom roles enabled, [teams can have role assignments](/docs/administration/access-identity/rbac/teams#team-role-assignments): one or more roles (default or custom). Team members receive the **union** of their own user role and all roles assigned to the teams they belong to. So team role assignments add on top of each member's baseline role. +When your organization has custom roles enabled, [teams can have role assignments](/docs/administration/access-identity/rbac/teams#team-role-assignments): **one or more** roles (default or custom). Team members receive the **union** of their own user role and all roles assigned to the teams they belong to. So team role assignments add on top of each member's baseline role. ## Best practices diff --git a/content/docs/administration/access-identity/rbac/scopes.md b/content/docs/administration/access-identity/rbac/scopes.md index 833dae411c0e..94b2729491fc 100644 --- a/content/docs/administration/access-identity/rbac/scopes.md +++ b/content/docs/administration/access-identity/rbac/scopes.md @@ -7,7 +7,7 @@ meta_image: /images/docs/meta-images/docs-meta.png menu: administration: parent: administration-access-identity-rbac - weight: 4 + weight: 5 identifier: administration-access-identity-rbac-scopes aliases: - /docs/intro/pulumi-service/scopes/ @@ -17,10 +17,6 @@ aliases: Scopes are the most granular level of access control in Pulumi Cloud's RBAC system. Each scope represents a specific action that can be performed on a resource, such as reading stack configurations or updating environment settings. Scopes are the building blocks of [permission sets](/docs/administration/access-identity/rbac/permission-sets), which are then bundled into [roles](/docs/administration/access-identity/rbac/roles) to create comprehensive access control configurations. -## Scopes vs. organization-wide settings - -Scopes are distinct from the **organization-wide access settings** found at **Settings** > **Access Management** (e.g., "Members can create stacks," "Members can delete stacks," "Members can create teams"). Those are separate on/off toggles that are not part of the RBAC scope system. When an org-wide setting is enabled, that capability is granted to all members unconditionally regardless of their role. When it is disabled, only members whose role includes the corresponding scope retain the capability. See the [RBAC overview](/docs/administration/access-identity/rbac/#organization-wide-settings) for a full explanation of how these two systems interact. - ## How Scopes Work Scopes follow a consistent naming pattern: `object:action`. For example: diff --git a/content/docs/administration/access-identity/rbac/teams.md b/content/docs/administration/access-identity/rbac/teams.md index f0f8ab17da81..d5b38d5e6bb6 100644 --- a/content/docs/administration/access-identity/rbac/teams.md +++ b/content/docs/administration/access-identity/rbac/teams.md @@ -8,7 +8,7 @@ menu: administration: name: Teams parent: administration-access-identity-rbac - weight: 1 + weight: 2 identifier: pulumi-cloud-access-management-rbac-teams aliases: - /docs/administration/access-identity/rbac/teams/ @@ -28,7 +28,7 @@ The Pulumi Cloud offers role-based access control (RBAC) using teams. Teams allo By default, all organization admins can create new teams. {{% notes "info" %}} -To allow all organization members to create teams, navigate to **Settings** > **Access Management** and enable the **Allow organization members to create teams** toggle. +To allow all organization members to create teams, enable the **Allow organization members to create teams** toggle in [Organization-wide role settings](/docs/administration/access-identity/rbac/roles#organization-wide-role-settings). {{% /notes %}} To create a team: