Airflow 安全模型¶

本文档从 Airflow 用户的角度描述了 Airflow 的安全模型。旨在帮助用户理解安全模型，并就如何部署和管理 Airflow 做出明智的决定。

如果您想了解如何报告安全漏洞以及 Airflow 安全团队如何处理安全报告，请访问 Airflow 安全策略。

Airflow 安全模型 - 用户类型¶

Airflow 安全模型涉及不同类型的用户，他们拥有不同的访问权限和功能

在小型安装中，与 Airflow 相关的所有操作可以由单个用户执行，但在大型安装中，显然需要分离不同的职责、角色和功能。

这就是 Airflow 具有以下用户类型的原因

部署管理员 - 全面负责 Airflow 的安装、安全和配置
已认证的 UI 用户 - 可以访问 Airflow UI 和 API 并与其交互的用户
DAG 作者 - 负责创建 DAG 并将其提交到 Airflow

您可以在架构概述中查看更多关于用户类型如何影响 Airflow 架构的信息，包括查看简单和复杂部署的图示。

部署管理员¶

他们拥有最高级别的访问权限和控制权。他们负责安装和配置 Airflow，并就技术和权限做出决定。他们可以潜在地删除整个安装并访问所有凭据。部署管理员还可以决定在 Airflow 之外保留审计、备份和信息副本，这些不属于 Airflow 安全模型的范围。

DAG 作者¶

他们可以创建、修改和删除 DAG 文件。DAG 文件中的代码在工作节点和 DAG 处理器中执行。因此，DAG 作者可以创建和更改在工作节点和 DAG 处理器上执行的代码，并可能访问 DAG 代码用于访问外部系统的凭据。DAG 作者对元数据数据库拥有完全访问权限。

已认证的 UI 用户¶

他们有权访问 UI 和 API。有关已认证 UI 用户可能拥有的功能的更多详细信息，请参见下文。

未认证的 UI 用户¶

Airflow 默认不支持未经认证的用户。如果允许，部署管理员必须评估并解决潜在漏洞。但是，这也有例外。/health 端点用于获取健康检查更新，它应该是公开可访问的。这是因为其他系统可能需要检索该信息。另一个例外是 /login 端点，因为用户在使用它时应处于未经认证的状态。

已认证 UI 用户的功能¶

已认证 UI 用户的功能可能因部署管理员或管理员用户配置的角色以及这些角色拥有的权限而异。角色权限的范围可以小至单个 DAG，例如，或大至管理员权限。以下是四个通用类别，有助于概念化已认证用户可能拥有的一些功能

管理员用户¶

他们管理并授予其他用户权限，完全访问所有 UI 功能。他们可以通过配置连接在工作节点上执行代码，因此需要信任他们不会滥用这些权限。他们可以访问敏感凭据并修改它们。默认情况下，他们无权访问系统级配置。应信任他们不会滥用通过连接配置可访问的敏感信息。他们也有能力制造 API 服务器拒绝服务的情况，因此应信任他们不会滥用此能力。

只有管理员用户可以访问审计日志。

操作员用户¶

操作员与管理员的主要区别在于管理和授予其他用户权限的能力，以及访问审计日志 - 只有管理员能够做到这一点。否则，假定他们拥有与管理员相同的访问权限。

连接配置用户¶

他们配置连接，并在 DAG 执行期间可能在工作节点上执行代码。需要信任以防止滥用这些权限。他们完全访问存储在连接中的敏感凭据并可以修改它们。应信任他们不会滥用通过连接配置可访问的敏感信息。他们也有能力错误配置连接，可能导致 API 服务器拒绝服务的情况，并指定不安全的连接选项，这可能导致在执行 DAG 时对某些提供者（无论是社区发布的还是自定义的）造成任意远程代码执行的情况。

应高度信任这些用户不会滥用此能力。

审计日志用户¶

他们可以查看整个 Airflow 安装的审计事件。

普通用户¶

他们能够查看和编辑 DAG、任务实例和 DAG 运行，并查看任务日志。

查看者用户¶

他们可以以只读方式查看与 DAG 相关的信息、任务日志和其他相关详情。此角色适用于只需要只读访问权限，而不能触发或修改 DAG 的用户。

查看者也无权访问审计日志。

有关已认证 UI 用户功能的更多信息，请参见使用 FAB 认证管理器进行访问控制。

DAG 作者的功能¶

DAG 作者能够创建或编辑代码（通过放置在 DAG 包中的 Python 文件），这些代码将在多种情况下执行。Airflow 不会验证、检查或沙盒化要执行的代码（这样做即使不是不可能也非常困难），因此实际上 DAG 作者可以在工作节点（Celery Executor 的 Celery Workers 的一部分，Local Executor 的调度器运行的本地进程，Kubernetes Executor 的任务 Kubernetes POD）、DAG 处理器和 Triggerer 中执行任意代码。

Airflow 选择的这种模型会产生一些后果，部署管理员需要了解这些后果

本地执行器¶

对于本地执行器，DAG 作者可以在调度器运行的机器上执行任意代码。这意味着他们可以影响调度器进程本身，并可能影响整个 Airflow 安装，包括修改集群范围的策略和更改 Airflow 配置。如果您使用本地执行器运行 Airflow，部署管理员必须信任 DAG 作者不会滥用此能力。

Celery 执行器¶

