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:
-
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,
)
-
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).
-
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.
-
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.
-
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?
Code of Conduct
Description
The Airflow multi-team feature allows scoping resources (DAGs, connections, pools, variables) to teams. When performing authorization requests, Airflow passes the
team_namethrough 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,
AwsAuthManagerignores theteam_nameparameter entirely. Theis_authorized_*methods do not extractteam_namefrom the resource details, and thefilter_authorized_*methods acceptteam_nameas a parameter but never pass it through to the AVP facade. Additionally,is_authorized_teamis not implemented, which means enablingcore.multi_teamwith the AWS auth manager raises aNotImplementedError.What needs to change
KeycloakAuthManageralready supports multi-team and can be used as a reference implementation. The key patterns to follow:Extract
team_namefrom resource details inis_authorized_*methods — For team-scoped resources (connection, dag, pool, variable), extractteam_namefrom the details object and pass it to the AVP facade. Example from Keycloak: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).Pass
team_namethrough to AVP infilter_authorized_*methods — Thefilter_authorized_connections,filter_authorized_dag_ids,filter_authorized_pools, andfilter_authorized_variablesmethods already acceptteam_namebut currently discard it.Update the AVP facade — The
is_authorizedand batch methods inAwsAuthManagerAmazonVerifiedPermissionsFacadeneed to accept and useteam_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.Update the AVP Cedar schema (
providers/amazon/aws/src/airflow/providers/amazon/aws/auth_manager/avp/schema.json) — The schema may need aTeamentity 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— Addteam_nameextraction, implementis_authorized_team, passteam_nameto facadeproviders/amazon/src/airflow/providers/amazon/aws/auth_manager/avp/facade.py— Accept and useteam_namein authorization requestsproviders/amazon/src/airflow/providers/amazon/aws/auth_manager/avp/entities.py— AddTEAMtoAvpEntitiesproviders/amazon/src/airflow/providers/amazon/aws/auth_manager/avp/schema.json— Update Cedar schema for team supportproviders/amazon/tests/unit/amazon/aws/auth_manager/Reference implementation
See
KeycloakAuthManagerinproviders/keycloak/src/airflow/providers/keycloak/auth_manager/keycloak_auth_manager.pywhich:TEAM_SCOPED_RESOURCESto identify which resources are team-awareteam_namevia a_get_team_name()helper from resource detailsConnection:team_a)is_authorized_teamfor team membership checkscore.multi_teamconfig flagUse 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?
Code of Conduct