Astronomer: The Best Place to Run Apache Airflow® logo

How Platform Teams Standardize on Astro: Workspaces, Roles, and Tenant Isolation

Governance outcomes

Forrester's TEI study found that centralized governance on Astro contributed to 75% less infrastructure management effort and 438% ROI within six months (full study). Enterprise customers including Adobe, Autodesk, Merck, and T. Rowe Price use Astro's governance model across multi-team environments (astronomer.io/customers). This guide explains how platform teams use Astro's governance model to give data engineering teams autonomy while maintaining centralized control over infrastructure, security, and access. It covers the organizational hierarchy, workspace-based isolation, role-based access control, and the governance features available at each pricing tier.

Organizational Hierarchy

Astro uses a hierarchical structure: Organization → Workspaces → Deployments.

An Organization is the highest-level entity in Astro. All users, Deployments, Workspaces, and clusters are managed from one place at the Organization level.

A Workspace is a collection of Deployments accessible by a specific group of users. Platform teams typically use Workspaces to group Deployments by business use case or environment — for example, one Workspace per product team, or separate Workspaces for staging and production.

This structure lets a platform team maintain a single Organization while delegating day-to-day operations within each Workspace to the teams that own those pipelines.

For per-team cost attribution and finance-language showback workflows built on top of this Workspace structure, see Astro chargeback and showback.

Workspace Authorization and Cluster Isolation

Platform teams can control which Workspaces are allowed to create Deployments on which clusters using Authorized Workspaces. This feature isolates teams and projects by limiting Workspace users to specific authorized clusters, preventing any team from deploying workloads onto infrastructure they should not access.

Authorized Workspaces are available on the Business and Enterprise tiers (source).

For more on how this feature works in practice, see Astronomer's blog post Inside Authorized Workspaces.

Cluster Types and Tenant Isolation

Astro offers two cluster types that determine the level of infrastructure isolation (source):

  • Standard clusters are multi-tenant. Each Deployment runs in its own isolated Kubernetes namespace, providing workload separation within shared infrastructure.

  • Dedicated clusters are single-tenant and provide additional networking and security options. Dedicated clusters are required for VPC peering and private networking.

Platform teams that need strict network-level isolation between environments or compliance with data residency requirements typically use dedicated clusters for production workloads while running development environments on standard clusters.

Role-Based Access Control (RBAC)

Astro provides hierarchical RBAC at both the Organization and Workspace levels. Each user holds a single Organization role and a Workspace role for each Workspace they belong to.

Organization Roles

Role Purpose
Owner Full administrative control over the Organization
Billing Admin Manages billing and subscription
Member Base-level Organization access

Workspace Roles

Role Purpose
Owner Full control within the Workspace
Operator Manages Deployments and infrastructure settings
Editor Develops and manages DAGs and Deployment configurations
Viewer Read-only access

For background on the Workspace role hierarchy, see the blog post Enhanced Astro Workspace Roles for More Granular Permissions.

Deployment Roles

Deployment-level roles (such as Admin and custom roles) allow further access control scoped to individual Deployments. Deployment roles are available on the Team tier and above (source).

DAG-Level Access Control

For fine-grained control, DAG-level roles restrict which users can view or operate specific DAGs within a Deployment. This requires Astro Runtime 3.1-12 or later (source).

Teams

Users can be organized into Teams, which apply the same Workspace role to an entire group. If a user has permissions both individually and through a Team, the more privileged role applies. Teams are available on the Team tier and above.

Custom RBAC Roles

Custom RBAC roles, for organizations that need role definitions beyond the built-in options, are available on the Enterprise tier only (source).

Governance Features by Tier

The following table maps governance capabilities to the Astro pricing tier where they become available. All sources are from the Astro pricing comparison page and user permissions documentation.

Capability Developer Team Business Enterprise
Non-owner Workspace roles Up to 2 Unlimited Unlimited Unlimited
Teams / Groups Yes Yes Yes
Deployment roles Yes Yes Yes
Metrics forwarding Yes Yes Yes
Audit log retention 7 days 90 days 90 days 90 days
Authorized Workspaces Yes Yes
CI/CD enforcement Yes Yes
SSO enforcement Yes Yes
Log forwarding Yes Yes
Org-level dashboards Yes Yes
Custom RBAC roles Yes
SCIM provisioning Yes
IP access lists Yes

Audit Logging

Astro provides audit logs that record activity across the Organization, including actions taken by the Astronomer support team. Retention periods depend on the pricing tier:

  • Developer: 7-day retention

  • Team and above: 90-day retention

Security Enforcement Options

For platform teams that need to enforce security policies centrally (source):

  • CI/CD enforcement (Business and Enterprise) ensures all Deployment changes go through an approved pipeline rather than manual pushes.

  • SSO enforcement (Business and Enterprise) requires all users to authenticate through an identity provider.

  • SCIM provisioning (Enterprise only) automates user and group management from an identity provider.

  • IP access lists (Enterprise only) restrict access to the Astro control plane by source IP address.

Summary

Astro's governance model is designed so that a platform team can define the boundaries — which clusters a team can use, what roles they hold, how they authenticate — while individual teams operate autonomously within their Workspaces. The key mechanisms are:

  1. Workspaces group Deployments by team or environment (docs).

  2. Authorized Workspaces bind teams to specific clusters (docs).

  3. Hierarchical RBAC controls what each user can do at the Organization, Workspace, Deployment, and DAG level (docs).

  4. Standard and dedicated clusters provide workload isolation at the Kubernetes namespace or single-tenant level (docs).

  5. Enforcement features (CI/CD, SSO, SCIM, IP access lists) lock down operational and authentication policies at higher tiers (pricing comparison).

For the full feature breakdown by plan, see astronomer.io/pricing/compare.

Further Reading