Skip to main content
This page lists the default permissions for each user role on Astro Private Cloud. To modify these default permissions, see Customize role permissions.

​
Config governance permissions

Astro Private Cloud 2.0 adds permissions for config governance on the deployments object, which covers cluster, Workspace, and Deployment overrides. The APC API checks these permission strings, not the UI label, when you call the GraphQL API. Workspace-scoped users need both a Workspace role and the matching Deployment role to act in a specific Deployment. The system.* permissions apply when a user operates across Workspaces or Deployments from a system role binding, such as a System Admin. Cluster-level data plane overrides use the updateCluster mutation and the cluster.config.* and system.clusters.update permissions, not the workspace.* or deployment.deployments.* permissions in the preceding table. See Override data plane cluster configurations.

​
Default role permissions tables

The following tables compare the actions each user role permits.

​
Default Deployment user permissions

​
Default Workspace user permissions

​
Default System user permissions

​
Default role permissions lists

The following sections list the permission values that each role has by default as defined in the Astronomer Helm chart. You can update these permissions in your values.yaml file if you want to change the permissions that each role has. See Customize role permissions. These lists are also published in YAML form in the Astronomer documentation repository.

​
System Viewer

The System Viewer has the following permissions by default:
  • system.airflow.get: View the Airflow UI for any Deployment
  • system.deployment.variables.get: View environment variables for any Deployment
  • system.deployments.get: View any setting for any Deployment in the Astro Private Cloud UI
  • system.deployRevisions.get: Use paginatedDeployRevisions API to view deploy revisions
  • system.invites.get: View all pending user invites in the System Admin tab of the Astro Private Cloud UI
  • system.invite.get: View information for any pending user invite
  • system.monitoring.get: Access to Grafana for system-level monitoring
  • system.serviceAccounts.get: View service accounts for any Deployment or Workspace
  • system.updates.get: View the newest platform release version number
  • system.users.get: View information for any user on the platform, including their email address, the list of Workspaces that user has access to, and their user role
  • system.workspace.get: View information for any Workspace
  • system.workspace.deployments.config.get: Read a Workspace’s deployments config override when using a system-scoped role binding (same workspaceDeploymentsConfig query with system permissions)

​
System Editor

The System Editor has the same default permissions as the System Viewer, plus:
  • system.adminCount.get: View System Admin users
  • system.deployment.variables.update: Modify environment variables for any Deployment
  • system.iam.update: Modify IAM roles for any Deployment
  • system.serviceAccounts.update: Modify service accounts for any Workspace or Deployment
  • deployment.airflow.user: Airflow user permissions for all Deployments
  • system.registryBaseImages.push: Modify base layer Docker images for Deployments
  • system.workspace.deployments.config.update: Update a Workspace’s deployments config override from a system context (updateWorkspaceDeploymentsConfig with a system role)
  • system.deployment.deployments.config.update: Update any Deployment’s deployments config override from a system context (updateDeploymentConfig)

​
System Admin

The System Admin has the same default permissions as the System Viewer and System Editor, plus:
  • system.clusters.register: Register a new data plane cluster
  • system.clusters.deregister: Deregister (remove) an existing data plane cluster
  • system.clusters.update: Update data plane cluster configuration or metadata
  • system.clusters.get: View details and status of any registered data plane cluster
  • system.cleanupAirflowDb.delete: Clean Deployment task metadata
  • system.deployments.create: Create a Deployment on any Workspace
  • system.deployments.update: Modify any Deployment
  • system.deployments.upsert: Use upsertDeployment API
  • system.deployments.delete: Delete any Deployment
  • system.deployments.images.push: Deploy code to any Deployment
  • system.deployments.logs: View logs for any Deployment
  • system.deployments.metrics: View metrics for any Deployment
  • system.invites.get: View pending user invites in all Workspaces
  • system.serviceAccounts.create: Create a service account at any level
  • system.serviceAccounts.delete: Delete any service account
  • system.serviceAccounts.update: Modify any service account
  • system.teams.remove: Delete any Team
  • system.user.invite: Invite a user
  • system.user.delete: Delete a user
  • system.user.forceDelete: Delete a user that is a part of an IdP team
  • system.user.verifyEmail: Bypass email verification for any user
  • system.workspace.delete: Delete any Workspace
  • system.workspace.update: Modify the name or description of any Workspace
  • system.workspace.deployments.config.delete: Reset a Workspace’s deployments config override from a system context (deleteWorkspaceDeploymentsConfig)
  • system.deployment.deployments.config.delete: Reset any Deployment’s deployments config override from a system context (deleteDeploymentConfig)
  • system.airflow.admin: Airflow admin permissions on any Deployment, including permission to configure:
    • Pools
    • Configuration
    • Users
    • Connections
    • Variables
    • XComs

