Apache Airflow 系列教程 | 第23课:安全体系与权限管理
导读(Introduction)
欢迎来到 Apache Airflow 源码深度解析系列的第二十三课。
在生产环境中,安全是一切的基石。Airflow 作为数据管道的核心编排引擎,通常需要访问数据库、云服务、消息队列等敏感资源,同时面对来自不同角色用户的访问——管理员需要全局视图,开发者只需管理自己的 DAG,运维人员需要操控调度和清理任务。如何在保障安全的前提下,为不同用户提供恰当的访问权限,是每个生产级 Airflow 部署必须解决的核心问题。
Airflow 3.x 对安全体系进行了深度重构。旧有的紧耦合权限系统被替换为可插拔的Auth Manager架构(由 AIP-56 引入),将认证(Authentication)与授权(Authorization)从核心解耦,允许组织根据需要选择不同的认证后端。同时,Multi-Team机制(AIP-67)为多租户场景提供了原生支持。API 层面则采用JWT(JSON Web Token)作为无状态认证方案,结合 JWKS(JSON Web Key Set)实现密钥轮转。
本课将从 BaseAuthManager 抽象接口出发,深入分析 FAB(Flask-AppBuilder)Auth Manager 的实现、JWT Token 的生成与验证、Token 撤销机制,以及 Team 模型的多租户隔离设计。
学习目标(Learning Objectives)
完成本课学习后,你将能够:
- 理解 Auth Manager 抽象架构——掌握
BaseAuthManager的接口设计以及资源粒度的授权模型 - 深入 FAB Auth Manager 实现——理解 RBAC 角色权限体系、DAG 级别访问控制、用户序列化/反序列化
- 掌握 JWT Token 认证机制——理解
JWTGenerator和JWTValidator的工作原理,包括对称/非对称加密选择 - 理解 JWKS 密钥管理——掌握远程/本地密钥集获取、自动刷新、密钥轮转机制
- 分析 Token 撤销模型——理解
RevokedToken的持久化撤销与自动清理策略 - 掌握 Team 多租户隔离——理解 Team 模型如何通过 DagBundle 关联实现资源隔离
- 了解权限常量与资源映射——理解 Airflow 的细粒度权限定义体系
正文内容(Main Content)
1. 安全架构全景
1.1 三层安全模型
Airflow 的安全体系可以分为三个层次:
┌─────────────────────────────────────────────────────────────┐ │ 认证层 (Authentication) │ │ "你是谁?" — 验证用户身份 │ │ 方式:用户名/密码、OAuth2、LDAP、Kerberos、JWT Token │ ├─────────────────────────────────────────────────────────────┤ │ 授权层 (Authorization) │ │ "你能做什么?" — 验证用户权限 │ │ 模型:RBAC 角色、资源-动作映射、DAG 级别权限 │ ├─────────────────────────────────────────────────────────────┤ │ 隔离层 (Isolation) │ │ "你能看到什么?" — 资源可见性隔离 │ │ 机制:Team 多租户、命名空间、DagBundle 关联 │ └─────────────────────────────────────────────────────────────┘1.2 Auth Manager 可插拔架构
Airflow 3.x 引入了可插拔的 Auth Manager 架构,核心设计思想是:
- 接口与实现分离:
BaseAuthManager定义标准接口,具体实现由 Provider 提供 - 资源粒度授权:每种资源(DAG、Connection、Variable、Pool 等)都有独立的授权方法
- 批量授权优化:提供
batch_is_authorized_*方法避免 N+1 查询问题 - Multi-Team 原生支持:授权接口天然支持
team_name参数
┌─────────────────────┐ │ BaseAuthManager │ (抽象基类) │ - deserialize_user│ │ - serialize_user │ │ - is_authorized_* │ │ - generate_jwt │ │ - revoke_token │ └──────────┬──────────┘ │ ┌────────────────┼────────────────┐ │ │ │ ┌─────────┴────┐ ┌───────┴──────┐ ┌──────┴──────┐ │FabAuthManager│ │ OIDCManager │ │CustomManager│ │(FAB Provider)│ │ (未来扩展) │ │ (自定义) │ └──────────────┘ └──────────────┘ └─────────────┘2. BaseAuthManager:核心抽象接口
2.1 类定义与泛型设计
# airflow-core/src/airflow/api_fastapi/auth/managers/base_auth_manager.pyT=TypeVar("T",bound=BaseUser)classBaseAuthManager(Generic[T],LoggingMixin,metaclass=ABCMeta):""" Class to derive in order to implement concrete auth managers. Auth managers are responsible for any user management related operation such as login, logout, authz, ... """BaseAuthManager是泛型类,类型参数T约束为BaseUser的子类。这意味着不同的 Auth Manager 可以使用不同的用户模型(FAB 使用User,OIDC 可能使用自定义OIDCUser)。
2.2 BaseUser 接口
# airflow-core/src/airflow/api_fastapi/auth/managers/models/base_user.pyclassBaseUser:"""User model interface."""@abstractmethoddefget_id(self)->str:...@abstractmethoddefget_name(self)->str:...仅要求两个方法:get_id()返回用户唯一标识,get_name()返回用户显示名。这种极简接口保证了最大兼容性。
2.3 资源粒度的授权方法
BaseAuthManager 为每种 Airflow 资源定义了独立的抽象授权方法:
@abstractmethoddefis_authorized_configuration(self,*,method:ResourceMethod,user:T,details:ConfigurationDetails|None=None)->bool:...@abstractmethoddefis_authorized_connection(self,*,method:ResourceMethod,user:T,details:ConnectionDetails|None=None)->bool:...@abstractmethoddefis_authorized_dag(self,*,method:ResourceMethod,user:T,access_entity:DagAccessEntity|None=None,details:DagDetails|None=None)->bool:...@abstractmethoddefis_authorized_asset(self,*,method:ResourceMethod,user:T,details:AssetDetails|None=None)->bool:...@abstractmethoddefis_authorized_pool(self,*,method:ResourceMethod,user:T,details:PoolDetails|None=None)->bool:...@abstractmethoddefis_authorized_variable(self,*,method:ResourceMethod,user:T,details:VariableDetails|None=None)->bool:...@abstractmethoddefis_authorized_view(self,*,access_view:AccessView,user:T)->bool:...每个方法接收三个核心参数:
- method(
ResourceMethod):HTTP 方法,即GET、POST、PUT、DELETE - user:当前用户对象
- details:资源的具体标识信息(如
conn_id、dag_id等)
2.4 ResourceMethod 与 ExtendedResourceMethod
classResourceMethod(str,Enum):"""HTTP methods (actions) a user can perform against a resource."""GET="GET"POST="POST"PUT="PUT"DELETE="DELETE"classExtendedResourceMethod(str,Enum):"""Extended HTTP methods including MENU for UI resource authorization."""GET="GET"POST="POST"PUT="PUT"DELETE="DELETE"MENU="MENU"# 菜单项可见性权限MENU是一个特殊的"方法",仅用于控制 Web UI 中菜单项的可见性。
2.5 资源详情模型
每种资源都有对应的 Details dataclass,携带资源标识和 Team 归属信息:
# airflow-core/src/airflow/api_fastapi/auth/managers/models/resource_details.py@dataclassclassDagDetails:id:str|None=Noneteam_name:str|None=None@dataclassclassConnectionDetails:conn_id:str|None=Noneteam_name:str|None=None@dataclassclassPoolDetails:name:str|None=Noneteam_name:str|None=None@dataclassclassVariableDetails:key:str|None=Noneteam_name:str|None=None@dataclassclassTeamDetails:name:str|None=Noneteam_name字段在所有资源 Details 中都存在,这是 Multi-Team 设计的基础——每个资源可以归属于一个 Team,授权时需要考虑用户是否属于该 Team。
2.6 DAG 访问实体细粒度
DAG 是 Airflow 中最复杂的资源,其子实体也需要独立的权限控制:
classDagAccessEntity(Enum):"""Enum of Dag entities the user tries to access."""AUDIT_LOG="AUDIT_LOG"# 审计日志CODE="CODE"# DAG 源码DEPENDENCIES="DEPENDENCIES"# 依赖关系HITL_DETAIL="HITL_DETAIL"# 人机协作详情RUN="RUN"# DAG RunTASK="TASK"# 任务定义TASK_INSTANCE="TASK_INSTANCE"# 任务实例TASK_LOGS="TASK_LOGS"# 任务日志VERSION="VERSION"# DAG 版本WARNING="WARNING"# DAG 警告XCOM="XCOM"# XCom 数据这意味着你可以配置用户只能查看某个 DAG 的运行日志,但不能查看源码或修改调度参数。
2.7 Multi-Team 初始化验证
classBaseAuthManager(Generic[T],LoggingMixin,metaclass=ABCMeta):definit(self)->None:"""Run operations when Airflow is initializing."""ifconf.getboolean("core","multi_team"):am_teams=self._get_teams()db_teams=Team.get_all_team_names()ifnotdb_teams.issuperset(am_teams):raiseValueError(f"Teams defined in the auth manager ({am_teams}) "f"are not present in the database ({db_teams}).")在多团队模式下,启动时验证 Auth Manager 中定义的所有 Team 都已在数据库中注册。
3. FAB Auth Manager:RBAC 权限实现
3.1 FAB 的定位
FAB(Flask-AppBuilder)Auth Manager 是 Airflow 默认的认证/授权实现,提供了基于角色的访问控制(RBAC):
# providers/fab/src/airflow/providers/fab/auth_manager/fab_auth_manager.pyclassFabAuthManager(BaseAuthManager[User]):""" Flask-AppBuilder auth manager. This auth manager is responsible for providing a backward compatible user management experience to users. """cache:TTLCache