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 默认不支持未经身份验证的用户。如果允许，则部署管理器必须评估和解决潜在漏洞。
经过身份验证的 UI 用户的功能¶
经过身份验证的 UI 用户的功能可能因部署管理器或管理员用户配置的角色以及这些角色拥有的权限而异。角色上的权限可以严格限定为单个 DAG，例如，也可以像管理员一样广泛。以下是四种一般类别，有助于概念化经过身份验证的用户可能具有的某些功能
管理员用户¶
他们管理并向其他用户授予权限，并完全访问所有 UI 功能。他们可以通过配置连接来执行工作进程上的代码，并且需要信任他们不会滥用这些权限。他们可以访问敏感凭据并修改它们。默认情况下，他们无法访问系统级配置。应该信任他们不会滥用通过连接配置可访问的敏感信息。他们还有能力创建 Web 服务器拒绝服务情况，并且应该信任他们不会滥用此功能。
只有管理员用户才能访问审计日志。
操作用户¶
操作员和管理员之间的主要区别在于管理和向其他用户授予权限以及访问审计日志的能力 - 只有管理员才能这样做。否则，假设他们具有与管理员相同的访问权限。
连接配置用户¶
他们在 DAG 执行期间配置连接，并可能在工作进程上执行代码。需要信任以防止滥用这些权限。他们可以完全访问存储在连接中的敏感凭据，并可以修改它们。应该信任通过连接配置访问敏感信息不会被滥用。他们还有权错误地配置连接，这可能会创建 Web 服务器拒绝服务的情况，并指定不安全的连接选项，这可能会在某些提供程序（社区发布或自定义）中创建执行 DAG 将导致任意远程代码执行的情况。
应该高度信任这些用户不会滥用此功能。
审计日志用户¶
他们可以查看整个 Airflow 安装的审计事件。
普通用户¶
他们可以查看和交互 UI 和 API。他们可以查看和编辑 DAG、任务实例和 DAG 运行，以及查看任务日志。
DAG 作者的功能¶
DAG 作者能够提交代码（通过放置在 DAGS_FOLDER 中的 Python 文件），该代码将在多种情况下执行。要执行的代码既未经 Airflow 验证、检查或沙盒处理（如果不可能的话，这将非常困难），因此 DAG 作者实际上可以在工作进程（Celery Executor 的 Celery 工作进程的一部分，在 Local Executor 的情况下由调度程序运行的本地进程，在 Kubernetes Executor 的情况下为任务 Kubernetes POD）、DAG 文件处理器（可以作为独立进程执行或可以作为调度程序的一部分）和触发器中执行任意代码。
部署管理器需要了解 Airflow 选择的此模型的几个后果
本地执行器和内置 DAG 文件处理器¶
在本地执行器和作为调度程序一部分运行的 DAG 文件处理器的情况下，DAG 作者可以在运行调度程序的机器上执行任意代码。这意味着他们可以影响调度程序进程本身，并可能影响整个 Airflow 安装，包括修改集群范围的策略和更改 Airflow 配置。如果您使用其中一种设置运行 Airflow，则部署管理器必须信任 DAG 作者不会滥用此功能。
Celery 执行器¶
对于 Celery 执行器，DAG 作者可以在 Celery Workers 上执行任意代码。这意味着他们有可能影响在同一工作进程上执行的所有任务。如果你使用 Celery 执行器运行 Airflow，部署管理器必须相信 DAG 作者不会滥用此功能，除非部署管理器通过集群策略按队列分离任务执行，否则他们应该假设任务之间没有隔离。
Kubernetes 执行器¶
对于 Kubernetes 执行器，DAG 作者可以在他们运行的 Kubernetes POD 上执行任意代码。每个任务都在一个单独的 POD 中执行，因此任务之间已经存在隔离，因为一般来说 Kubernetes 提供了 POD 之间的隔离。
触发器¶
对于触发器，DAG 作者可以在触发器中执行任意代码。目前没有强制机制允许隔离使用可延迟功能的任务，并且来自不同任务的任意代码可以在同一进程/机器中执行。部署管理器必须相信 DAG 作者不会滥用此功能。
调度程序和 Web 服务器不需要的 DAG 文件¶
部署管理器可能会隔离 DAG 作者提供的代码执行，特别是在调度程序和 Web 服务器中，方法是确保调度程序和 Web 服务器甚至无法访问 DAG 文件（这需要部署独立的 DAG 文件处理器）。一般来说，调度程序或 Web 服务器进程中永远不应执行任何 DAG 作者提供的代码。
允许 DAG 作者在调度程序和 Web 服务器中执行选定的代码¶
有一些功能允许 DAG 作者使用预先注册的自定义代码在调度程序或 Web 服务器进程中执行 - 例如，他们可以选择自定义时间表、UI 插件、连接 UI 字段、操作员额外链接、宏、侦听器 - 所有这些功能都允许 DAG 作者选择将在调度程序或 Web 服务器进程中执行的代码。但是，这不能是 DAG 作者可以添加到 DAG 文件夹中的任意代码。所有这些功能仅通过 plugins 和 providers 机制提供，其中执行的代码只能由已安装的软件包提供（或在插件的情况下，也可以将其添加到 DAG 作者无权写入的 PLUGINS 文件夹中）。PLUGINS FOLDER 是一种来自 Airflow 1.10 的传统机制 - 但我们建议使用入口点机制，该机制允许部署管理器有效地选择和注册将在这些上下文中执行的代码。DAG 作者无权安装或修改 Web 服务器和调度程序中安装的软件包，这是防止 DAG 作者在这些进程中执行任意代码的方法。
部署管理器可能会决定引入额外的控制机制来防止 DAG 作者执行任意代码。这完全由部署管理器负责，并在下一章中进行讨论。
访问所有 DAG¶
所有 DAG 作者都可以访问 Airflow 部署中的所有 DAG。这意味着他们可以随时查看、修改和更新任何 DAG，不受任何限制。
部署管理人员的职责¶
作为部署管理器，您应该了解 DAG 作者的能力，并确保您信任他们不会滥用其拥有的能力。您还应该确保已正确配置 Airflow 安装，以防止 DAG 作者在调度程序和 Web 服务器进程中执行任意代码。
部署和保护 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 社区目前正在开发多租户模型。