​
Workspace Viewer

The Workspace Viewer has the following default permissions for a given Workspace:
  • workspace.config.get: View the Workspace
  • system.deployments.get: View all settings and configuration pages of any Deployment
  • workspace.serviceAccounts.get: View any Deployment or Workspace-level service account
  • workspace.users.get: View information for all users with access to the Workspace
  • workspace.teams.get: View Teams belonging to the Workspace
  • workspace.taskUsage.get: View task usage in the Workspace
  • workspace.deployments.config.get: Read the Workspace config governance override (workspaceDeploymentsConfig in the APC API)

​
Workspace Editor

For a given Workspace, the Workspace Editor has the same default permissions as the Workspace Viewer, plus:
  • workspace.adminCount.get: View Workspace Admin users
  • workspace.config.update: Modify the Workspace, including Workspace Name, Description, and user access
  • workspace.deployments.create: Create a Deployment in the Workspace
  • workspace.deployments.upsert: Use Create Deployment path within the upsertDeployment API
  • workspace.serviceAccounts.create: Create a Workspace-level service account
  • workspace.serviceAccounts.update: Modify a Workspace-level service account
  • workspace.serviceAccounts.delete: Delete a Workspace-level service account
  • workspace.deployments.config.update: Create or update the Workspace’s deployments config override (updateWorkspaceDeploymentsConfig in the APC API)

​
Workspace Admin

For a given Workspace, the Workspace Admin has the same default permissions as the Workspace Viewer and Workspace Editor, plus:
  • workspace.invites.get: View pending user invites for the Workspace
  • workspace.config.delete: Delete the Workspace
  • workspace.iam.update: Update IAM for the Workspace
  • workspace.teams.getAll: View all users in Teams belonging to the Workspace
  • workspace.users.getAll: View all users in the Workspace
  • workspace.deployments.config.delete: Reset the Workspace’s deployments config override (deleteWorkspaceDeploymentsConfig in the APC API)
In addition, Workspace Admins have Deployment Admin permissions for all Deployments within the Workspace.

​
Deployment Viewer

For a given Deployment, a Deployment Viewer has the following permissions:
  • deployment.airflow.get: View the Airflow UI
  • deployment.config.get: View the Deployment’s settings
  • deployment.deployRevisions.get: Use the paginatedDeployRevisions API to view deploy revisions
  • deployment.logs.get: View the Deployment’s logs
  • deployment.images.pull: Access the Deployment’s running Docker image
  • deployment.metrics.get: View the Deployment’s Metrics tab in the Astro Private Cloud UI
  • deployment.serviceAccounts.get: View any service account for the Deployment
  • deployment.status.get: View the Deployment’s status
  • deployment.variables.get: View the Deployment’s environment variables
  • deployment.users.get: View the list of users with access to the Deployment
  • deployment.teams.get: View all Teams belonging to the Deployment
  • deployment.taskUsage.get: View task usage information for the Deployment

​
Deployment Editor

For a given Deployment, the Deployment Editor has the same default permissions as the Deployment Viewer, plus:
  • deployment.adminCount.get: View Deployment Admin users
  • deployment.airflow.user: Airflow user permissions for all Deployments, including modifying task runs and Dag runs
  • deployment.config.update: Modify the Deployment’s settings
  • deployment.config.upsert: Use upsertDeployment API
  • deployment.dags.push: Push Dag-only code deploys to the Deployment using the Astro CLI
  • deployment.images.push: Push code to the Deployment using the Astro CLI
  • deployment.serviceAccounts.create: Create a Deployment-level service account
  • deployment.serviceAccounts.update: Modify a Deployment-level service account
  • deployment.serviceAccounts.delete: Delete a Deployment-level service account
  • deployment.variables.update: Update the Deployment’s environment variables
  • deployment.deployments.config.update: Create or update the Deployment’s deployments config override (updateDeploymentConfig in the APC API)

​
Deployment Admin

For a given Deployment, the Deployment Admin has the same default permissions as the Deployment Viewer and the Deployment Editor, plus:
  • deployment.config.delete: Delete the Deployment
  • deployment.userRoles.update: Update Deployment-level permissions for users within the Deployment
  • deployment.teamRoles.update: Update Deployment-level permissions for Teams within the Deployment
  • deployment.deployments.config.delete: Reset the Deployment’s deployments config override (deleteDeploymentConfig in the APC API)
  • deployment.airflow.admin: Airflow admin permissions, including permission to configure:
    • Pools
    • Configuration
    • Users
    • Connections
    • Variables
    • XComs

​
Custom role permission catalog

