Skip to main content
Each user gets one Airflow role for each Deployment. You can change which Airflow role a built-in role such as DEPLOYMENT_EDITOR gets by overriding its deployment.airflow.* permissions in your values.yaml file. For the permission keys behind each Airflow role, see Airflow roles and their permission keys.

​
Prerequisites

  • Access to your platform values.yaml file and permission to apply a config change.
  • A test user whose only access to the Deployment comes from the role you’re overriding.
  • A release that includes the Op role: APC 1.1.8, 1.2.2, 2.0.5, 2.1.2, 2.2.0, or later. In earlier releases, deployment.airflow.op and system.airflow.op have no effect. See Airflow Op role removal and restoration.

​
How the APC API picks an Airflow role

The APC API checks a user’s permissions in rank order and uses the first match: Admin, then Op, then User, then Viewer. Op ranks between User and Admin, and it never grants Admin. On Airflow 3 Deployments, there’s no separate Op tier. Op and User both give the Editor permissions.

​
Grant Op access to a built-in role

1

Set the Airflow permissions in values.yaml

Set deployment.airflow.op to true on the role. This example gives the Deployment Editor role Op access:
Because Op ranks above User, the role keeps deployment.airflow.user: true and still gets Op. For what happens if you turn User off, see Understand the effect of turning User off.
2

Apply the change

Apply the config change to your platform.
3

Verify the result

  1. Confirm the override reached the APC API by checking the rendered Houston configuration in your control plane. Search the Houston config map for deployment.airflow.op, for example with kubectl get configmap <houston-configmap> -n <platform-namespace> -o yaml.
  2. Sign in as the test user and open the Airflow UI for a Deployment.
  3. On an Airflow 2 Deployment, open your profile in the Airflow UI and confirm the role is Op. Viewer means the override didn’t take effect, usually because your release doesn’t include the Op role.
  4. On an Airflow 3 Deployment, the UI doesn’t show a role name. Confirm instead that you can take an Editor action, such as triggering a Dag run. A read-only UI means the user got Viewer access.
  5. Confirm the user can’t take Admin actions, such as managing Airflow users. Op never grants Admin.

​
Check for permission keys that are ignored

The APC API ignores any permission key in a built-in role override that it doesn’t recognize, such as a misspelled deployment.airflow.opp. The override has no effect and the role gets its default access. In APC 2.2.0 and later, two checks report these keys:
  • When the APC API starts, it logs a warning for each unknown or removed permission key in a built-in role override. The warning names the role and the key. Search the Houston logs for built-in role override.
  • When you run the Helm values migration script described in Upgrade to Astro Private Cloud 2.0 from 1.x or Upgrade to Astro Private Cloud 2.0 from 0.37, it prints a warning to stderr for each ignored key. This check is advisory. It doesn’t change your file or block the upgrade.
Remove or correct any key that either check reports, then apply the config change.

​
Understand the effect of turning User off

Setting deployment.airflow.user: false removes the User permission from the role. What users get instead depends on the other Airflow permissions in the role: In the last row, the role keeps deployment.airflow.get from the Viewer role, so users get read-only access to Airflow. Don’t turn User off without also turning Op on unless you want that outcome. The same behavior applies to the system.airflow.op and system.airflow.user permissions for system roles.