Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancing the permissions page #6869

Open
wants to merge 11 commits into
base: current
Choose a base branch
from
221 changes: 219 additions & 2 deletions website/docs/docs/cloud/manage-access/enterprise-permissions.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,9 +16,226 @@ help manage access controls within a dbt Cloud account. See the docs on [access
control](/docs/cloud/manage-access/about-user-access) for more information on Role-Based access
control (RBAC).

## Roles and permissions

The following roles and permission sets are available for assignment in dbt Cloud Enterprise accounts. They can be granted to dbt Cloud groups which are then in turn granted to users. A dbt Cloud group can be associated with more than one role and permission set. Roles with more access take precedence.
## Permission sets

The following permission sets are available for assignment in dbt Cloud Enterprise accounts. They can be granted to dbt Cloud groups which are then in turn granted to users. A dbt Cloud group can be associated with more than one permission set. Permissions assignments with more access take precedence.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The following permission sets are available for assignment in dbt Cloud Enterprise accounts. They can be granted to dbt Cloud groups which are then in turn granted to users. A dbt Cloud group can be associated with more than one permission set. Permissions assignments with more access take precedence.
The following permission sets are available for assignment in dbt Cloud Enterprise accounts. They can be granted to dbt Cloud groups which are then, granted to users. A dbt Cloud group can be associated with more than one permission set. Permissions assignments with more access take precedence.