Astro Private Cloud 2.1This feature was introduced in Astro Private Cloud 2.1. To access this feature, upgrade your Astro Private Cloud installation to 2.1 or later.
This is the full list of permissions you can grant through a custom role. Permissions use the same categories as the role builder. Some permissions depend on others. For example, an update or delete permission depends on the matching get permission. Each entry notes its dependencies, and the role builder applies them automatically when you select a permission. Creating, updating, or deleting a custom role always requires a System-scope role-management permission (system.roles.<action> or system.iam.update), regardless of what scope the role itself targets. A Workspace or Deployment Admin can still be assigned a role at their own scope, but authoring a role definition is a System Admin action.
This catalog covers permissions available to custom roles. For the default permissions of the built-in System, Workspace, and Deployment roles, see the preceding sections.

​
System administration

  • system.adminCount.get: See how many System Admins exist on the platform. Check this before removing an admin so the platform isn’t left without one.
  • system.airflow.admin: Full admin-level access to Airflow, including Dags, connections, variables, and pools, for every Deployment on the platform. Also lets you grant that same access when building another user’s custom role.
  • system.airflow.get: Read-only access to Airflow, including Dags, runs, and logs, for every Deployment on the platform. This grants you Airflow viewer access directly.
  • system.airflow.user: Edit-level access to Airflow for every Deployment on the platform, covering actions such as triggering and editing Dags, runs, variables, and connections, but not admin-only actions. Also lets you grant that same level when building another user’s custom role.
  • system.airflow.viewer: Doesn’t grant you Airflow access. It lets you grant other users read-only Airflow access, including Dags, logs, and connections, across every Deployment when building their custom role.
  • system.cleanupAirflowDb.delete: Start a cleanup job that purges old Airflow history, such as past task runs and logs, from one or more Deployment metadata databases so they don’t grow too large.
  • system.cleanupDeployRevisions.delete: Delete old deploy/release history entries (past deploys) older than a chosen number of days, for a single Deployment or across the whole platform.
  • system.clusters.cordon: Put a cluster into maintenance mode (cordon) and lift it again (uncordon). While cordoned, the cluster rejects all Deployment create, update, delete, and image operations. Requires system.clusters.get.
  • system.clusters.deregister: Remove a cluster from the platform’s list of managed clusters. Requires system.clusters.get.
  • system.clusters.get: View the list of clusters on the platform, cluster details, available disaster-recovery failover targets, and regions.
  • system.clusters.register: Register a new cluster with the platform. Requires system.clusters.get.
  • system.clusters.update: Edit cluster settings, manage disaster-recovery regions, and trigger or upgrade Deployments as part of a failover. Requires system.clusters.get.
  • system.deployRevisions.get: View the deploy/release history (a record of past deploys, useful for rollbacks) for Deployments across the platform.
  • system.deployment.deployments.config.delete: Remove one specific Deployment’s advanced configuration overrides (like custom resource limits or executor settings), restoring it to the Workspace/platform defaults, for any Deployment on the platform.
  • system.deployment.deployments.config.update: Set advanced configuration overrides (like resource limits, executors, or scaling behavior) for one specific Deployment, for any Deployment on the platform. Separate from that Deployment’s everyday settings such as resources, alerts, or scaling shortcuts.
  • system.deployment.variables.get: View a Deployment’s environment variables (used to configure Airflow tasks), for any Deployment on the platform.
  • system.deployment.variables.update: Add, edit, or remove a Deployment’s environment variables, for any Deployment on the platform. Requires system.deployment.variables.get.
  • system.deployments.adopt: See Airflow Deployments that exist in a cluster but aren’t yet managed by Astro Private Cloud, and bring them under its management. Requires system.deployments.get.
  • system.deployments.cordon: Temporarily lock a Deployment to block changes to it, and unlock it again, for any Deployment on the platform. Useful during maintenance or an incident. Requires system.deployments.get.
  • system.deployments.create: Has no effect in the Astro Private Cloud UI. Creating a Deployment is controlled by system.deployments.upsert. Requires system.deployments.get.
  • system.deployments.dags.push: Roll a Deployment back to a previous Dag-only deploy, for any Deployment on the platform. Requires system.deployments.get.
  • system.deployments.delete: Permanently delete a Deployment, for any Deployment on the platform. Requires system.deployments.get.
  • system.deployments.get: View Deployments across the entire platform, Deployment details, lists, and access URLs, regardless of which Workspace they belong to.
  • system.deployments.images.push: Deploy a new or existing image to a Deployment (for example, from an external CI/CD pipeline) and roll back to a previous image deploy, for any Deployment on the platform. Requires system.deployments.get.
  • system.deployments.logs: View live log streams for any Deployment on the platform. Requires system.deployments.get.
  • system.deployments.metrics: View live metrics (like task and worker resource usage) for any Deployment on the platform. Requires system.deployments.get.
  • system.deployments.status: View the live status of any Deployment on the platform (for example, whether it’s healthy or still deploying). Requires system.deployments.get.
  • system.deployments.unadopt: Release a Deployment from Astro Private Cloud management without deleting the underlying Airflow instance, for any Deployment on the platform. Requires system.deployments.get.
  • system.deployments.update: Change a Deployment’s everyday settings, resource sizing, scaling behavior, alert configuration, and who’s assigned to it, for any Deployment on the platform. Doesn’t cover advanced configuration overrides, which use system.deployment.deployments.config.update. Requires system.deployments.get.
  • system.deployments.upsert: Create a brand-new Deployment, or save changes made in a Deployment’s setup/settings form (including checking that git-sync credentials work), for any Deployment on the platform. Requires system.deployments.get.
  • system.iam.update: Manage user and Team access platform-wide: assign or remove system-level roles, add or remove Workspace members and Teams, bulk-import Airflow users into a Deployment, and manage custom role assignments for anyone. Requires system.users.get.
  • system.invite.get: Has no effect in Astro Private Cloud. Viewing pending platform invitations is controlled by system.invites.get.
  • system.invites.get: View the list of pending invitations to join the platform.
  • system.monitoring.get: Access the platform’s monitoring dashboards (such as Grafana, Prometheus, Alertmanager, and Elasticsearch).
  • system.registryBaseImages.push: Publish updates to the platform’s shared base Airflow images that every Deployment is built from.
  • system.roles.create: Create new custom roles of any scope (system, Workspace, Deployment, or cluster) in the role builder. Requires system.roles.get.
  • system.roles.delete: Delete existing custom roles of any scope. Requires system.roles.get.
  • system.roles.get: View existing custom roles of any scope and see who they’re assigned to.
  • system.roles.update: Edit existing custom roles of any scope, including which permissions they grant. Requires system.roles.get.
  • system.serviceAccounts.create: Create service accounts (API keys used by automation instead of a person) anywhere on the platform, system-wide, or for any Workspace or Deployment. Requires system.serviceAccounts.get.
  • system.serviceAccounts.delete: Delete service accounts anywhere on the platform, system-wide, or for any Workspace or Deployment. Requires system.serviceAccounts.get.
  • system.serviceAccounts.get: View service accounts anywhere on the platform, system-wide, or for any Workspace or Deployment.
  • system.serviceAccounts.update: Edit service accounts anywhere on the platform (for example, their permissions), system-wide, or for any Workspace or Deployment. Requires system.serviceAccounts.get.
  • system.taskUsage.get: View task usage metrics, the task-run counts used for consumption-based billing, for the whole platform, any Workspace, or any Deployment.
  • system.teams.create: Create new Teams on the platform. Requires system.teams.get.
  • system.teams.get: View Teams and their members, for any Team on the platform (including within a specific Workspace or Deployment).
  • system.teams.remove: Delete a Team from the platform. Requires system.teams.get.
  • system.teams.update: Edit a Team’s details, for any Team on the platform. Requires system.teams.get.
  • system.updates.get: See whether a newer version of the platform is available to upgrade to.
  • system.user.delete: Remove a user from the platform. Requires system.users.get.
  • system.user.forceDelete: Remove a user from the platform even if they belong to a Team synced from your company’s identity provider, normally blocked to protect those accounts from accidental removal. Requires system.users.get.
  • system.user.invite: Invite a new user to join the platform. Requires system.users.get.
  • system.user.verifyEmail: Manually mark a user’s email address as verified. Requires system.users.get.
  • system.users.get: View the list of users on the platform, their role assignments, and their Workspace/Deployment membership.
  • system.workspace.create: Create a new Workspace. Every authenticated user already holds this permission through the built-in user role, so granting it explicitly in a custom role has no additional effect.
  • system.workspace.delete: Delete a Workspace, for any Workspace on the platform. Requires system.workspace.get.
  • system.workspace.deployments.config.delete: Remove the default configuration overrides a Workspace applies to its Deployments (like resource limits or executor settings), for any Workspace on the platform. Requires system.workspace.deployments.config.get.
  • system.workspace.deployments.config.get: View the default configuration overrides a Workspace applies to its Deployments, for any Workspace on the platform.
  • system.workspace.deployments.config.update: Set default configuration overrides (like resource limits or executor settings) that apply to every Deployment within a Workspace, for any Workspace on the platform. Requires system.workspace.deployments.config.get.
  • system.workspace.get: View any Workspace on the platform, and see the full list of every Workspace, regardless of your membership in it.
  • system.workspace.update: Edit a Workspace’s general settings (like its name or description), for any Workspace on the platform. Requires system.workspace.get.

