Apache Airflow 集成 AWS Secrets Backend 实战Secrets Manager 与 SSM Parameter Store 完整配置指南【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow在 Apache Airflow 中连接Connection、变量Variable与部分配置Config默认存储在元数据库或本地airflow.cfg中存在明文泄露与难以集中管理的风险。本指南基于当前仓库中providers/amazon的官方文档secrets-backends 索引、AWS Secrets Manager 文档、AWS SSM Parameter Store 文档展开完整讲解如何通过 SecretsManagerBackend 与 SystemsManagerParameterStoreBackend 将密钥托管到 AWS。读完本文你将能够完成两种后端的airflow.cfg配置、以 URI 或 JSON 两种形态存取 Connection 与 Variable、按前缀/正则精细控制查询范围并理解多团队multi-team模式下密钥的命名隔离规则。一、Airflow Secrets Backend 机制概述Airflow 的 BaseSecretsBackend 抽象定义了统一的密钥读取接口get_conn_value连接、get_variable变量、get_config配置。任何后端只需实现这三个方法就能接入 Airflow 的密钥解析链。providers/amazon提供了两个基于 AWS 的实现后端类完整类路径对应 AWS 服务AWS Secrets Managerairflow.providers.amazon.aws.secrets.secrets_manager.SecretsManagerBackendSecrets Manager适合存密钥支持自动轮换、JSON 多字段存储AWS SSM Parameter Storeairflow.providers.amazon.aws.secrets.systems_manager.SystemsManagerParameterStoreBackendSystems Manager Parameter Store适合存参数与配置按层级路径组织两个后端都继承自BaseSecretsBackend与LoggingMixin并通过airflow.cfg的[secrets]段统一启用。从源码看两者的客户端构造逻辑完全一致都通过SessionFactory与AwsConnectionWrapperbase_aws.py按传入的backend_kwargs创建 boto3 客户端Secrets Manager 客户端见 secrets_manager.pySSM 客户端见 systems_manager.py因此额外的认证参数会原样透传给 boto3。二、启用 AWS Secrets Manager 后端2.1 最小配置在airflow.cfg的[secrets]段指定backend为SecretsManagerBackend并通过backend_kwargs传入前缀参数[secrets] backend airflow.providers.amazon.aws.secrets.secrets_manager.SecretsManagerBackend backend_kwargs { connections_prefix: airflow/connections, connections_lookup_pattern: null, variables_prefix: airflow/variables, variables_lookup_pattern: null, config_prefix: airflow/config, config_lookup_pattern: null, profile_name: default }要点说明backend_kwargs以 JSON 解析文档明确指出 Thesebackend_kwargsare parsed as JSON因此 JSON 不支持的 Python 值如False、None会被忽略相关参数将回退到后端的默认值。请务必使用 JSON 语法null而不是 Python 的None。前缀默认值从 secrets_manager.py 的构造函数可见三个前缀的默认值分别是airflow/connections、airflow/variables、airflow/config构造时会用分隔符sep默认/对非空前缀执行rstrip避免结尾多余斜杠造成路径拼接错误。认证方式二选一可以在backend_kwargs中提供 AWS 连接 Extra 配置 中列出的参数如region_name、profile_name、role_arn也可以依赖 AWS 标准环境变量AWS_ACCESS_KEY_ID等由 boto3 自动完成认证。2.2 使用 IAM Role 认证STS 场景在 Kubernetes 或 ECS 等以 IAM Role 交付凭证的环境中推荐通过role_arn指定角色[secrets] backend airflow.providers.amazon.aws.secrets.secrets_manager.SecretsManagerBackend backend_kwargs { connections_prefix: airflow/connections, variables_prefix: airflow/variables, config_prefix: airflow/config, role_arn: arn:aws:iam::123456789098:role/role-name }该参数会随其余 kwargs 传入AwsConnectionWrapper由底层SessionFactory完成角色代入。三、在 Secrets Manager 中存取 Connection文档给出了两种存储形态二者在源码get_conn_valuesecrets_manager.py中被分别处理。3.1 方式一存储为 Connection URI将完整的 Airflow Connection URI如postgresql://user:passhost:5432/db作为 SecretString 存入所有字段都被视为已 URL 编码。例如密码my password必须写成my%20password否则含空格或特殊字符的字段会在解析时出错。3.2 方式二存储为 JSON多字段Secrets Manager 原生支持键值结构Airflow 会按字段名自动识别连接组件并允许使用别名连接组件允许的字段名别名conn_typeconn_type、conn_id、connection_type、engineloginlogin、user、username、user_namepasswordpassword、pass、keyhosthost、remote_host、serverportportschemadatabase、schemaextraextra必须是合法 JSON 字符串这张别名表与源码中的possible_words_for_conn_fieldssecrets_manager.py完全对应且支持通过配置参数extra_conn_words扩展。该参数必须是 dict of lists可选键为user、password、host、schema、conn_type其中user会向后兼容地映射到loginextra_conn_words: {password: [passwd, pwd], host: [endpoint]}当读取到的 SecretString 以{开头时后端会执行json.loads→ 键标准化 →json.dumps的流程源码注释说明这是为了兼容 Airflow 2.3 之前 Secrets Manager 后端的 JSON 别名行为再交给 Airflow 核心解析。3.3 端到端示例存入并通过 CLI 验证假设配置了connections_prefix airflow/connections为连接smtp_default创建密钥aws secretsmanager put-secret-value \ --secret-id airflow/connections/smtp_default \ --secret-string {login: nice_user, password: this_is_the_password, host: ec2.8399.com, port: 999}验证密钥确实存在❯ aws secretsmanager get-secret-value --secret-id airflow/connections/smtp_default { ARN: arn:aws:secretsmanager:us-east-2:314524341751:secret:airflow/connections/smtp_default-7meuul, Name: airflow/connections/smtp_default, VersionId: 34f90eff-ea21-455a-9c8f-5ee74b21be672, SecretString: {\n \login\:\nice_user\,\n \password\:\this_is_the_password\\n,\n \host\:\ec2.8399.com\\n,\n \port\:\999\\n}\n, VersionStages: [AWSCURRENT], CreatedDate: 2020-04-08T02:10:35.13200001:00 }此时 DAG 中通过Connection.get_conn(smtp_default)或连接 ID 引用即可从 Secrets Manager 解析无需在 Airflow UI 中维护明文。若不想使用任何前缀将connections_prefix设为空字符串即可源码会跳过rstrip直接以完整 secret id 查询。3.4 特殊场景把 Google Cloud 连接存入 Secrets Manager对于 Google Cloud 等第三方连接所有参数都放在extra字段中例如使用服务账号密钥文件{extra: {key_path: /opt/airflow/service_account.json, scope: https://www.googleapis.com/auth/devstorage.read_only}}或使用密钥字典直接把服务账号 JSON 粘贴进来{extra: {keyfile_dict: copy paste the service account json here, scope: https://www.googleapis.com/auth/devstorage.read_only}}两种方式都可以直接在 AWS 控制台的 Key/value 界面编辑最终都表现为extra字段内的合法 JSON。四、在 Secrets Manager 中存取 Variable 与 Config与 Connection 同理variables_prefix决定 Variable 的查找路径。若配置为airflow/variables则 Variablehello对应密钥airflow/variables/hello后端在get_variablesecrets_manager.py中按该路径拼接查询。config_prefix则允许把 Airflow 配置项如sql_alchemy_conn也托管到 Secrets Manager密钥airflow/config/sql_alchemy_conn会被映射为配置项sql_alchemy_conn见类 docstring 中的示例secrets_manager.py适用于不希望把元数据库连接串写进airflow.cfg的场景。五、可选查询控制前缀排除与正则匹配5.1 用null前缀排除某一类查询Connections、Variables、Config 三者可以独立启用/禁用禁用后 Airflow完全不会向 AWS 发送该类请求源码中三个 getter 的第一行都是if xxx_prefix is None: return None。例如只想用 Secrets Manager 查 Connection[secrets] backend airflow.providers.amazon.aws.secrets.secrets_manager.SecretsManagerBackend backend_kwargs { connections_prefix: airflow/connections, variables_prefix: null, config_prefix: null, profile_name: default }5.2 用*_lookup_pattern只查询匹配正则的 ID*_lookup_pattern接收正则字符串只有匹配的连接/变量/配置才会触发 AWS 查询其余回落本地。例如只查询以 m 开头的连接[secrets] backend airflow.providers.amazon.aws.secrets.secrets_manager.SecretsManagerBackend backend_kwargs { connections_prefix: airflow/connections, connections_lookup_pattern: ^m, profile_name: default }从源码看模式匹配使用re.match(lookup_pattern, secret_id, re.IGNORECASE)secrets_manager.py即从开头匹配且忽略大小写。该正则仅在*_prefix非空时生效。六、启用 AWS SSM Parameter Store 后端6.1 最小配置SSM 后端的配置结构与 Secrets Manager 完全对称只需更换backend类路径[secrets] backend airflow.providers.amazon.aws.secrets.systems_manager.SystemsManagerParameterStoreBackend backend_kwargs { connections_prefix: airflow/connections, connections_lookup_pattern: null, variables_prefix: airflow/variables, variables_lookup_pattern: null, config_prefix: airflow/config, config_lookup_pattern: null, profile_name: default }认证方式与 Secrets Manager 相同既可以提供 AWS 连接 Extra 配置 中的参数如下面的role_arn也可以依赖 boto3 环境变量[secrets] backend airflow.providers.amazon.aws.secrets.systems_manager.SystemsManagerParameterStoreBackend backend_kwargs { connections_prefix: airflow/connections, variables_prefix: airflow/variables, config_prefix: airflow/config, role_arn: arn:aws:iam::123456789098:role/role-name }6.2 与 Secrets Manager 的两处关键差异路径规范要求前导斜杠源码中的_ensure_leading_slashsystems_manager.py会为 SSM 路径动态补上/因为 AWS Systems Manager 强制要求参数路径以/开头。因此官方示例中的前缀通常写作/airflow/connections风格。取值逻辑不同SSM 后端通过get_parameter(Namessm_path, WithDecryptionTrue)获取参数值systems_manager.py即默认启用解密适合配合 KMS 加密的 SecureString 类型参数未命中时捕获ParameterNotFound返回None不会抛异常中断 DAG。6.3 SSM 中的连接存储格式SSM 参数值必须是 Connection URI 表示 或连接的 JSON 格式之一。若配置了connections_prefix /airflow/connections连接smtp_default就存储在/airflow/connections/smtp_default。URI 形态的双协议陷阱HTTP(S)、SPARK 等连接的 URI 并不直观——URI 的 scheme 与连接的实际协议是相互独立的两部分必要时必须显式写出例如http://https%3A%2F%2Fexample.com spark://spark%3A%2F%2Fspark-main-0.spark-main.spark:7077同样的连接用 JSON 对象表示则清晰得多{conn_type: http, host: https://example.com} {conn_type: spark, host: spark://spark-main-0.spark-main.spark, port: 7077}6.4 Variable 与 Config 的存储配置variables_prefix /airflow/variables后Variablehello对应参数/airflow/variables/hello。SSM 后端同样支持config_prefix把 Airflow 配置项托管为 SSM 参数。profile_name可用于引用~/.aws/config中定义的 AWS 配置文件。七、多团队Multi-Team支持与跨团队隔离两个后端均支持多团队模式团队范围的密钥使用--作为团队名与密钥 ID 的分隔符。例如团队marketing拥有的连接smtp_default存储在airflow/connections/marketing--smtp_default变量hello存储在airflow/variables/marketing--helloSSM 侧对应/airflow/connections/marketing--smtp_default。查找顺序任务作者仍按普通 IDsmtp_default请求密钥后端会先尝试团队作用域路径{team_name}--{secret_id}未命中再回退到全局路径airflow/connections/smtp_default。该逻辑在 secrets_manager.py 与 systems_manager.py 中均可见。安全约束文档与源码都强调——在启用多团队模式core.multi_team True后任何包含--的连接 ID / Variable 键都被视为保留命名空间无团队上下文的请求若使用形如team--name的键会直接返回None防止跨团队读取见_names_a_team_namespace与_log_refusal的实现secrets_manager.py团队 A 的调用者也无法通过显式命名读取团队 B 的密钥。这些行为都有对应的单元测试验证例如 test_secrets_manager.py 中的test_get_conn_value_with_team_name、test_global_caller_cannot_access_team_scoped_connection、test_another_teams_secret_is_not_reachable分别覆盖团队作用域命中、全局调用者无法访问团队密钥、跨团队不可达三个场景。八、后端选择建议与实战小结对比维度Secrets Manager 后端SSM Parameter Store 后端典型用途密码、API Key 等高敏密钥参数、配置项、普通密钥存储形态URI 或 JSON 多字段支持字段别名 extra_conn_words扩展URI 或 JSON 对象路径风格无前导斜杠如airflow/connections/...强制前导斜杠如/airflow/connections/...密钥特性支持自动轮换、版本阶段AWSCURRENTSecureString 配合 KMS 加密读取时WithDecryptionTrue适用场景追求密钥托管与轮换能力复用现有 SSM 参数体系、按层级路径组织部署建议先以null前缀或*_lookup_pattern正则做小范围灰度确认 DAG 解析无误后再全量切换backend_kwargs一律使用合法 JSONnull而非None优先用role_arn/ IAM Role 而非硬编码密钥并将认证参数与 AWS 连接 Extra 配置 保持一致。两种后端的源码、文档与测试均可在本仓库对应目录中继续深挖本文覆盖的两个后端类、三个 getter 方法与多团队隔离逻辑构成了理解 Airflow 云端密钥管理的最小知识闭环。【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Apache Airflow 集成 AWS Secrets Backend 实战Secrets Manager 与 SSM Parameter Store 完整配置指南【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow在 Apache Airflow 中连接Connection、变量Variable与部分配置Config默认存储在元数据库或本地airflow.cfg中存在明文泄露与难以集中管理的风险。本指南基于当前仓库中providers/amazon的官方文档secrets-backends 索引、AWS Secrets Manager 文档、AWS SSM Parameter Store 文档展开完整讲解如何通过 SecretsManagerBackend 与 SystemsManagerParameterStoreBackend 将密钥托管到 AWS。读完本文你将能够完成两种后端的airflow.cfg配置、以 URI 或 JSON 两种形态存取 Connection 与 Variable、按前缀/正则精细控制查询范围并理解多团队multi-team模式下密钥的命名隔离规则。一、Airflow Secrets Backend 机制概述Airflow 的 BaseSecretsBackend 抽象定义了统一的密钥读取接口get_conn_value连接、get_variable变量、get_config配置。任何后端只需实现这三个方法就能接入 Airflow 的密钥解析链。providers/amazon提供了两个基于 AWS 的实现后端类完整类路径对应 AWS 服务AWS Secrets Managerairflow.providers.amazon.aws.secrets.secrets_manager.SecretsManagerBackendSecrets Manager适合存密钥支持自动轮换、JSON 多字段存储AWS SSM Parameter Storeairflow.providers.amazon.aws.secrets.systems_manager.SystemsManagerParameterStoreBackendSystems Manager Parameter Store适合存参数与配置按层级路径组织两个后端都继承自BaseSecretsBackend与LoggingMixin并通过airflow.cfg的[secrets]段统一启用。从源码看两者的客户端构造逻辑完全一致都通过SessionFactory与AwsConnectionWrapperbase_aws.py按传入的backend_kwargs创建 boto3 客户端Secrets Manager 客户端见 secrets_manager.pySSM 客户端见 systems_manager.py因此额外的认证参数会原样透传给 boto3。二、启用 AWS Secrets Manager 后端2.1 最小配置在airflow.cfg的[secrets]段指定backend为SecretsManagerBackend并通过backend_kwargs传入前缀参数[secrets] backend airflow.providers.amazon.aws.secrets.secrets_manager.SecretsManagerBackend backend_kwargs { connections_prefix: airflow/connections, connections_lookup_pattern: null, variables_prefix: airflow/variables, variables_lookup_pattern: null, config_prefix: airflow/config, config_lookup_pattern: null, profile_name: default }要点说明backend_kwargs以 JSON 解析文档明确指出 Thesebackend_kwargsare parsed as JSON因此 JSON 不支持的 Python 值如False、None会被忽略相关参数将回退到后端的默认值。请务必使用 JSON 语法null而不是 Python 的None。前缀默认值从 secrets_manager.py 的构造函数可见三个前缀的默认值分别是airflow/connections、airflow/variables、airflow/config构造时会用分隔符sep默认/对非空前缀执行rstrip避免结尾多余斜杠造成路径拼接错误。认证方式二选一可以在backend_kwargs中提供 AWS 连接 Extra 配置 中列出的参数如region_name、profile_name、role_arn也可以依赖 AWS 标准环境变量AWS_ACCESS_KEY_ID等由 boto3 自动完成认证。2.2 使用 IAM Role 认证STS 场景在 Kubernetes 或 ECS 等以 IAM Role 交付凭证的环境中推荐通过role_arn指定角色[secrets] backend airflow.providers.amazon.aws.secrets.secrets_manager.SecretsManagerBackend backend_kwargs { connections_prefix: airflow/connections, variables_prefix: airflow/variables, config_prefix: airflow/config, role_arn: arn:aws:iam::123456789098:role/role-name }该参数会随其余 kwargs 传入AwsConnectionWrapper由底层SessionFactory完成角色代入。三、在 Secrets Manager 中存取 Connection文档给出了两种存储形态二者在源码get_conn_valuesecrets_manager.py中被分别处理。3.1 方式一存储为 Connection URI将完整的 Airflow Connection URI如postgresql://user:passhost:5432/db作为 SecretString 存入所有字段都被视为已 URL 编码。例如密码my password必须写成my%20password否则含空格或特殊字符的字段会在解析时出错。3.2 方式二存储为 JSON多字段Secrets Manager 原生支持键值结构Airflow 会按字段名自动识别连接组件并允许使用别名连接组件允许的字段名别名conn_typeconn_type、conn_id、connection_type、engineloginlogin、user、username、user_namepasswordpassword、pass、keyhosthost、remote_host、serverportportschemadatabase、schemaextraextra必须是合法 JSON 字符串这张别名表与源码中的possible_words_for_conn_fieldssecrets_manager.py完全对应且支持通过配置参数extra_conn_words扩展。该参数必须是 dict of lists可选键为user、password、host、schema、conn_type其中user会向后兼容地映射到loginextra_conn_words: {password: [passwd, pwd], host: [endpoint]}当读取到的 SecretString 以{开头时后端会执行json.loads→ 键标准化 →json.dumps的流程源码注释说明这是为了兼容 Airflow 2.3 之前 Secrets Manager 后端的 JSON 别名行为再交给 Airflow 核心解析。3.3 端到端示例存入并通过 CLI 验证假设配置了connections_prefix airflow/connections为连接smtp_default创建密钥aws secretsmanager put-secret-value \ --secret-id airflow/connections/smtp_default \ --secret-string {login: nice_user, password: this_is_the_password, host: ec2.8399.com, port: 999}验证密钥确实存在❯ aws secretsmanager get-secret-value --secret-id airflow/connections/smtp_default { ARN: arn:aws:secretsmanager:us-east-2:314524341751:secret:airflow/connections/smtp_default-7meuul, Name: airflow/connections/smtp_default, VersionId: 34f90eff-ea21-455a-9c8f-5ee74b21be672, SecretString: {\n \login\:\nice_user\,\n \password\:\this_is_the_password\\n,\n \host\:\ec2.8399.com\\n,\n \port\:\999\\n}\n, VersionStages: [AWSCURRENT], CreatedDate: 2020-04-08T02:10:35.13200001:00 }此时 DAG 中通过Connection.get_conn(smtp_default)或连接 ID 引用即可从 Secrets Manager 解析无需在 Airflow UI 中维护明文。若不想使用任何前缀将connections_prefix设为空字符串即可源码会跳过rstrip直接以完整 secret id 查询。3.4 特殊场景把 Google Cloud 连接存入 Secrets Manager对于 Google Cloud 等第三方连接所有参数都放在extra字段中例如使用服务账号密钥文件{extra: {key_path: /opt/airflow/service_account.json, scope: https://www.googleapis.com/auth/devstorage.read_only}}或使用密钥字典直接把服务账号 JSON 粘贴进来{extra: {keyfile_dict: copy paste the service account json here, scope: https://www.googleapis.com/auth/devstorage.read_only}}两种方式都可以直接在 AWS 控制台的 Key/value 界面编辑最终都表现为extra字段内的合法 JSON。四、在 Secrets Manager 中存取 Variable 与 Config与 Connection 同理variables_prefix决定 Variable 的查找路径。若配置为airflow/variables则 Variablehello对应密钥airflow/variables/hello后端在get_variablesecrets_manager.py中按该路径拼接查询。config_prefix则允许把 Airflow 配置项如sql_alchemy_conn也托管到 Secrets Manager密钥airflow/config/sql_alchemy_conn会被映射为配置项sql_alchemy_conn见类 docstring 中的示例secrets_manager.py适用于不希望把元数据库连接串写进airflow.cfg的场景。五、可选查询控制前缀排除与正则匹配5.1 用null前缀排除某一类查询Connections、Variables、Config 三者可以独立启用/禁用禁用后 Airflow完全不会向 AWS 发送该类请求源码中三个 getter 的第一行都是if xxx_prefix is None: return None。例如只想用 Secrets Manager 查 Connection[secrets] backend airflow.providers.amazon.aws.secrets.secrets_manager.SecretsManagerBackend backend_kwargs { connections_prefix: airflow/connections, variables_prefix: null, config_prefix: null, profile_name: default }5.2 用*_lookup_pattern只查询匹配正则的 ID*_lookup_pattern接收正则字符串只有匹配的连接/变量/配置才会触发 AWS 查询其余回落本地。例如只查询以 m 开头的连接[secrets] backend airflow.providers.amazon.aws.secrets.secrets_manager.SecretsManagerBackend backend_kwargs { connections_prefix: airflow/connections, connections_lookup_pattern: ^m, profile_name: default }从源码看模式匹配使用re.match(lookup_pattern, secret_id, re.IGNORECASE)secrets_manager.py即从开头匹配且忽略大小写。该正则仅在*_prefix非空时生效。六、启用 AWS SSM Parameter Store 后端6.1 最小配置SSM 后端的配置结构与 Secrets Manager 完全对称只需更换backend类路径[secrets] backend airflow.providers.amazon.aws.secrets.systems_manager.SystemsManagerParameterStoreBackend backend_kwargs { connections_prefix: airflow/connections, connections_lookup_pattern: null, variables_prefix: airflow/variables, variables_lookup_pattern: null, config_prefix: airflow/config, config_lookup_pattern: null, profile_name: default }认证方式与 Secrets Manager 相同既可以提供 AWS 连接 Extra 配置 中的参数如下面的role_arn也可以依赖 boto3 环境变量[secrets] backend airflow.providers.amazon.aws.secrets.systems_manager.SystemsManagerParameterStoreBackend backend_kwargs { connections_prefix: airflow/connections, variables_prefix: airflow/variables, config_prefix: airflow/config, role_arn: arn:aws:iam::123456789098:role/role-name }6.2 与 Secrets Manager 的两处关键差异路径规范要求前导斜杠源码中的_ensure_leading_slashsystems_manager.py会为 SSM 路径动态补上/因为 AWS Systems Manager 强制要求参数路径以/开头。因此官方示例中的前缀通常写作/airflow/connections风格。取值逻辑不同SSM 后端通过get_parameter(Namessm_path, WithDecryptionTrue)获取参数值systems_manager.py即默认启用解密适合配合 KMS 加密的 SecureString 类型参数未命中时捕获ParameterNotFound返回None不会抛异常中断 DAG。6.3 SSM 中的连接存储格式SSM 参数值必须是 Connection URI 表示 或连接的 JSON 格式之一。若配置了connections_prefix /airflow/connections连接smtp_default就存储在/airflow/connections/smtp_default。URI 形态的双协议陷阱HTTP(S)、SPARK 等连接的 URI 并不直观——URI 的 scheme 与连接的实际协议是相互独立的两部分必要时必须显式写出例如http://https%3A%2F%2Fexample.com spark://spark%3A%2F%2Fspark-main-0.spark-main.spark:7077同样的连接用 JSON 对象表示则清晰得多{conn_type: http, host: https://example.com} {conn_type: spark, host: spark://spark-main-0.spark-main.spark, port: 7077}6.4 Variable 与 Config 的存储配置variables_prefix /airflow/variables后Variablehello对应参数/airflow/variables/hello。SSM 后端同样支持config_prefix把 Airflow 配置项托管为 SSM 参数。profile_name可用于引用~/.aws/config中定义的 AWS 配置文件。七、多团队Multi-Team支持与跨团队隔离两个后端均支持多团队模式团队范围的密钥使用--作为团队名与密钥 ID 的分隔符。例如团队marketing拥有的连接smtp_default存储在airflow/connections/marketing--smtp_default变量hello存储在airflow/variables/marketing--helloSSM 侧对应/airflow/connections/marketing--smtp_default。查找顺序任务作者仍按普通 IDsmtp_default请求密钥后端会先尝试团队作用域路径{team_name}--{secret_id}未命中再回退到全局路径airflow/connections/smtp_default。该逻辑在 secrets_manager.py 与 systems_manager.py 中均可见。安全约束文档与源码都强调——在启用多团队模式core.multi_team True后任何包含--的连接 ID / Variable 键都被视为保留命名空间无团队上下文的请求若使用形如team--name的键会直接返回None防止跨团队读取见_names_a_team_namespace与_log_refusal的实现secrets_manager.py团队 A 的调用者也无法通过显式命名读取团队 B 的密钥。这些行为都有对应的单元测试验证例如 test_secrets_manager.py 中的test_get_conn_value_with_team_name、test_global_caller_cannot_access_team_scoped_connection、test_another_teams_secret_is_not_reachable分别覆盖团队作用域命中、全局调用者无法访问团队密钥、跨团队不可达三个场景。八、后端选择建议与实战小结对比维度Secrets Manager 后端SSM Parameter Store 后端典型用途密码、API Key 等高敏密钥参数、配置项、普通密钥存储形态URI 或 JSON 多字段支持字段别名 extra_conn_words扩展URI 或 JSON 对象路径风格无前导斜杠如airflow/connections/...强制前导斜杠如/airflow/connections/...密钥特性支持自动轮换、版本阶段AWSCURRENTSecureString 配合 KMS 加密读取时WithDecryptionTrue适用场景追求密钥托管与轮换能力复用现有 SSM 参数体系、按层级路径组织部署建议先以null前缀或*_lookup_pattern正则做小范围灰度确认 DAG 解析无误后再全量切换backend_kwargs一律使用合法 JSONnull而非None优先用role_arn/ IAM Role 而非硬编码密钥并将认证参数与 AWS 连接 Extra 配置 保持一致。两种后端的源码、文档与测试均可在本仓库对应目录中继续深挖本文覆盖的两个后端类、三个 getter 方法与多团队隔离逻辑构成了理解 Airflow 云端密钥管理的最小知识闭环。【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
