> ## Documentation Index
> Fetch the complete documentation index at: https://astronomer.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Override the Airflow access of a built-in role on Astro Private Cloud

> Change which Airflow role a built-in Astro Private Cloud role gets, such as Deployment Editor, and verify the result.

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](https://astronomer.io/docs/astro-private-cloud/v-2-x/role-permission-reference.md#airflow-roles-and-their-permission-keys).

## Prerequisites

* Access to your platform `values.yaml` file and permission to [apply a config change](https://astronomer.io/docs/astro-private-cloud/v-2-x/apply-platform-config.md).
* 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](https://astronomer.io/docs/astro-private-cloud/v-2-x/breaking-changes-removals.md#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:

```yaml wrap theme={null}
astronomer:
  houston:
    config:
      roles:
        DEPLOYMENT_EDITOR:
          permissions:
            deployment.airflow.op: true
```

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](#understand-the-effect-of-turning-user-off).

**2. Apply the change**

[Apply the config change](https://astronomer.io/docs/astro-private-cloud/v-2-x/apply-platform-config.md) 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](https://astronomer.io/docs/astro-private-cloud/v-2-x/upgrade-1x-to-2.md) or [Upgrade to Astro Private Cloud 2.0 from 0.37](https://astronomer.io/docs/astro-private-cloud/v-2-x/upgrade-037-to-2.md), 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](https://astronomer.io/docs/astro-private-cloud/v-2-x/apply-platform-config.md).

## 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:

| `deployment.airflow.op` | `deployment.airflow.user` | Airflow 2 role | Airflow 3 permissions |
| - | - | - | - |
| `true` | `false` | Op | Editor |
| `true` | `true` | Op | Editor |
| `false` or unset | `true` | User | Editor |
| `false` or unset | `false` | Viewer | Viewer |

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.

## Related

* [Customize role permissions](https://astronomer.io/docs/astro-private-cloud/v-2-x/manage-platform-users.md#customize-role-permissions)
* [User roles and permissions](https://astronomer.io/docs/astro-private-cloud/v-2-x/role-permission-reference.md)
* [Create custom roles](https://astronomer.io/docs/astro-private-cloud/v-2-x/custom-roles.md)