​
Cluster management

  • cluster.config.create: Register a new data plane cluster with the platform so Deployments can run on it. Requires cluster.config.get.
  • cluster.config.delete: Deregister a cluster from the platform, removing it from the list of clusters that Deployments can run on. Requires cluster.config.get.
  • cluster.config.cordon: Put a cluster into maintenance mode (cordon) and lift it again (uncordon). While cordoned, the cluster rejects all Deployment create, update, delete, and image operations. Requires cluster.config.get.
  • cluster.config.get: View a cluster’s details and status, the cloud regions available to it, and which other clusters it could fail over to.
  • cluster.config.update: Edit a cluster’s settings (name, connection endpoints, assigned region, Deployment overrides), and trigger or manage failover to another cluster. Requires cluster.config.get.
  • cluster.roles.get: View the custom roles and role assignments that control cluster-level administration.
  • cluster.roles.update: Edit a cluster-administration role template, and assign or change who holds cluster-admin access. Requires cluster.roles.get.

​
Workspace management

  • workspace.adminCount.get: See how many Workspace Admins exist for this Workspace, used to warn if an action would leave it without one.
  • workspace.config.delete: Permanently delete this Workspace and everything in it. Requires workspace.config.get.
  • workspace.config.get: View a Workspace’s basic details, such as its name and description.
  • workspace.config.update: Change a Workspace’s name or description. Requires workspace.config.get.
  • workspace.deployments.config.delete: Remove any custom configuration overrides for the Workspace, reverting all its Deployments back to the platform’s standard defaults. Requires workspace.deployments.config.get.
  • workspace.deployments.config.get: View the Workspace-wide configuration overrides that apply to every Deployment in this Workspace. This is different from viewing the Deployments themselves.
  • workspace.deployments.config.update: Change the Workspace-wide configuration overrides (such as default resource limits) that apply to every Deployment in this Workspace. Requires workspace.deployments.config.get.
  • workspace.deployments.adopt: Bring an Airflow environment that’s already running on a cluster, but not yet managed here, under this Workspace so it can be managed as a Deployment. Requires workspace.deployments.get.
  • workspace.deployments.cordon: Pause platform updates to a Deployment, or resume them. While paused, its Airflow environment keeps running, but the platform stops applying changes to it. Requires workspace.deployments.get.
  • workspace.deployments.create: Create new Deployments within this Workspace. Requires workspace.deployments.get.
  • workspace.deployments.get: View the list of Deployments in this Workspace and open an individual Deployment’s details. This is different from viewing the Workspace’s Deployment configuration overrides.
  • workspace.deployments.unadopt: Release a previously adopted Deployment from this Workspace’s management, without affecting the underlying Airflow environment, which keeps running untouched. Requires workspace.deployments.get.
  • workspace.deployments.upsert: Create a new Deployment within this Workspace. Requires workspace.deployments.get.
  • workspace.iam.update: Add or remove users and Teams from this Workspace, and change which role each one holds. This controls who has access and which role they’re assigned, not the role definitions themselves. Use the workspace.roles.* permissions to create or edit roles. Requires workspace.users.get.
  • workspace.invites.get: View pending invitations to join this Workspace.
  • workspace.roles.get: View the custom roles belonging to this Workspace, and see who currently holds each one. Creating, updating, or deleting a role always requires a System-scope role-management permission, even for a Workspace-scoped role — see the note at the top of this section.
  • workspace.serviceAccounts.create: Create a new API service account (a non-human credential) for programmatic access to this Workspace. Requires workspace.serviceAccounts.get.
  • workspace.serviceAccounts.delete: Delete an API service account from this Workspace, revoking its programmatic access. Requires workspace.serviceAccounts.get.
  • workspace.serviceAccounts.get: View the API service accounts that exist in this Workspace.
  • workspace.serviceAccounts.update: Edit an existing API service account in this Workspace, such as its name or assigned role. Requires workspace.serviceAccounts.get.
  • workspace.taskUsage.get: View task-execution usage statistics for the Deployments in this Workspace.
  • workspace.teams.get: View the Teams that already belong to this Workspace.
  • workspace.teams.getAll: Search and browse every Team across the entire platform, for example, to find one to add to this Workspace, not just the Teams already in it. Requires workspace.teams.get.
  • workspace.users.get: View the people who are already members of this Workspace.
  • workspace.users.getAll: Search and browse every user across the entire platform, for example, to find someone to add through identity provider group import, not just the members already in this Workspace. Requires workspace.users.get.

