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