Cloud Composer 共担责任模型

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

在 Cloud Composer 上运行关键业务应用需要多方承担不同的责任。本文档列出了 Google 和客户的责任（并未详尽列出所有主题）。

Google 责任

• 强化和修补 Cloud Composer 环境的组件和底层基础架构，包括 Google Kubernetes Engine 集群、Cloud SQL 数据库（托管 Airflow 数据库）、Pub/Sub、Artifact Registry 和其他环境元素。具体而言，这包括自动升级底层基础架构，包括环境的 GKE 集群和 Cloud SQL 实例。

  注意 ：Cloud Composer 1 处于维护后模式，我们不再发布包含安全修复程序的 Cloud Composer 1 新版本。迁移到 Cloud Composer 2，获取包含安全改进的最新版本更新。

• 通过纳入 IAM 提供的访问控制功能、默认加密静态数据、提供额外的客户管理式存储加密、加密传输中的数据，保护对 Cloud Composer 环境的访问。

• Google Cloud 为 Identity and Access Management、Cloud Audit Logs 和 Cloud Key Management Service 提供集成。

• 使用 Access Transparency 和 Access Approval 限制和记录 Google 对客户集群的管理员权限，以便根据合同提供支持。

• 在 Cloud Composer 版本说明中发布有关 Cloud Composer 和 Airflow 版本之间向后不兼容更改的信息。

• 及时更新 Cloud Composer 文档：

  • 提供 Cloud Composer 提供的所有功能的说明。

  • 提供有助于保持环境处于良好状态的问题排查说明。

  • 发布有关已知问题的信息，并附上解决方法（如果有）。

• 通过提供可解决这些突发事件的新环境版本，解决与 Cloud Composer 环境和 Cloud Composer 提供的 Airflow 映像（不包括客户安装的 Python 软件包）相关的严重安全突发事件。

• 根据客户的支持方案，排查 Cloud Composer 环境运行状况问题。

• 维护和扩展 Cloud Composer Terraform 提供程序的功能。

• 与 Apache Airflow 社区合作，维护和开发 Google Airflow 运算符。

  注意 ：Google 不会修复或排查运营商提供商针对第三方服务或产品的问题。

• 排查 Airflow 核心功能中的问题，并在可能的情况下进行修复。

客户责任

• 升级到新的 Cloud Composer 和 Airflow 版本，以便在 Cloud Composer 服务发布可解决问题的 Cloud Composer 版本后继续获得对该产品的支持并解决安全问题。

• 维护 DAG 代码，使其与所使用的 Airflow 版本保持兼容。

• 保持环境的 GKE 集群配置不变，尤其是其自动升级功能。

• 在 IAM 中为环境的服务账号维护适当的权限。具体而言，请保留 Cloud Composer Agent 和环境的服务账号所需的权限。维护用于 Cloud Composer 环境加密的 CMEK 密钥的必要权限，并根据需要对其进行轮替。

  注意 ：我们建议您为 Cloud Composer 环境设置用户管理的服务账号，该账号仅具有运行环境和执行 DAG 中定义的操作所需的一组权限。在大多数情况下，Composer Worker (composer.worker) 角色会提供这组必需的权限。仅当 DAG 的运行需要时，才向此服务账号添加额外权限。
  
  虽然我们不建议使用此方法，但如果您未指定环境的服务账号，则 Cloud Composer 环境将使用默认的 Compute Engine 服务账号。默认的 Compute Engine 服务账号通常具有 Editor 基本角色，该角色包含的权限比运行 Cloud Composer 环境所需的权限多得多，因此会导致 DAG 使用超出预期的权限。

• 在 IAM 中为存储 Cloud Composer 组件映像的环境存储分区和 Artifact Registry 代码库维护适当的权限。

  注意：对以下组件拥有读写权限的用户：

  • 您环境的存储分区
  • 包含以下各项所使用的容器映像的 Artifact Registry 代码库： %Airflow 组件、GKEPodOperator 或 GKEStartPodOperator

  可以将自己的 DAG 或容器映像版本部署到环境，即使没有明确的 Cloud Composer 相关权限也可以。之后，您可以使用 Cloud Composer 环境服务账号的权限在环境中执行这些 DAG 或映像。

• 为执行 PyPI 软件包安装的服务账号维护适当的 IAM 权限。如需了解更多信息，请参阅访问权限控制。

  注意：对环境的存储分区具有读写权限的用户或可以发起 PyPI 软件包安装的用户可以代表用于执行此类构建的服务账号启动映像构建流程。此服务账号称为环境的服务账号，是在环境创建期间指定的，可以是用户提供的服务账号，也可以是默认服务账号。

• 在 IAM 和 Airflow 界面访问控制配置中维护适当的最终用户权限。

• 通过使用维护 DAG 将 Airflow 数据库大小保持在 16 GB 以下。

• 在向 Cloud 客户服务团队提交支持请求之前，请先解决所有 DAG 解析问题。

• 正确命名 DAG（例如，不要在 DAG 名称中使用空格或 TAB 等不可见字符），以便正确报告 DAG 的指标。

• 升级 DAG 的代码，使其不使用已废弃的运算符，并迁移到最新的替代方案。已废弃的运算符可能会从 Airflow 提供程序中移除，这可能会影响您升级到更高版本的 Cloud Composer 或 Airflow 的计划。我们也不会维护已废弃的运算符，因此必须“按原样”使用这些运算符。

• 使用 Secret Manager 等密钥后端时，请配置适当的 IAM 权限，以便环境的服务账号可以访问该后端。

• 使用 Cloud Composer 优化指南和环境扩缩指南调整 Cloud Composer 环境参数（例如 Airflow 组件的 CPU 和内存）和 Airflow 配置，以满足 Cloud Composer 环境的预期性能和负载。

• 避免移除 Cloud Composer Agent 和环境服务账号所需的权限（移除这些权限可能会导致管理操作失败或 DAG 和任务失败）。

• 始终启用 Cloud Composer 所需的所有服务和 API。这些依赖项必须在 Cloud Composer 所需的级别配置配额。

• 保留托管 Cloud Composer 环境使用的容器映像的 Artifact Registry 代码库。

• 遵循实现 DAG 的建议和最佳实践。

• 按照调度器问题排查、DAG 问题排查和触发器问题排查中的说明，诊断 DAG 和任务失败问题。

• 避免在环境的 GKE 集群中安装或运行会干扰 Cloud Composer 组件并阻止其正常运行的其他组件。

后续步骤

• 使用 IAM 进行访问权限控制
• 清理 Airflow 数据库
• 安全概览