Enhanced Astro Workspace Roles for more granular permissions

Security and data protection are at the forefront of every administrator’s mind, while ensuring usability and a great user experience are still respected. The balance of the two priorities is not only critical in delivering Astro to our users, but also increasingly important and difficult as the demands for safeguarding organizations from cybercrime, unauthorized access and data breaches continue to expand.

In this blog post, we will dive into the details of the Astro’s Role-Based Access Control (RBAC) and new Workspace Role updates, and explore improvements to popular use cases of Astro.

Astro’s RBAC Model

Astro offers a set of roles with defined permissions across two entities in the product — Organization and Workspaces. The Astro Organization is a collection of your entire Astro estate including users, workspaces, and deployments. Every user within an Organization has a specific Organization role that specifies what they are allowed to do. Along with users, Organization API Tokens and Teams can also be assigned an Organization role.

Similarly, a user may belong to one or more Astro Workspaces. Every user added to a Workspace is assigned a Workspace role, that specifies what they are allowed to do in that Workspace. In addition to users, both Organization and Workspace API Tokens and Teams can also be assigned a Workspace role.

Another key aspect of Astro’s RBAC is that it is hierarchical. The most privileged roles in the Organization and Workspace entities inherit the permissions of the lesser privileged roles. The most privileged Organization role also inherits all the permissions to all Workspaces. Lastly, 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.

Revisiting Workspace Roles

Since the launch of Astro, we received considerable feedback about the challenges customers were facing with the existing set of Workspace roles, and it became apparent we had to improve this experience as part of delivering a modern data orchestration solution. The feedback revolved around two main issues:

1. Lack of Airflow permissions for non-Workspace Admins
2. Missing role for the data engineer persona

We went back to the drawing board to better understand the appropriate mix of permissions for existing roles and how to best serve the data engineer persona with an appropriate role, with an ultimate goal of making it easier and more secure to develop, manage, and support data pipelines and deployments at scale.

Ultimately, the major enhancements include expanded Airflow permissions for the Workspace Operator, previously Editor, and a new Workspace Author role for the unique and specific needs of the data engineer using Astro. Check out the table and the end of the blog for a detailed breakdown of Workspace roles and associated permissions.

Improved User Experience

Beyond the two main issues shared above, we learned of specific use cases and challenges that were suffering as a result of previous Workspace roles.

• Over or Under Privileged Users: Organizations with stringent security practices and requirements had to make the tradeoff between granting less or more permissions to users then required for their duties. This led to either a poor user experience and need to use break glass procedures or increased risk to issues or unauthorized actions.
  
  With this update, we have either greatly reduced or completely addressed this issue across our Astro customer base by providing only the necessary access for the various user personas on Astro.
• Improved Alignment to Airflow OSS Roles: Organizations migrating over from OSS, MWAA or Cloud Composer were forced to adjust their processes and Airflow user management procedures due to the differences in Workspace roles and associated Airflow permissions, ultimately leading to increased confusion and slower adoption.
  
  The introduction of the new role and revised mapping of Airflow permissions align to customer expectations during migrations and further removes friction in adopting and scaling on Astro.
• Securing DAG Automation: Teams leveraging Workspace API Tokens to automate repetitive, break-fix tasks, or perform cross DAG operations such as retrying a task or triggering a DAG were forced to over privilege their API Token.
  
  This led to greater risk in unauthorized access and incidents as those tokens had full CRUD access to the entire deployment. The Workspace Author role strikes the right balance between DAG and Task management capabilities without exposing the entire deployment to unintentional and destructive operations.

The Nitty Gritty Details

The table below breaks down the new Workspace roles and associated permissions. The asterisk represents new capabilities.