​
Deployment management

  • deployment.adminCount.get: See how many admins currently have full control over this Deployment (used to warn before removing the last one).
  • deployment.config.delete: Permanently delete this Deployment. Requires deployment.config.get.
  • deployment.config.get: View this Deployment and open its pages at all. Most other Deployment permissions require this as a baseline.
  • deployment.config.update: Change this Deployment’s operating settings, things like autoscaling, alert email recipients, and moving it to another cluster during a failover. Requires deployment.config.get.
  • deployment.config.upsert: Create a new Deployment, or edit an existing Deployment’s core setup, name, executor, workers/resources, runtime version, and Dag deploy/git-sync configuration. Requires deployment.config.get.
  • deployment.dags.push: Deploy new Dag code to this Deployment, used both by people deploying from the UI and by CI/CD automation (for example, the Astro CLI).
  • deployment.deployRevisions.get: View this Deployment’s deploy history, the list of past code/image deploys and when they happened. Requires deployment.config.get.
  • deployment.deployments.config.delete: Remove an advanced, platform-level configuration override applied to this specific Deployment (an admin/support-level setting, separate from the Deployment’s regular settings).
  • deployment.deployments.config.update: Set an advanced, platform-level configuration override on this specific Deployment (an admin/support-level setting, separate from the Deployment’s regular settings).
  • deployment.deployments.cordon: Temporarily pause or resume scheduling on this Deployment (cordon/uncordon), blocking new activity without deleting it.
  • deployment.images.pull: Retrieve this Deployment’s built container images, used when promoting/retagging an image between Deployments or environments.
  • deployment.images.push: Deploy a new container image to this Deployment, the action behind deploying custom Docker images, typically used by CI/CD automation as well as manual image deploys.
  • deployment.logs.get: View this Deployment’s raw component logs (scheduler, webserver, workers, triggerer) for troubleshooting.
  • deployment.metrics.get: View this Deployment’s performance graphs and charts, including CPU, memory, and task throughput.
  • deployment.roles.get: View the custom role definitions available to assign on Deployments, including what each one grants. Creating, updating, or deleting a role always requires a System-scope role-management permission, even for a Deployment-scoped role — see the note at the top of this section.
  • deployment.serviceAccounts.create: Create API-key based service accounts for this Deployment, used to authenticate automation and CI/CD tools. Requires deployment.serviceAccounts.get.
  • deployment.serviceAccounts.delete: Delete API-key based service accounts on this Deployment. Requires deployment.serviceAccounts.get.
  • deployment.serviceAccounts.get: View the API-key based service accounts configured on this Deployment.
  • deployment.serviceAccounts.update: Edit API-key based service accounts on this Deployment (for example, rename or change their role). Requires deployment.serviceAccounts.get.
  • deployment.status.get: View this Deployment’s overall health/status indicator (for example, healthy, degraded).
  • deployment.taskUsage.get: View task-execution usage data for this Deployment, used for usage and billing reporting.
  • deployment.teamRoles.update: Assign or change which role a specific Team holds on this Deployment. This is about who has access and at what level, not about editing role definitions. Requires deployment.teams.get.
  • deployment.teams.get: View which Teams have access to this Deployment.
  • deployment.userRoles.update: Assign or change which role a specific person holds on this Deployment. This is about who has access and at what level, not about editing role definitions. Requires deployment.users.get.
  • deployment.users.get: View which individual people have access to this Deployment.
  • deployment.variables.get: View this Deployment’s environment variables.
  • deployment.variables.update: Add, edit, or remove this Deployment’s environment variables. Requires deployment.variables.get.

