Astro user permissions reference
To better protect your data pipelines and cloud infrastructure, Astro provides role based access control (RBAC) for Organizations and Workspaces. Each Astro user has a Workspace role in each Workspace they belong to, plus a single Organization role. Users can also belong to Teams, which apply the same Workspace role to a group of users. Role based access control is not available for Deployments.
You can also apply roles to API tokens to limit the scope of their actions in CI/CD and automation pipelines. See Manage Deployments as code.
Astro has hierarchical RBAC. Within a given Workspace or Organization, senior roles have their own permissions in addition to the permissions granted to lower roles. For example, a user or API token with Organization Owner permissions inherits Organization Billing Admin and Organization Member permissions because those roles are lower in the hierarchy.
The Astro role hierarchies in order of inheritance are:
- Organization Owner > Organization Billing Admin > Organization Member
- Workspace Owner > Workspace Operator > Workspace Author > Workspace Member > Workspace Accessor (Public Preview)
Additionally, Organization Owners inherit Workspace Owner permissions for all Workspaces in the Organization.
Organization roles
An Organization role grants a user or API token some level of access to an Astro Organization. The Organization Owner role include access to all of the Workspaces within that Organization. All users have at least an Organization Member role regardless of whether they belong to a Workspace, however, an API token's access is based on the scope you define for it. For example, you must give an API token an organization owner role to perform Organization-level actions or to access the list of all Workspaces in the Organization.
The following table lists the available Organization roles:
| Permission | Organization Member | Organization Billing Admin | Organization Owner |
|---|---|---|---|
| View Organization details and user membership | ✔️ | ✔️ | ✔️ |
| View lineage metadata in the Lineage tab | ✔️ | ✔️ | ✔️ |
| View clusters | ✔️ | ✔️ | ✔️ |
| Update Organization billing information and settings | ✔️ | ✔️ | |
| View usage for all Workspaces in the Usage tab | ✔️ | ✔️ | |
| View Organization-level metrics dashboards on the Dashboards page | ✔️ | ✔️ | |
| Create, update, and delete Data Products | ✔️ | ✔️ | |
| Create, update, and delete Data Product SLAs | ✔️ | ✔️ | |
| Create, update, and delete clusters | ✔️ | ||
| Create a new Workspace | ✔️ | ||
| Workspace Owner permissions to all Workspaces | ✔️ | ||
| Update roles and permissions of existing Organization users | ✔️ | ||
| Invite a new user to an Organization | ✔️ | ||
| Remove a user from an Organization | ✔️ | ||
| Create, update, and delete Organization API tokens | ✔️ | ||
| Access, regenerate, and delete single sign-on (SSO) bypass links | ✔️ | ||
| Create, update, and delete a Team | ✔️ | ||
| Configure environment secrets fetching | ✔️ | ||
| Configure IP access | ✔️ |
To manage users in an Organization, see Manage Organization users. To manage the Organization permissions of your API tokens, see Organization API tokens.
Workspace roles
A Workspace role grants a user or API token some level of access to a specific Workspace. If a user or API token has some level of access to a Workspace, that access applies to all Deployments in the Workspace.
- A Workspace Accessor has the fewest permissions in a Workspace. A Workspace Accessor can only see basic information about the Workspace in which they have the role. They can only be granted further permissions through a Deployment role. If you grant a user a Deployment role without first assigning them a Workspace role, they'll automatically be granted the Workspace Accessor role for the Workspace. For more information, see Customize Deployment roles.
- A Workspace Member can view the most basic details about Deployments, DAGs, tasks, logs, and alerts. Give a user this role if they need to be able to monitor a DAG run or view Deployment health, but they shouldn't make any changes to a Deployment themselves.
- A Workspace Author has all of the same permissions as a Workspace Member, plus the ability to update DAG code and run DAGs in the Airflow UI, plus limited permissions to configure Deployment-level observability features such as Astro alerts. Give a user this role if they are primarily DAG developers and don't need to manage the environments their DAGs run in.
- A Workspace Operator has all the same permissions as a Workspace Author, plus the ability to manage Deployment-level configurations, such as environment variables. Give a user this role if they need to manage the environments that DAGs run in.
- A Workspace Owner has all the same permissions as a Workspace Operator, plus the ability to manage user membership in the Workspace. Give a user this role if they need to administrate membership to the Workspace.
To manage a user's Workspace permissions, see Manage Workspace users.
Deployment roles
There are two types of Deployment roles: the default Deployment Admin role and custom Deployment roles.
Deployment Admin roles have the same permissions as the Workspace Operator role but only Deployment-level operations in a specific Deployment. For example, a Deployment Admin can create a Deployment environment variable but, unlike a Workspace Operator, they can't create an Astro alert because alerts are configured at the Workspace level.
A custom Deployment role is a role that your Organization has configured to have specific Deployment-level permissions. For a complete list of available custom Deployment role permissions, see Deployment role reference.
Permissions reference
The following table lists the specific permissions that a Deployment Admin role and each Workspace role has:
| Permission | Workspace Member | Workspace Author | Workspace Operator | Deployment Admin | Workspace Owner |
|---|---|---|---|---|---|
| View Deployment and Workspace users and teams | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| View all Deployments in the Astro UI | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| View DAGs in the Airflow UI | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| View Airflow task logs | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| View Airflow datasets | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Create and delete Airflow datasets | ✔️ | ✔️ | ✔️ | ✔️ | |
| View Astro Cloud IDE projects | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| View Astro alerts | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| View the Cluster Activity tab in the Airflow UI | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Use custom plugins from the Airflow UI menu | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Manually trigger DAG and task runs | ✔️ | ✔️ | ✔️ | ✔️ | |
| Pause or unpause a DAG | ✔️ | ✔️ | ✔️ | ✔️ | |
| Clear/mark a task run or DAG run | ✔️ | ✔️ | ✔️ | ✔️ | |
| Push code to Deployments or Astro Cloud IDE projects | ✔️ | ✔️ | ✔️ | ✔️ | |
| Create, update, and delete Astro Cloud IDE projects | ✔️ | ✔️ | ✔️ | ✔️ | |
| Create, update, and delete Astro alerts | ✔️ | ✔️ | ✔️ | ||
| View Airflow connections, variables, plugins, providers, pools, and XComs that were created in the Airflow UI | ✔️ | ✔️ | ✔️ | ✔️ | |
| Create, update, and delete Airflow connections, variables, plugins, providers, pools, and XComs | ✔️ | ✔️ | ✔️ | ||
| Create, update, delete, and assign connections to Deployments in the Astro Environment Manager | ✔️ | ✔️ | |||
| Update Deployment configurations | ✔️ | ✔️ | ✔️ | ||
| Create and delete Deployments | ✔️ | ✔️ | ✔️ | ||
| Create, update, and delete Deployment environment variables | ✔️ | ✔️ | ✔️ | ||
| Create, update, and delete Workspace API tokens | ✔️ | ||||
| Create, delete, pause, and unpause hiberation schedules. | ✔️ | ✔️ | ✔️ | ||
| Create, update, and delete Deployment API tokens | ✔️ | ✔️ | |||
| Update user roles and permissions | ✔️ | ||||
| Invite users to a Workspace | ✔️ | ||||
| Assign Teams to or remove from Workspaces | ✔️ |
Relationship between user roles and Team roles
There are two ways to define a user's role in a Workspace:
- Define the individual user role when you add a user to a Workspace.
- Assign a Workspace role to a Team and add the user to the Team.
If a user has permissions to a Workspace both as an individual and as a member of a Team, then Astronomer recognizes the more privileged role.
For example, if a user belongs to a Workspace as a Workspace Member, but also belongs to a Team in the Workspace with Workspace Owner privileges, then the user has Workspace Owner privileges in the Workspace.