Access to dbt Cloud features and functionality is split into `account-level` and `project-level` permission sets. Account-level permissions are primarily for account administration (inviting users, configuring SSO, and creating groups). Project-level permissions are for the configuration and maintenance of the projects themselves (configuring environments, accessing IDE, and running jobs). Account permission sets may have access to project features, and project permission sets may have access to account features. Check out the [permissions tables](/docs/cloud/manage-access/enterprise-permissions#account-roles) to compare sets and their access.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hiya @matthewshaver

The link didn't take me to a page for the permissions table. The link you used looks find so I'm not sure of it's just me.

Kind Regards

<Expandable alt_header="Account admin">

The Account admin permission set is the highest level of access and control over your dbt Cloud account and projects. We recommend limiting the number of users and groups assigned the account admin permission set.

Notable features:
- Account admin is an account-level set.
- Unrestricted access to every feature.
- The default permissions for every user who creates a new dbt Cloud account.
- The default permissions assigned to the `Owner` group.

</Expandable>
<Expandable alt_header="Admin">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how much is this feedback about the content and how much is about the naming. bc i think it's confusing that there's account admin and admin :( can those be differentiated or is that out of scope?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm listing the permissions as they appear in the product. If we want to get them renamed there (which I agree with) we should give the feedback to the enterprise team through their channels


The Admin permission set is intended for project administration but with limited account-level access to invite and assign users.

Notable features:
- Admin is a project-level set.
- Unrestricted access to existing projects, but can't create new projects.
- Can invite new members and assign access but can't create groups.
- Can access dbt Explorer.

</Expandable>
<Expandable alt_header="Analyst">

The Analyst permission set is designed for users who need to run and analyze dbt models in the IDE but can't create or edit anything outside the IDE.

Notable features:
- Analyst is a project-level set.
- Full access to the IDE and the ability to configure personal credentials for adapters and Git.
- Read-only access to environment configs.
- Can view jobs but can't edit them.
- Can access dbt Explorer.

</Expandable>
<Expandable alt_header="Billing admin">

The Billing admin permission set can review product usage information that impacts the final billing of dbt Cloud (for example, models run).

Notable features:
- Billing admin is an account-level set.
- Unrestricted access to the **Billing** section of your **Account settings**.
- Read access to public models.
- No other access.

</Expandable>
<Expandable alt_header="Database admin">

Database admins manage the connections and configurations between dbt Cloud and the underlying databases.

Notable features:
- Database admin is a project-level set.
- Can set up and maintain database connections, environment variables, and Semantic Layer configs.
- Helpful for scenarios where your data warehouse admins only need access to dbt Cloud to configure connections.
- Read-only access to Git repo, job, and run settings.
- Can access dbt Explorer.

</Expandable>
<Expandable alt_header="Developer">

The Developer permission set is intended for users who build and maintain dbt models under development and manage production behavior. This is the primary permission set for users working in the IDE and should not be conflated with the [Developer license](/docs/cloud/manage-access/seats-and-users#licenses).

Notable features:
- Developer is a project-level set.
- Can create, edit, and test dbt code in the IDE.
- Read-only access to the underlying configs for environments, jobs, runs, and Git.
- Users manage their credentials to data warehouses and Git.
- Can access dbt Explorer.

</Expandable>
<Expandable alt_header="Git admin">

Git admins manage Git repository integrations and cloning.

Notable features:
- Git admin is a project-level set.
- Can create new Git integrations and environment variables.
- Can edit project settings.
- Read-only access to account settings (including users and groups).
- No access to the IDE.
- Can access dbt Explorer.

</Expandable>
<Expandable alt_header="Job admin">
Job admin is an administrative permission set for users who create, run, and manage jobs in dbt Cloud.

Notable features:
- Job admin is a project-level set.
- Job admins can create and edit jobs, runs, environment variables, and data warehouse configs.
- Read-only access to project configs.
- Read-only access to connections and public models.
- Can access dbt Explorer.

</Expandable>
<Expandable alt_header="Job runner">

Job runner is a specialized permission set for users who need access to run jobs and view the outcomes.

Notable features:
- Job runner is a project-level set.
- Can run jobs.
- Has read-only access to jobs, including status and results.
- No other access to dbt Cloud features.

</Expandable>
<Expandable alt_header="Job viewer">

Job viewer enables users to monitor and review job executions within dbt Cloud. Users with this role can see jobs’ status, logs, and outcomes but cannot initiate or modify them.

Notable features:
- Job viewer is a project-level set.
- Can run jobs.
- Read-only access to job results, status, and logs.
- No other access to dbt Cloud features.
- Can access dbt Explorer.

</Expandable>

<Expandable alt_header="Manage marketplace apps">
Manage marketplace apps is a specialized permission set associated with dbt Cloud marketplace apps. Usually implemented for the Snowflake Native App.

Notable features:
- Manage marketplace apps is an account-level set.
- Used exclusively for marketplace app integrations.
- Not intended for general user/group assignment.

</Expandable>
<Expandable alt_header="Metadata (Discovery API only)">

Metadata is intended to be a read-only [Discovery API](/docs/dbt-cloud-apis/discovery-api) integration permission set.

Notable features:
- Metadata is a project-level set.
- Grants read-only access to metadata related to dbt models, runs, sources, and tests.
- No access to modify, execute, or manage dbt jobs, repositories, or users.
- No other access to dbt Cloud features.

</Expandable>
<Expandable alt_header="Project creator">

The Project creator permission set can create, configure, and set up new projects. It is recommended for the admin of teams that will own a project.

Notable features:
- Project creator is an account-level set.
- Only permission set other than Account admin that can create projects.
- Limited account settings access, including creating and editing connections, inviting users, creating groups, and assigning licenses.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Limited account settings access, including creating and editing connections, inviting users, creating groups, and assigning licenses.
- Limited account settings access &mdash; the project creator can create and edit connections, invite users, create groups, and assign licenses.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hiya @matthewshaver

This is a non blocker but I amended this slightly as initially the sentence confused me a little. I read it as they weren't able to create, edit...projects.

Kind Regards
Natalie

- Unrestricted access to project configurations.
- Can access dbt Explorer

</Expandable>
<Expandable alt_header="Security admin">

Security admins have limited access to the security settings and policies for the dbt Cloud account. This is intended for members of a security team who need to ensure compliance with security standards and oversee the implementation of best security practices across the account. This permission set is frequently paired with the [IT license-type](/docs/cloud/manage-access/seats-and-users#licenses).

Notable features:
- Security admin is an account-level set.
- Can create and edit users and groups and assign licenses.
- Can create and edit authentication and SSO settings.
- Can create and edit IP restrictions and service tokens and manage user access controls.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Can create and edit IP restrictions and service tokens and manage user access controls.
- Can create and edit IP restrictions and service tokens, as well as manage user access controls.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hiya @matthewshaver

I've amended this sentence a little to remove the repetition of "and".

Kind Regards
Natalie

- No access to jobs, runs, environments, or the IDE.

</Expandable>
<Expandable alt_header="Semantic Layer">

A specialized permission set with strict access to only the Semantic Layer configuration (credentials and service tokens) for projects.

Notable features:
- Semantic Layer is a project-level set.
- Can only access Semantic Layer configs.
- No other access to dbt Cloud features.

</Expandable>
<Expandable alt_header="Stakeholder">
matthewshaver marked this conversation as resolved.
Show resolved Hide resolved

Stakeholder is a read-only permission set, similar to viewer, but without access to sensitive content such as account settings or billing information. Useful for personas who need to monitor projects and their configurations.

Notable features:
- Stakeholder is a project-level set.
- Read-only access to projects, environments, jobs, and runs.
- Read-only access to user and group information.
- No access to the IDE.
- Can access dbt Explorer.

</Expandable>
<Expandable alt_header="Team admin">
Team admin is an administrative permission set intended for team leaders or similar personas. The permissions grants the ability to manage projects for the team.

Notable features:
- Team admin is a project-level set.
- Access to manage the project(s) for a team of users. Limited scope and access can be extended via environment permissions.
- Read-only access to many account settings (excluding sensitive content like billing and auth providers).
- Can access dbt Explorer.

</Expandable>
<Expandable alt_header="Viewer">
The Account Viewer permissions set provides read-only access to the dbt Cloud account. Useful for any persona who needs insights into your dbt Cloud account without access to create or change configurations.

Notable features:
- Viewer is an account-level set.
- Read-only access to all settings, projects, environments, and runs.
- No access to the IDE.
- Can access dbt Explorer

</Expandable>
<Expandable alt_header="Webhook">

The Webhook permissions set manages webhooks in the dbt Cloud.

Notable features:
- Webhooks is a project-level set.
- Create, edit, and manage webhooks.
- No other access to dbt Cloud features.

</Expandable>

:::tip Licenses or Permission sets

Expand Down
31 changes: 16 additions & 15 deletions website/snippets/_enterprise-permissions-table.md
Original file line number Diff line number Diff line change
@@ -1,18 +1,19 @@

Permissions:

* Account-level permissions &mdash; Permissions related to the management of the dbt Cloud account. For example, billing and account settings.
* Project-level permissions &mdash; Permissions related to the projects in dbt Cloud. For example, repos and access to the dbt Cloud IDE or dbt Cloud CLI.
* **Account-level permissions** &mdash; Permissions related to the management of the dbt Cloud account. For example, billing and account settings.
* **Project-level permissions** &mdash; Permissions related to the projects in dbt Cloud. For example, repos and access to the dbt Cloud IDE or dbt Cloud CLI.

### Account roles
Account roles enable you to manage the dbt Cloud account and manage the account settings (for example, generating service tokens, inviting users, and configuring SSO). They also provide project-level permissions. The **Account Admin** role is the highest level of access you can assign.
### Account permissions

Account permission sets enable you to manage the dbt Cloud account and manage the account settings (for example, generating service tokens, inviting users, and configuring SSO). They also provide project-level permissions. The **Account Admin** permission set is the highest level of access you can assign.

Key:

* (W)rite &mdash; Create new or modify existing. Includes `send`, `create`, `delete`, `allocate`, `modify`, and `develop`.
* (R)ead &mdash; Can view but can not create or change any fields.
* **(W)rite** &mdash; Create new or modify existing. Includes `send`, `create`, `delete`, `allocate`, `modify`, and `develop`.
* **(R)ead** &mdash; Can view but can not create or change any fields.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* **(R)ead** &mdash; Can view but can not create or change any fields.
* **(R)ead** &mdash; Can view but cannot create or change any fields.


#### Account permissions for account roles
#### Account access for account permissions

<SortableTable>

Expand All @@ -38,10 +39,10 @@ Key:

</SortableTable>

\* Roles with write (**W**) access to Account settings can modify account-level settings, including [setting up Slack notifications](/docs/deploy/job-notifications#slack-notifications).
\* Permission sets with write (**W**) access to Account settings can modify account-level settings, including [setting up Slack notifications](/docs/deploy/job-notifications#slack-notifications).
matthewshaver marked this conversation as resolved.
Show resolved Hide resolved


#### Project permissions for account roles
#### Project access for account permissions

<SortableTable>

Expand All @@ -64,16 +65,16 @@ Key:

</SortableTable>

### Project role permissions
### Project permissions

The project roles enable you to work within the projects in various capacities. They primarily provide access to project-level permissions such as repos and the IDE or dbt Cloud CLI, but may also provide some account-level permissions.
The project permission sets enable you to work within the projects in various capacities. They primarily provide access to project-level permissions such as repos and the IDE or dbt Cloud CLI, but may also provide some account-level permissions.

Key:

* (W)rite &mdash; Create new or modify existing. Includes `send`, `create`, `delete`, `allocate`, `modify`, and `develop`.
* (R)ead &mdash; Can view but can not create or change any fields.
* **(W)rite** &mdash; Create new or modify existing. Includes `send`, `create`, `delete`, `allocate`, `modify`, and `develop`.
* **(R)ead** &mdash; Can view but can not create or change any fields.

#### Account permissions for project roles
#### Account access for project permissions

<SortableTable>

Expand All @@ -96,7 +97,7 @@ Key:

</SortableTable>

#### Project permissions for project roles
#### Project access for project permissions

<SortableTable>

Expand Down
Loading