Skip to content

Update AwsAuthManager to support multi-team #65371

@vincbeck

Description

@vincbeck

Description

The Airflow multi-team feature allows scoping resources (DAGs, connections, pools, variables) to teams. When performing authorization requests, Airflow passes the team_name through resource details (e.g., ConnectionDetails.team_name, DagDetails.team_name, PoolDetails.team_name, VariableDetails.team_name). It is up to the auth manager to use that team name when making authorization decisions.

Currently, AwsAuthManager ignores the team_name parameter entirely. The is_authorized_* methods do not extract team_name from the resource details, and the filter_authorized_* methods accept team_name as a parameter but never pass it through to the AVP facade. Additionally, is_authorized_team is not implemented, which means enabling core.multi_team with the AWS auth manager raises a NotImplementedError.

What needs to change

KeycloakAuthManager already supports multi-team and can be used as a reference implementation. The key patterns to follow:

  1. Extract team_name from resource details in is_authorized_* methods — For team-scoped resources (connection, dag, pool, variable), extract team_name from the details object and pass it to the AVP facade. Example from Keycloak:

    def is_authorized_connection(self, *, method, user, details=None):
        connection_id = details.conn_id if details else None
        team_name = self._get_team_name(details)
        return self._is_authorized(
            method=method, resource_type=..., user=user,
            resource_id=connection_id, team_name=team_name,
        )
  2. Implement is_authorized_team — This method is required for multi-team compatibility. It checks whether a user is authorized to perform actions on a team (primarily used to check team membership).

  3. Pass team_name through to AVP in filter_authorized_* methods — The filter_authorized_connections, filter_authorized_dag_ids, filter_authorized_pools, and filter_authorized_variables methods already accept team_name but currently discard it.

  4. Update the AVP facade — The is_authorized and batch methods in AwsAuthManagerAmazonVerifiedPermissionsFacade need to accept and use team_name. This likely means incorporating the team name into the AVP context or entity structure so that Amazon Verified Permissions policies can make team-aware authorization decisions.

  5. Update the AVP Cedar schema (providers/amazon/aws/src/airflow/providers/amazon/aws/auth_manager/avp/schema.json) — The schema may need a Team entity type and/or team-related attributes on existing resource entities so that Cedar policies can reference team membership.

Files likely to be modified

  • providers/amazon/src/airflow/providers/amazon/aws/auth_manager/aws_auth_manager.py — Add team_name extraction, implement is_authorized_team, pass team_name to facade
  • providers/amazon/src/airflow/providers/amazon/aws/auth_manager/avp/facade.py — Accept and use team_name in authorization requests
  • providers/amazon/src/airflow/providers/amazon/aws/auth_manager/avp/entities.py — Add TEAM to AvpEntities
  • providers/amazon/src/airflow/providers/amazon/aws/auth_manager/avp/schema.json — Update Cedar schema for team support
  • Unit tests in providers/amazon/tests/unit/amazon/aws/auth_manager/

Reference implementation

See KeycloakAuthManager in providers/keycloak/src/airflow/providers/keycloak/auth_manager/keycloak_auth_manager.py which:

  • Defines TEAM_SCOPED_RESOURCES to identify which resources are team-aware
  • Extracts team_name via a _get_team_name() helper from resource details
  • Incorporates team name into the authorization resource name (e.g., Connection:team_a)
  • Implements is_authorized_team for team membership checks
  • Respects the core.multi_team config flag

Use case

Operators running Airflow in multi-team mode with AWS auth manager cannot scope authorization to teams. This blocks adoption of multi-team for AWS-based deployments.

Use case/motivation

No response

Related issues

No response

Are you willing to submit a PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions