K8s部署Airflow AD认证正常 调用REST API返回401如何解决

Airflow 2.x版本默认的airflow.api.auth.backend.basic_auth认证后端仅校验Airflow元数据库ab_user表中存储的本地用户密码哈希，不会自动复用Web端配置的AD/LDAP身份认证逻辑。
Web端AD登录正常，是因为Web登录链路单独加载了FAB（Flask App Builder）的LDAP认证模块，和API层的basic_auth校验链路完全独立：AD用户首次Web登录时，Airflow只会同步用户基础信息到元数据库，不会同步存储AD密码，因此API层拿请求里的AD密码和本地存储的无效哈希比对，必然返回401，这也是非LDAP环境下相同请求能正常调用、LDAP环境下校验失败的核心原因。

方案1：切换为支持LDAP校验的API认证后端（推荐，保持账号密码调用方式不变） #

1. 先确认Airflow运行环境已安装LDAP provider依赖，在Airflow Pod内执行以下命令校验：

   pip list | grep apache-airflow-providers-ldap
   

   如果没有返回对应包信息，先执行pip install apache-airflow-providers-ldap安装，注意安装的provider版本要和当前Airflow版本兼容。
2. 修改API认证后端配置，将[api]段下的auth_backends替换为LDAP适配的basic auth后端：

   [api]
   auth_backends = airflow.providers.ldap.auth.backends.basic_auth
   

   K8s部署注意：如果是通过官方Helm chart部署，不要直接挂载修改airflow.cfg，优先通过Helm values的config字段配置，或直接设置环境变量AIRFLOW__API__AUTH_BACKENDS=airflow.providers.ldap.auth.backends.basic_auth，避免配置被Helm默认值覆盖。

3. 确认[ldap]配置段的所有AD参数和Web端使用的配置完全一致，重点校验以下参数：
   • bind_user、bind_password：LDAP查询绑定账号的完整DN和密码
   • base_filter：AD用户搜索过滤规则
   • user_name_attr：AD中对应用户登录名的属性，AD场景通常为sAMAccountName
   • search_scope：LDAP用户搜索范围
4. 滚动重启所有Airflow组件（webserver、scheduler、worker），确保所有实例加载到新配置。
5. 重新发起请求测试：Basic Auth中填写的用户名和Web端AD登录的用户名保持完全一致，不要加DOMAIN\前缀、不要填邮箱地址。

方案2：使用API Token认证（无需调整LDAP配置，适合服务间固定调用） #

如果不想修改现有认证链路，可以直接为AD账号生成长期API Token，绕开密码校验逻辑：

1. 用AD账号正常登录Airflow Web端
2. 点击右上角个人头像，进入「API Tokens」页面，点击「Create Token」
3. 设置Token有效期、绑定对应权限后生成，复制保存生成的Token值（Token仅在生成时展示一次，丢失需要重新生成）
4. 调用API时不再使用Basic Auth传账号密码，改为在请求头中携带认证信息：

   Authorization: Bearer <替换为你生成的Token值>
   

   该方式完全兼容现有配置，不需要重启服务，权限粒度可控，适合生产环境服务调用场景。

如果调整配置后仍然返回401，按以下顺序校验：

• 在Airflow Pod内执行airflow config get-value api auth_backends，确认返回值和你配置的后端完全一致，没有被环境变量或其他配置源覆盖
• 查看webserver日志，搜索ldap、auth关键字，确认LDAP连接无报错（常见问题为LDAP服务网络不通、绑定账号密码错误、用户搜索规则匹配不到请求的账号）
• 确认请求中的Basic Auth头没有被网关、Ingress层篡改，部分Ingress默认会剥离Authorization头，导致请求到Airflow时没有携带认证信息
• 确认调用的账号在Airflow中已经分配了对应API的访问权限，权限不足也可能返回401类错误

内容的提问来源于stack exchange，提问作者Heitor Magaldi