Secrets Backend 是什么
默认情况下 Airflow 把 Connection 与 Variable 存在自己元数据库的表中，凭据与业务数据混在一起，轮换与审计都不方便。Secrets Backend 让这些值改从外部密钥系统读取：HashiCorp Vault、云厂商密钥管理（AWS Secrets Manager、GCP Secret Manager、Azure Key Vault）或 Kubernetes Secret。按约定路径命名（connections/<conn_id>、variables/<key>）后，凭据可以集中在外部系统里做轮换与权限控制，Airflow 侧只保留引用。
基本信息
| 适用版本 | Airflow 2.x 起支持多种 secrets backends |
|---|---|
| 常见后端 | Vault、云密钥管理服务、K8s Secrets、环境变量 |
| 命名约定 | connections/<conn_id>、variables/<key> |
| 配置位置 | airflow.cfg 的 [secrets] 段或对应环境变量 |
| 回退行为 | 本地元数据库仍可作为后备来源，按后端顺序查找 |
典型使用场景
- 数据库密码、API Token 需要按合规要求集中管理与定期轮换
- 多环境（开发、预发、生产）共用一套 DAG 代码，凭据从环境对应的密钥系统读取
- 权限收紧：只授权运维角色能看凭据，开发人员只能引用连接名
- 审计要求：凭据的读取与变更需要在密钥系统里留有日志
- 容器化部署下用 K8s Secret 挂载，避免凭据写进镜像或配置文件
Vault 后端配置示意
Vault 后端配置示意
[secrets]
backend = airflow.providers.hashicorp.secrets.vault.VaultBackend
backend_kwargs = {"connections_path": "connections", "variables_path": "variables", "url": "http://vault:8200", "auth_type": "token"}
# 说明：示例用 token 认证便于本地验证；
# 生产建议改用 AppRole 或 Kubernetes 认证方式，避免长期令牌硬编码
# 多个后端可叠加，按配置顺序依次查找，先命中者生效后端选择对照
| 后端 | 适用 | 注意点 |
|---|---|---|
| HashiCorp Vault | 自建密钥平台 | 需维护 Vault 自身的高可用与解封 |
| 云密钥管理 | 已上云团队 | 按云厂商计费与调用配额 |
| K8s Secrets | 容器化部署 | 需注意 Secret 的 RBAC 与 etcd 加密 |
| 环境变量 | 过渡方案 | 进程可见，不适合长期承载敏感凭据 |
切换后端前先确认 DAG 里没有硬编码凭据：只是把存储位置换了，泄漏点还在代码里，等于没解决问题。
backend_kwargs 里写 token 明文，等于把问题从元数据库搬到配置文件；凭据本身也要用环境变量或平台注入的方式提供。
多个后端叠加时查找顺序很重要：先命中的生效，顺序没理清时读到的值可能来自意料之外的后端，排查凭据问题时先确认这一点。