This guide is applicable to Dagster Cloud.
Users in Dagster Cloud can be granted specific permissions what they can and cannot do in your organization. Granularly assigning permissions to users ensures that the right people have appropriate access to what they require in Dagster Cloud, and no more.
In this guide, we'll cover the available user roles, how permissions are assigned, and how to add and remove users in your organization.
Dagster Cloud supports five user roles for several levels of role-based access control:
Role | Plan | Description |
---|---|---|
Viewer | Enterprise | The least permissive role. Grants view access to most things in a deployment, with some exceptions. Refer to the User role permissions tab for more info. |
Launcher | Enterprise | Includes all Viewer permissions and the ability to launch and terminate runs. |
Editor | All plans | Includes all Launcher permissions and the ability to:
|
Admin | All plans | Includes all Editor permissions and the ability to:
|
Organization Admin | All plans | The most permissive role. Includes all Admin permissions and the ability to:
|
Click the User role permissions tab to view all granular permissions for each user role.
All user roles are enforced both in Dagster Cloud and the GraphQL API. With the exception of the Organization Admin role, user roles are set on a per-deployment basis. Organization Admins have access to the entire organization, including all full deployments, code locations, and Branch Deployments.
All Dagster Cloud accounts - Enterprise plan or not - can set permissions at the deployment level. When defined, the selected user role will be used as the default for all code locations contained in the deployment.
For example, if a user is assigned the Editor user role for a deployment, they'll also be an Editor for all code locations in the deployment:
For Dagster Cloud Enterprise users, default user roles can be overridden at the code location level. For non-Enterprise users, the user will have the same level of access for all code locations in the deployment.
Note: Having access to a deployment doesn't automatically grant access to Branch Deployments. Branch deployment permissions must be granted separately.
Code location permissions are a Dagster Cloud Enterprise feature.
Dagster Cloud Enterprise users can override the deployment-level user role by setting permissions at the code location level. Overrides can only be performed if:
For example, if a user is assigned the Viewer user role for a deployment, only a more permissive role can be assigned for a code location in the deployment. Specifically, an Editor or Launcher user role:
If a user is an Organization Admin or a deployment-level Admin or Editor, they already have the most permissive user role possible for the code location. In this case, an override is unnecessary and the Edit user role button next to the code location will be disabled:
To remove an override, click Edit user role next to the code location to open the user role selection dialog. Then, click the Remove override button:
Granting access to Branch Deployments gives users access to all Branch Deployments for all the code locations they have access to. Consider the following example:
In this case, the user would have Editor access to Branch Deployments for all code locations in the prod
deployment, but not in staging
. This is because they're a Viewer for the code locations in the prod
deployment, but they don't have access to the staging
deployment or any of its code locations.
Organization Admin or Admin permissions are required to add users in Dagster Cloud.
Before you start, note that:
If using Google for SSO, users must be added in Dagster Cloud before they can log in.
If using a SAML-based solution like Okta, users must be assigned to the Dagster app in the SSO portal to log in. By default, users will be granted Viewer permissions on each deployment. The default role can be adjusted by modifying the sso_default_role
deployment setting.
Organization Admin permissions are required to remove users in Dagster Cloud.
Removing a user removes them from the organization. Note: If using a SAML-based SSO solution like Okta, you'll also need to remove the user from the Identity Provider (IdP). Removing the user in Dagster Cloud doesn't remove them from the IdP.