​
Airflow access

  • deployment.airflow.access: Open this Deployment’s Airflow UI. On its own this shows an empty shell — each page inside needs its own permission — so this is the starting point every other Airflow permission builds on. Requires deployment.config.get.
  • deployment.airflow.admin: Full control inside this Deployment’s Airflow UI, including viewing, editing, and running Dags, connections, and variables. This is the highest of the three Airflow access tiers, and grants everything the granular Airflow permissions below would grant individually. Requires deployment.config.get.
  • deployment.airflow.get: View-only access to this Deployment’s Airflow UI. Despite the name, this is the entire read-only viewer tier (Dags, runs, task instances, logs, and audit logs), not a single narrow capability. Grant this only when someone should see all of it; otherwise, grant the individual Airflow permissions below along with deployment.airflow.access. Requires deployment.config.get.
  • deployment.airflow.user: Day-to-day working access to this Deployment’s Airflow UI, can edit and trigger things like Dags and connections, but without full admin-level control. Requires deployment.config.get.

​
Airflow configuration

  • deployment.airflow.config.read: View Airflow’s own webserver configuration page for this Deployment. Requires deployment.airflow.access.

​
Dag operations

The permissions in this category apply on both Airflow 2 and Airflow 3. Airflow 2’s security model uses deployment.airflow.dag.read as the parent check for Dag runs, task instances, logs, and more, so it isn’t optional there — without it, permissions that depend on it have nothing to attach to.
  • deployment.airflow.dag.read: View Dag-level details and metadata, such as whether a Dag is paused, in the Airflow UI for this Deployment. Requires deployment.airflow.access.
  • deployment.airflow.dag.edit: Edit Dag-level settings, such as pausing or unpausing a Dag, in the Airflow UI for this Deployment. Requires deployment.airflow.dag.read.
  • deployment.airflow.dag.delete: Delete a Dag’s metadata from the Airflow UI for this Deployment. Requires deployment.airflow.dag.read.
  • deployment.airflow.dag_code.read: View the Python source code of this Deployment’s Dags in the Airflow UI. Requires deployment.airflow.dag.read and deployment.airflow.task_instance.read.

