访问 Cloud Composer 的 Airflow Rest 时收到 HTTP 401 API
Receiving HTTP 401 when accessing Cloud Composer's Airflow Rest API
我正在尝试通过 Python 脚本从 Cloud Composer 版本 1 调用 Airflow 2.0 的 Stable REST API，并在引用 [= 时遇到 HTTP 401 错误16=].
服务帐户具有以下权限列表：
roles/iam.serviceAccountUser（服务帐户用户）roles/composer.user（作曲家用户）roles/iap.httpsResourceAccessor（IAP 安全 Web 应用程序用户，在应用程序返回 403 时添加，这很不寻常，因为指南没有指定需要这样的权限）
我不确定我的配置有什么问题；我已尝试为服务帐户授予编辑角色和 roles/iap.tunnelResourceAccessor（IAP 安全隧道用户）和 roles/composer.admin（作曲家管理员），但无济于事。
编辑：
我找到了问题的根源：Airflow 数据库没有用户 table 中服务帐户的凭据。但是，这很不寻常，因为我目前有一个服务帐户（我创建的第一个帐户），其详细信息已自动添加到 table。当用户 table 最初尝试访问 REST API 时，未将后续服务帐户添加到用户 API，从而返回 401。自 Airflow Web 服务器以来，我不确定如何创建没有密码的用户受 IAP 保护。
ewertonvsilva 的解决方案对我有用（使用 gcloud composer environments run <instance-name> --location=<location> users -- create ... 手动将服务帐户添加到 Airflow）
起初它不起作用，但将用户名更改为 accounts.google.com:<service_accounts_uid> 使其起作用。
抱歉没有评论，信誉不够。
根据@Adrien 的 Bennadji 反馈，我发布了最终答案。
为 cloud composer 创建具有适当权限的服务帐户；
通过gcloud控制台，手动添加airflow数据库中的用户：
gcloud composer environments run <instance-name> --location=<location> users -- create --use-random-password --username "accounts.google.com:<service_accounts_uid>" --role Op --email <service-account-username>@<...>.iam.gserviceaccount.com -f Service -l Account
然后，列出用户：gcloud composer environments run <env_name> --location=<env_loc> users -- list
使用：accounts.google.com:
感谢@Adrie Bennadji 和@ewertonvsilva 发布的答案，我能够诊断出 HTTP 401 问题。
Airflow 的一些数据库表中与用户相关的电子邮件字段限制为 64 个字符（类型：character varying(64)），如以下所述：Understanding the Airflow Metadata Database
巧合的是，我的第一个服务帐户有一封字符长度刚好超过 64 个字符的电子邮件。
当我尝试 运行 命令：gcloud composer environments run <instance-name> --location=<location> users -- create --use-random-password --username "accounts.google.com:<service_accounts_uid>" --role Op --email <service-account-username>@<...>.iam.gserviceaccount.com -f Service -l Account 按照@ewertonvsilva 的建议添加我的其他服务帐户时，它们失败并出现以下错误：(psycopg2.errors.StringDataRightTruncation) value too long for type character varying(64).
因此，我使用较短的电子邮件创建了新的服务帐户，并且这些帐户能够自动进行身份验证。我还能够通过 gcloud 命令手动将这些具有较短电子邮件的新服务帐户添加到 Airflow 并对其进行身份验证。此外，我发现第一次访问 REST API 时添加用户失败实际上记录在 Cloud Logging 中。但是，当时我并不知道 Cloud Composer 如何处理新用户访问 REST API 并且 HTTP 401 错误是一个转移注意力的问题。
因此，解决方案是确保您的服务帐户的电子邮件的总长度小于 64 个字符。
正在从
复制我的答案
看起来不是用
创建 Airflow 帐户
gcloud composer environments run
您可以只使用电子邮件长度 <64 个符号的 GCP 服务帐户。
它会在这些条件下自动工作：
TL'DR 版本：
为了使 Airflow 稳定 API 在 GCP Composer 工作：
- 将“api-auth_backend”设置为“airflow.composer.api.backend.composer_auth”
- 确保您的服务帐户电子邮件长度小于 64 个符号
- 确保您的服务帐户具有所需的权限（Composer 用户角色应该足够）
长读：
我们使用 Airflow 有一段时间了，从 1.x.x 版本开始，带有“实验性”（现已弃用）API。
为了授权，我们使用通过服务帐户获得的“Bearer”令牌：
# Obtain an OpenID Connect (OIDC) token from metadata server or using service account.
google_open_id_connect_token = id_token.fetch_id_token(Request(), client_id)
# Fetch the Identity-Aware Proxy-protected URL, including an
# Authorization header containing "Bearer " followed by a
# Google-issued OpenID Connect token for the service account.
resp = requests.request(
method, url,
headers={'Authorization': 'Bearer {}'.format(
google_open_id_connect_token)}, **kwargs)
现在我们正在迁移到 Airflow 2.x.x 并面临完全相同的问题：
403 禁止.
我们的环境详细信息是：
composer-1.17.3-airflow-2.1.2（Google云平台）
"api-auth_backend" 设置为 "airflow.api.auth.backend.default"。
Documentation 声称：
将 api-auth_backend 配置选项设置为 airflow.api.auth.backend.default 后，Airflow 网络服务器接受所有 API 请求而不进行身份验证。
然而，这似乎不是真的。
在实验中，我们发现如果“api-auth_backend”设置为”airflow.composer.api.backend.composer_auth”，Stable REST API (Airflow 2.X.X) 开始工作。
但对此还有其他警告：对我们来说，我们的一些服务帐户确实有效，而另一些则没有。
那些不起作用的是抛出“401 Unauthorized”错误。
我们发现电子邮件长度大于 64 个符号的帐户会抛出错误。同样观察到 .
所以在将“api-auth_backend”设置为 “airflow.composer.api.backend.composer_auth” 并确保我们的 服务帐户电子邮件长度 <64 symbols - 我们用于 Airflow 1.x.x 的旧代码开始用于身份验证。然后我们需要进行更改（API URL 和响应处理）和稳定的 Airflow (2.x.x) API 开始为我们工作
与 Airflow 1.x.x.
的方式相同
UPD：这是 Airflow 中的一个缺陷，将在此处修复：
https://github.com/apache/airflow/pull/19932
我正在尝试通过 Python 脚本从 Cloud Composer 版本 1 调用 Airflow 2.0 的 Stable REST API，并在引用 [= 时遇到 HTTP 401 错误16=].
服务帐户具有以下权限列表：
roles/iam.serviceAccountUser（服务帐户用户）roles/composer.user（作曲家用户）roles/iap.httpsResourceAccessor（IAP 安全 Web 应用程序用户，在应用程序返回 403 时添加，这很不寻常，因为指南没有指定需要这样的权限）
我不确定我的配置有什么问题；我已尝试为服务帐户授予编辑角色和 roles/iap.tunnelResourceAccessor（IAP 安全隧道用户）和 roles/composer.admin（作曲家管理员），但无济于事。
编辑： 我找到了问题的根源：Airflow 数据库没有用户 table 中服务帐户的凭据。但是，这很不寻常，因为我目前有一个服务帐户（我创建的第一个帐户），其详细信息已自动添加到 table。当用户 table 最初尝试访问 REST API 时，未将后续服务帐户添加到用户 API，从而返回 401。自 Airflow Web 服务器以来，我不确定如何创建没有密码的用户受 IAP 保护。
ewertonvsilva 的解决方案对我有用（使用 gcloud composer environments run <instance-name> --location=<location> users -- create ... 手动将服务帐户添加到 Airflow）
起初它不起作用，但将用户名更改为 accounts.google.com:<service_accounts_uid> 使其起作用。
抱歉没有评论，信誉不够。
根据@Adrien 的 Bennadji 反馈，我发布了最终答案。
为 cloud composer 创建具有适当权限的服务帐户；
通过gcloud控制台，手动添加airflow数据库中的用户：
gcloud composer environments run <instance-name> --location=<location> users -- create --use-random-password --username "accounts.google.com:<service_accounts_uid>" --role Op --email <service-account-username>@<...>.iam.gserviceaccount.com -f Service -l Account然后，列出用户：
gcloud composer environments run <env_name> --location=<env_loc> users -- list
使用：accounts.google.com:
感谢@Adrie Bennadji 和@ewertonvsilva 发布的答案，我能够诊断出 HTTP 401 问题。
Airflow 的一些数据库表中与用户相关的电子邮件字段限制为 64 个字符（类型：character varying(64)），如以下所述：Understanding the Airflow Metadata Database
巧合的是，我的第一个服务帐户有一封字符长度刚好超过 64 个字符的电子邮件。
当我尝试 运行 命令：gcloud composer environments run <instance-name> --location=<location> users -- create --use-random-password --username "accounts.google.com:<service_accounts_uid>" --role Op --email <service-account-username>@<...>.iam.gserviceaccount.com -f Service -l Account 按照@ewertonvsilva 的建议添加我的其他服务帐户时，它们失败并出现以下错误：(psycopg2.errors.StringDataRightTruncation) value too long for type character varying(64).
因此，我使用较短的电子邮件创建了新的服务帐户，并且这些帐户能够自动进行身份验证。我还能够通过 gcloud 命令手动将这些具有较短电子邮件的新服务帐户添加到 Airflow 并对其进行身份验证。此外，我发现第一次访问 REST API 时添加用户失败实际上记录在 Cloud Logging 中。但是，当时我并不知道 Cloud Composer 如何处理新用户访问 REST API 并且 HTTP 401 错误是一个转移注意力的问题。
因此，解决方案是确保您的服务帐户的电子邮件的总长度小于 64 个字符。
正在从
复制我的答案看起来不是用
创建 Airflow 帐户gcloud composer environments run
您可以只使用电子邮件长度 <64 个符号的 GCP 服务帐户。
它会在这些条件下自动工作：
TL'DR 版本：
为了使 Airflow 稳定 API 在 GCP Composer 工作：
- 将“api-auth_backend”设置为“airflow.composer.api.backend.composer_auth”
- 确保您的服务帐户电子邮件长度小于 64 个符号
- 确保您的服务帐户具有所需的权限（Composer 用户角色应该足够）
长读：
我们使用 Airflow 有一段时间了，从 1.x.x 版本开始，带有“实验性”（现已弃用）API。
为了授权，我们使用通过服务帐户获得的“Bearer”令牌：
# Obtain an OpenID Connect (OIDC) token from metadata server or using service account.
google_open_id_connect_token = id_token.fetch_id_token(Request(), client_id)
# Fetch the Identity-Aware Proxy-protected URL, including an
# Authorization header containing "Bearer " followed by a
# Google-issued OpenID Connect token for the service account.
resp = requests.request(
method, url,
headers={'Authorization': 'Bearer {}'.format(
google_open_id_connect_token)}, **kwargs)
现在我们正在迁移到 Airflow 2.x.x 并面临完全相同的问题： 403 禁止.
我们的环境详细信息是：
composer-1.17.3-airflow-2.1.2（Google云平台）
"api-auth_backend" 设置为 "airflow.api.auth.backend.default"。
Documentation 声称：
将 api-auth_backend 配置选项设置为 airflow.api.auth.backend.default 后，Airflow 网络服务器接受所有 API 请求而不进行身份验证。
然而，这似乎不是真的。
在实验中，我们发现如果“api-auth_backend”设置为”airflow.composer.api.backend.composer_auth”，Stable REST API (Airflow 2.X.X) 开始工作。
但对此还有其他警告：对我们来说，我们的一些服务帐户确实有效，而另一些则没有。
那些不起作用的是抛出“401 Unauthorized”错误。
我们发现电子邮件长度大于 64 个符号的帐户会抛出错误。同样观察到
所以在将“api-auth_backend”设置为 “airflow.composer.api.backend.composer_auth” 并确保我们的 服务帐户电子邮件长度 <64 symbols - 我们用于 Airflow 1.x.x 的旧代码开始用于身份验证。然后我们需要进行更改（API URL 和响应处理）和稳定的 Airflow (2.x.x) API 开始为我们工作 与 Airflow 1.x.x.
的方式相同UPD：这是 Airflow 中的一个缺陷，将在此处修复： https://github.com/apache/airflow/pull/19932