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作者可以创建和更改在工作节点和DAG文件处理器上执行的代码，并可能访问DAG代码用于连接外部系统的凭证。DAG作者对元数据数据库拥有完全访问权限。

已认证的UI用户¶

他们可以访问UI和API界面。关于已认证UI用户可能拥有的权限详情，请参阅下文。

未认证的UI用户¶

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

已认证UI用户的功能¶

已认证UI用户的功能可能有所不同，具体取决于部署管理员或管理员用户配置的角色以及这些角色拥有的权限。角色权限可以限定为单个DAG的范围，例如，也可以像管理员一样广泛。以下是四个一般类别，帮助概念化一些已认证用户可能拥有的功能：

管理员用户¶

他们负责管理和授予其他用户权限，拥有所有用户界面功能的完全访问权限。他们可能通过配置连接在工作节点上执行代码，因此需要被信任不会滥用这些特权。他们可以访问敏感凭证并对其进行修改。默认情况下，他们没有系统级配置的访问权限。他们应被信任不会滥用通过连接配置可访问的敏感信息。他们还有能力创建Web服务器拒绝服务的情况，应被信任不会滥用此能力。

只有管理员用户才能访问审计日志。

操作用户¶

操作员和管理员之间的主要区别在于管理和授予其他用户权限以及访问审计日志的能力 - 只有管理员能够执行这些操作。除此之外，可以认为他们拥有与管理员相同的访问权限。

连接配置用户¶

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

这些用户应被高度信任，不会滥用此功能。

审计日志用户¶

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

普通用户¶

他们可以查看并与用户界面和API进行交互。他们能够查看和编辑DAG、任务实例和DAG运行，以及查看任务日志。

查看者用户¶

他们可以以只读方式查看与DAG相关的信息、任务日志和其他相关细节。该角色适合需要只读访问权限、但无法触发或修改DAG的用户。

查看者也没有权限访问审计日志。

有关已认证UI用户功能的更多信息，请参阅访问控制。

DAG作者的能力¶

DAG作者能够通过放置在DAGS_FOLDER中的Python文件提交代码，这些代码将在多种情况下被执行。Airflow不会对要执行的代码进行验证、检查或沙盒隔离（这即使不是不可能，也非常困难），因此实际上DAG作者可以在工作节点（对于Celery Executor来说是Celery Workers的一部分，对于Local Executor来说是调度程序运行的本地进程，对于Kubernetes Executor来说是任务Kubernetes POD）、DAG文件处理器（可以作为独立进程执行，也可以是调度程序的一部分）以及触发器上执行任意代码。

Airflow选择的这种模型有几个后果，部署管理者需要注意：

本地执行器和内置DAG文件处理器¶

在本地执行器（Local Executor）和DAG文件处理器作为调度程序（Scheduler）组成部分运行的情况下，DAG编写者可以在调度程序运行的机器上执行任意代码。这意味着他们可能影响调度程序进程本身，甚至可能影响整个Airflow安装环境——包括修改集群范围的策略和更改Airflow配置。如果您正在使用这些设置之一运行Airflow，部署管理员必须信任DAG编写者不会滥用此功能。

Celery Executor¶

在使用Celery Executor的情况下，DAG作者可以在Celery Workers上执行任意代码。这意味着他们有可能影响同一worker上执行的所有任务。如果您正在使用Celery Executor运行Airflow，部署管理员必须信任DAG作者不会滥用此功能，除非部署管理员通过集群策略按队列分离任务执行，否则他们应该假设任务之间没有隔离。

Kubernetes执行器¶

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

触发器¶

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

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

部署管理器可能会隔离由DAG作者提供的代码执行——特别是在调度器和Web服务器中，确保调度器和Web服务器甚至无法访问DAG文件（这需要部署独立的DAG文件处理器）。一般来说，调度器或Web服务器进程中不应执行任何由DAG作者提供的代码。

允许DAG作者在Scheduler和Webserver中执行选定代码¶

DAG作者可以使用多种功能来执行预先注册的自定义代码，这些代码将在调度器或网络服务器进程中运行 - 例如他们可以选择自定义时间表、UI插件、连接UI字段、操作符额外链接、宏、监听器 - 所有这些功能都允许DAG作者选择将在调度器或网络服务器进程中执行的代码。然而，这些不应是DAG作者可以在DAG文件夹中随意添加的任意代码。所有这些功能仅通过plugins和providers机制提供，其中可执行的代码只能由已安装的包提供（对于插件，也可以添加到PLUGINS文件夹中，DAG作者不应具有写入权限）。PLUGINS_FOLDER是来自Airflow 1.10的遗留机制 - 但我们推荐使用入口点机制，允许部署管理器有效地选择和注册将在这些上下文中执行的代码。DAG作者无权安装或修改安装在网络服务器和调度器中的包，这是防止DAG作者在这些进程中执行任意代码的方式。

此外，如果您决定使用并配置PLUGINS_FOLDER，部署管理员必须确保DAG作者没有对该文件夹的写入权限。

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

访问所有DAG¶

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

部署管理员的职责¶

作为部署管理员，您应当了解DAG作者的能力范围，并确保您信任他们不会滥用所拥有的权限。同时，您还需确认已正确配置Airflow安装环境，以防止DAG作者在调度器和网页服务器进程中执行任意代码。

部署和保护Airflow安装¶

部署管理员还负责部署airflow并确保用户能够以符合组织适用的安全部署最佳实践的方式访问它。这包括但不限于：

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

限制DAG作者权限¶

部署管理器可能还会采用其他机制来防止DAG作者执行任意代码——例如，他们可能会围绕DAG提交引入工具，允许在部署前审查代码、进行静态检查，并添加其他方式来防止提交恶意代码。向DAG文件夹提交代码的方式和保护措施完全由部署管理器决定——Airflow不提供任何相关工具或机制，它期望部署管理器能提供工具来保护对DAG文件夹的访问，并确保只有可信代码被提交到其中。

Airflow本身并未原生实现这些功能，而是将其委托给部署管理器来部署所有必要的基础设施以保护部署——作为外部基础设施组件。

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

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

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

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

未来：多租户隔离¶

这些示例展示了部署管理员如何在Airflow中细化和限制用户权限，提供更严格的控制，确保用户仅能基于其角色和职责访问必要的组件和功能。然而，细粒度的访问控制目前尚无法以多租户方式实现不同用户组的完全隔离和访问分离。在Airflow的未来版本中，随着社区当前正在开发多租户模型，部分细粒度访问控制功能可能会成为Airflow安全模型的一部分。