​
Dag runs

  • deployment.airflow.dag_run.read: View Dag runs (individual executions of a Dag) for this Deployment. Requires deployment.airflow.dag.read.
  • deployment.airflow.dag_run.create: Manually trigger new Dag runs (individual executions of a Dag) for this Deployment. Requires deployment.airflow.dag_run.read.
  • deployment.airflow.dag_run.edit: Edit Dag runs (individual executions of a Dag) for this Deployment, such as changing a run’s state. Requires deployment.airflow.dag_run.read.
  • deployment.airflow.dag_run.delete: Delete Dag runs (individual executions of a Dag) for this Deployment. Requires deployment.airflow.dag_run.read.
  • deployment.airflow.dag_run.clear: Clear Dag runs for this Deployment, resetting the run’s state so its tasks can be re-executed. Requires deployment.airflow.dag_run.read.

​
Task instances

  • deployment.airflow.task_instance.read: View task instances, a single task’s execution within a specific Dag run, for this Deployment. Requires deployment.airflow.dag.read.
  • deployment.airflow.task_instance.create: Create new task instances, a single task’s execution within a specific Dag run, for this Deployment. Requires deployment.airflow.task_instance.read.
  • deployment.airflow.task_instance.edit: Edit task instances for this Deployment, such as marking a task’s execution as success, failed, or ready to retry. Requires deployment.airflow.task_instance.read.
  • deployment.airflow.task_instance.delete: Delete task instances, a single task’s execution within a specific Dag run, for this Deployment. Requires deployment.airflow.task_instance.read.

​
Task logs

  • deployment.airflow.task_log.read: View task logs, the log output produced by a task’s execution, for this Deployment. Requires deployment.airflow.dag.read.

​
Triggers

  • deployment.airflow.trigger.read: View Triggers, the waiting half of a deferred task, listing which trigger classes are currently pending, for this Deployment. Requires deployment.airflow.access.

​
Variables and connections

  • deployment.airflow.variable.read: View Airflow variables (key-value configuration values Dags can read at runtime) for this Deployment. Requires deployment.airflow.access.
  • deployment.airflow.variable.create: Create new Airflow variables (key-value configuration values Dags can read at runtime) for this Deployment. Requires deployment.airflow.variable.read.
  • deployment.airflow.variable.edit: Edit existing Airflow variables (key-value configuration values Dags can read at runtime) for this Deployment. Requires deployment.airflow.variable.read.
  • deployment.airflow.variable.delete: Delete Airflow variables (key-value configuration values Dags can read at runtime) for this Deployment. Requires deployment.airflow.variable.read.
  • deployment.airflow.connection.read: View Airflow connections (stored credentials for external systems like databases, APIs, and cloud services) for this Deployment. Requires deployment.airflow.access.
  • deployment.airflow.connection.create: Create new Airflow connections (stored credentials for external systems like databases, APIs, and cloud services) for this Deployment. Requires deployment.airflow.connection.read.
  • deployment.airflow.connection.edit: Edit existing Airflow connections (stored credentials for external systems like databases, APIs, and cloud services) for this Deployment. Requires deployment.airflow.connection.read.
  • deployment.airflow.connection.delete: Delete Airflow connections (stored credentials for external systems like databases, APIs, and cloud services) for this Deployment. Requires deployment.airflow.connection.read.