对于 Celery 执行器，DAG 作者可以在 Celery Workers 上执行任意代码。这意味着他们可能影响在同一工作节点上执行的所有任务。如果您使用 Celery 执行器运行 Airflow，部署管理员必须信任 DAG 作者不会滥用此能力，并且除非部署管理员通过集群策略按队列分离任务执行，否则应假定任务之间没有隔离。

Kubernetes 执行器¶

对于 Kubernetes 执行器，DAG 作者可以在其运行的 Kubernetes POD 上执行任意代码。每个任务都在一个单独的 POD 中执行，因此任务之间已经存在隔离，因为一般来说 Kubernetes 提供了 POD 之间的隔离。

触发器¶

对于触发器，DAG 作者可以在触发器中执行任意代码。目前没有强制机制可以隔离使用可延迟功能的任务，来自各种任务的任意代码可以在同一进程/机器中执行。部署管理员必须信任 DAG 作者不会滥用此能力。

调度器和 API 服务器不需要 DAG 文件¶

部署管理员可以通过确保调度器和 API 服务器无法访问 DAG 文件来隔离 DAG 作者提供的代码执行，特别是在调度器和 API 服务器中。一般来说，DAG 作者提供的代码绝不应在调度器或 API 服务器进程中执行。这意味着部署管理员可以在调度器和 API 服务器上排除 DAG 包所需的凭据 - 但这些包仍必须在这些组件上进行配置。

允许 DAG 作者在调度器和 API 服务器中执行特定代码¶

有许多功能允许 DAG 作者使用预先注册的自定义代码在调度器或 API 服务器进程中执行 - 例如，他们可以选择自定义 Timetables、UI 插件、Connection UI Fields、Operator extra links、宏、监听器 - 所有这些功能都允许 DAG 作者选择将在调度器或 API 服务器进程中执行的代码。然而，这不应该是 DAG 作者可以添加到 DAG 包中的任意代码。所有这些功能仅通过 plugins 和 providers 机制提供，其中执行的代码只能由已安装的包提供（或者对于插件，也可以添加到 PLUGINS 文件夹中，DAG 作者不应拥有该文件夹的写入权限）。PLUGINS_FOLDER 是来自 Airflow 1.10 的旧机制 - 但我们推荐使用 entrypoint 机制，它允许部署管理员有效地选择和注册将在这些上下文中执行的代码。DAG 作者无权安装或修改安装在调度器和 API 服务器中的包，这是防止 DAG 作者在这些进程中执行任意代码的方法。

此外，如果您决定使用和配置 PLUGINS_FOLDER，部署管理员必须确保 DAG 作者对该文件夹没有写入权限，这一点至关重要。

部署管理员可能决定引入额外的控制机制，以防止 DAG 作者执行任意代码。这完全由部署管理员掌控，并在以下章节中讨论。

访问所有 DAG¶

所有 DAG 作者都有权访问 Airflow 部署中的所有 DAG。这意味着他们可以随时无限制地查看、修改和更新任何 DAG。

部署管理员的职责¶

作为部署管理员，您应该了解 DAG 作者的能力，并确保您信任他们不会滥用他们拥有的能力。您还应该确保已正确配置 Airflow 安装，以防止 DAG 作者在调度器和 API 服务器进程中执行任意代码。

部署和保护 Airflow 安装¶

部署管理员还负责部署 Airflow，并以符合部署 Airflow 的组织所适用的安全部署最佳实践的方式，使其可供用户访问。这包括但不限于

使用 TLS/VPC 和部署 Airflow 的组织要求的任何网络安全措施来保护通信
应用通常用于 Web 应用程序的速率限制和其他形式的保护
对 Web 应用程序应用身份验证和授权，以便只有已知和授权的用户才能访问 Airflow
检测任何异常活动并加以保护
选择正确的会话后端并进行适当配置，包括会话超时

限制 DAG 作者的功能¶

部署管理员也可能使用额外的机制来阻止 DAG 作者执行任意代码 - 例如，他们可能引入围绕 DAG 提交的工具，以便在部署代码之前对其进行审查、进行静态检查，并添加其他方式来防止恶意代码被提交。将代码提交到 DAG 包的方式以及如何保护完全取决于部署管理员 - Airflow 不提供任何相关的工具或机制，并且期望部署管理员提供工具来保护对 DAG 包的访问，并确保只提交受信任的代码。

Airflow 本身并未实现任何这些功能，而是将其委托给部署管理员，由他们部署所有必要的基础设施来保护部署 - 作为外部基础设施组件。

限制已认证 UI 用户的访问权限¶

部署管理员还确定访问级别，并且必须了解用户可能造成的潜在损害。一些部署管理员可能会通过为已认证 UI 用户设置细粒度权限来进一步限制访问。然而，这些限制超出了 Airflow 的基本安全模型范围，由部署管理员自行决定。

细粒度访问控制的示例包括（但不限于）

限制登录权限：限制用户可以登录的账户，只允许属于特定账户或角色的用户访问 Airflow 系统。
限制对视图或 DAG 的访问：控制用户对特定视图或特定 DAG 的访问，确保用户只能查看或与授权组件交互。

未来：多租户隔离¶

这些示例展示了部署管理员如何在 Airflow 中细化和限制用户权限，提供更严格的控制，并根据用户的角色和职责确保他们只能访问必要的组件和功能。然而，细粒度访问控制目前尚未提供完全隔离和访问分离，以实现在多租户模式下隔离不同的用户组。在未来的 Airflow 版本中，一些细粒度访问控制功能可能会成为 Airflow 安全模型的一部分，因为 Airflow 社区目前正在研究多租户模型。