​
Pools and XComs

  • deployment.airflow.pool.read: View Airflow pools (named limits on how many tasks can run at the same time) for this Deployment. Requires deployment.airflow.access.
  • deployment.airflow.pool.create: Create new Airflow pools (named limits on how many tasks can run at the same time) for this Deployment. Requires deployment.airflow.pool.read.
  • deployment.airflow.pool.edit: Edit existing Airflow pools (named limits on how many tasks can run at the same time) for this Deployment. Requires deployment.airflow.pool.read.
  • deployment.airflow.pool.delete: Delete Airflow pools (named limits on how many tasks can run at the same time) for this Deployment. Requires deployment.airflow.pool.read.
  • deployment.airflow.xcom.read: View XComs (small pieces of data tasks pass to each other during execution) for this Deployment. Requires deployment.airflow.dag.read.
  • deployment.airflow.xcom.create: Create new XComs (small pieces of data tasks pass to each other during execution) for this Deployment. Requires deployment.airflow.xcom.read.
  • deployment.airflow.xcom.delete: Delete XComs (small pieces of data tasks pass to each other during execution) for this Deployment. Requires deployment.airflow.xcom.read.

​
Datasets

  • deployment.airflow.dataset.read: View datasets (data-aware scheduling assets that can trigger Dags when updated) for this Deployment. Requires deployment.airflow.access.
  • deployment.airflow.dataset.create: Create dataset events (manually mark a dataset as updated to trigger downstream Dags) for this Deployment. Requires deployment.airflow.dataset.read.
  • deployment.airflow.dataset.delete: Delete datasets for this Deployment. Requires deployment.airflow.dataset.read.

​
Backfills

  • deployment.airflow.backfill.read: View backfills (re-runs of a Dag over a past date range it already covers) for this Deployment. Requires deployment.airflow.access.
  • deployment.airflow.backfill.create: Start new backfills (re-runs of a Dag over a past date range it already covers) for this Deployment. Requires deployment.airflow.backfill.read.
  • deployment.airflow.backfill.edit: Edit or manage in-progress backfills (re-runs of a Dag over a past date range it already covers) for this Deployment. Requires deployment.airflow.backfill.read.
  • deployment.airflow.backfill.delete: Cancel or delete backfills (re-runs of a Dag over a past date range it already covers) for this Deployment. Requires deployment.airflow.backfill.read.

​
Human in the loop

  • deployment.airflow.hitl_detail.read: View human-in-the-loop task details, for tasks that pause mid-run for manual approval or input, for this Deployment. Requires deployment.airflow.access.
  • deployment.airflow.hitl_detail.edit: Respond to human-in-the-loop tasks, such as approving or providing input for tasks paused mid-run, for this Deployment. Requires deployment.airflow.hitl_detail.read.

​
Audit and logs

  • deployment.airflow.audit_log.read: View the audit log, a record of actions users take in the Airflow UI, for this Deployment. Requires deployment.airflow.dag.read.
  • deployment.airflow.import_error.read: See the errors Airflow reports when a Dag file fails to load for this Deployment. The messages quote file paths and lines of the Dag’s code. Requires deployment.airflow.access.

​
Browse and monitoring

  • deployment.airflow.sla_miss.read: View service-level agreement (SLA) misses, which are tasks that ran past their defined SLA, for this Deployment. Requires deployment.airflow.dag.read.
  • deployment.airflow.sla_miss.edit: Edit SLA miss records for this Deployment. Requires deployment.airflow.sla_miss.read.
  • deployment.airflow.sla_miss.delete: Delete SLA miss records for this Deployment. Requires deployment.airflow.sla_miss.read.
  • deployment.airflow.task_reschedule.read: View task reschedules, which are records of sensor tasks rescheduled while waiting, for this Deployment. Requires deployment.airflow.dag.read.
  • deployment.airflow.cluster_activity.read: View the Cluster Activity page, a dashboard of Dag run and task health, for this Deployment. Requires deployment.airflow.access.
  • deployment.airflow.dag_warning.read: View Dag warnings, which are parsing and configuration warnings raised for Dags, for this Deployment. Requires deployment.airflow.dag.read.

​
Providers and plugins

  • deployment.airflow.provider.read: View the Providers page, the installed Airflow provider packages and their versions, for this Deployment. Requires deployment.airflow.access.
  • deployment.airflow.plugin.read: View the Plugins page, the installed Airflow plugins, for this Deployment. Requires deployment.airflow.access.

​
Full permission dependency reference

The role builder adds a permission’s dependencies for you automatically when you select it. If you’re calling the APC API directly instead of using the role builder, dependencies aren’t added for you — submitting an incomplete permission list is rejected, and the error alone doesn’t tell you the rest of the chain. The tables below list every permission’s complete dependency chain, so you can assemble a full permissionKeys list without tracing it yourself one entry at a time. To grant a permission through the API, include it along with everything in its dependency chain. For example, to grant deployment.airflow.dag_run.read directly through the API, include all of deployment.airflow.dag_run.read, deployment.airflow.dag.read, deployment.airflow.access, and deployment.config.get in the same request.

​
System scope

​
Cluster scope

​
Workspace scope

​
Deployment scope