Dataflow 安全与权限

Dataflow 流水线可以在本地运行（用于对小型数据集执行测试），也可以通过 Dataflow 代管式服务在 Google Cloud 托管资源上运行。无论是在本地运行还是在云端运行，您的流水线及其工作器均使用权限系统来维护对流水线文件和资源的安全访问。Dataflow 权限根据用于访问流水线资源的角色进行分配。本文档介绍以下概念：

• 升级 Dataflow 虚拟机。
• 运行本地和 Google Cloud 流水线所需的角色和权限。
• 跨项目访问流水线资源所需的角色和权限。
• Dataflow 服务和数据安全中使用的数据类型。

准备工作

请参阅 Platform 概览，了解 Google Cloud 项目标识符。这些标识符包括项目名称、项目 ID 和项目编号。

升级和修补 Dataflow 虚拟机

Dataflow 使用 Container-Optimized OS。因此，Container-Optimized OS 的安全流程同样适用于 Dataflow。

批处理流水线具有时限性，不需要维护。新的批处理流水线启动时，将使用最新的 Dataflow 映像。

对于流处理流水线，如果立即需要安全补丁程序，Google Cloud 会使用安全公告通知您。对于流处理流水线，我们建议您使用 --update 选项，通过最新的 Dataflow 映像重启作业。

Google Cloud 控制台中提供了 Dataflow 容器映像。

本地流水线的安全性和权限

在本地运行时，您的 Apache Beam 流水线将以您使用 Google Cloud CLI 可执行文件配置的 Google Cloud 账号身份运行。因此，在本地运行的 Apache Beam SDK 操作和您的 Google Cloud 账号可以访问相同的文件和资源。

要列出您选为默认账号的 Google Cloud 账号，请运行 gcloud config list 命令。

注意：本地流水线可将数据输出到本地目的地（如本地文件），也可以输出到云端目的地（如 Cloud Storage 或 BigQuery）。如果本地运行的流水线将文件写入云端资源（如 Cloud Storage），则该流水线会使用您的 Google Cloud 账号凭据以及您配置为 Google Cloud CLI 默认项目的 Google Cloud 项目。如需了解如何使用 Google Cloud 账号凭据进行身份验证，请参阅与您使用的语言对应的快速入门：Java 快速入门、Python 快速入门或 Go 快速入门。

Google Cloud 上的流水线的安全性和权限

当您运行流水线时，Dataflow 使用两个服务账号来管理安全性和权限：

• Dataflow 服务账号。Dataflow 服务会在作业创建请求发出期间使用 Dataflow 服务账号来执行各种操作（例如，代表您检查项目配额以及创建工作器实例）。 Dataflow 还会在作业执行期间使用 Dataflow 服务账号来管理作业。此账号也称为 Dataflow 服务代理。

• 工作器服务账号。 在您提交作业后，工作器实例使用工作器服务账号访问输入和输出资源。 默认情况下，工作器使用与您的项目关联的 Compute Engine 默认服务账号作为工作器服务账号。 要使工作器服务账号能够创建、运行和检查作业，它必须具有以下角色：

  • roles/dataflow.admin
  • roles/dataflow.worker

此外，当 Apache Beam 流水线访问 Google Cloud 资源时，您需要向 Dataflow 项目的工作器服务账号授予所需角色。工作器服务账号需要能够在运行 Dataflow 作业时访问资源。例如，如果您的作业写入 BigQuery，则您的服务账号还必须至少具有 roles/bigquery.dataEditor 角色。资源示例包括：

• Cloud Storage 存储桶
• BigQuery 数据集
• Pub/Sub 主题和订阅
• Firestore 数据集

最后，如需模拟服务账号，您的用户账号必须具有以下角色：iam.serviceAccounts.actAs。您的用户账号可能还需要 roles/dataflow.developer 角色，具体取决于其他项目权限。

如需在项目中添加所需角色，请按以下步骤操作。

控制台

1. 在 Google Cloud 控制台中，转到 IAM 页面。

   进入 IAM

2. 选择您的项目。

3. 在用户账号所在的行中，点击 修改主账号，然后点击 添加其他角色。

4. 在下拉列表中，选择 Service Account User 角色。

5. 在 Compute Engine 默认服务账号所在的行中，点击 修改主账号，然后点击 添加其他角色。

6. 在下拉列表中，选择 Dataflow Worker 角色。

7. 对 Dataflow Admin 和作业中使用的资源所需的任何角色重复上述步骤，然后点击保存。

   如需详细了解如何授予角色，请参阅使用控制台授予 IAM 角色。

gcloud CLI

1. 将 roles/iam.serviceAccountUser 角色授予您的用户账号。运行以下命令：

   gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS --role=roles/iam.serviceAccountUser
   

   • 将 PROJECT_ID 替换为您的项目 ID。
   • 将 EMAIL_ADDRESS 替换为用户账号的电子邮件地址。

2. 向您的 Compute Engine 默认服务账号授予角色。对以下每个 IAM 角色运行以下命令一次：roles/dataflow.admin、roles/dataflow.worker 以及作业中使用的资源所需的任何角色。

   gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:[e-mail]" --role=SERVICE_ACCOUNT_ROLE
   

   • 将 PROJECT_ID 替换为您的项目 ID。
   • 将 PROJECT_NUMBER 替换为您的项目编号。 如需查找项目编号，请参阅识别项目或使用 gcloud projects describe 命令。
   • 将 SERVICE_ACCOUNT_ROLE 替换为每个角色。

Dataflow 服务账号

所有使用资源 Dataflow Job 的项目都有一个 Dataflow 服务账号（也称为 Dataflow 服务代理），该账号具有以下电子邮件：

[e-mail]

此服务账号由 Google 创建和管理，并在首次使用资源 Dataflow Job 时自动分配给您的项目。

在运行 Dataflow 流水线的过程中，Dataflow 服务会代表您操作资源。例如，它会创建其他虚拟机。当您在 Dataflow 服务上运行流水线时，该服务会使用此服务账号。

此账号会获得项目的 Dataflow Service Agent 角色。它具有在项目中运行 Dataflow 作业所必需的权限，包括启动 Compute Engine 工作器。此账号专供 Dataflow 服务使用，并且是您项目的专属账号。

您可以在 Google Cloud 控制台或 Google Cloud CLI 中查看 Dataflow 服务账号的权限。

控制台

1. 打开角色页面。

   打开“角色”

2. 如果适用，请选择您的项目。

3. 在列表中，点击标题 Cloud Dataflow Service Agent。系统会打开一个页面，其中列出了分配给 Dataflow 服务账号的权限。

gcloud CLI

查看 Dataflow 服务账号的权限：

gcloud iam roles describe roles/dataflow.serviceAgent

由于 Google Cloud 服务应该拥有项目及其资源的读写权限，因此建议您不要更改系统为项目自动设定的默认权限。如果 Dataflow 服务账号失去对某个项目的权限，Dataflow 将无法启动虚拟机，也无法执行其他管理任务。

如果您从 Identity and Access Management (IAM) 政策中移除该服务账号的权限，该账号将仍然存在，因为它归 Dataflow 服务所有。

最佳实践：创建一个归您的项目所有的存储桶，并将其用作 Dataflow 的暂存存储桶。默认存储桶权限允许 Dataflow 使用存储桶暂存流水线的可执行文件。

工作器服务账号

Compute Engine 实例在云端执行 Apache Beam SDK 操作。这些工作器使用您项目的工作器服务账号来访问与流水线关联的文件和其他资源。工作器服务账号用作所有工作器虚拟机的身份，并且源自虚拟机的所有请求都使用工作器服务账号。此服务账号还用于与 Cloud Storage 存储桶和 Pub/Sub 主题等资源进行交互。

要使工作器服务账号能够创建、运行和检查作业，它必须具有以下角色：

• roles/dataflow.admin
• roles/dataflow.worker

默认工作器服务账号

默认情况下，工作器将您项目的 Compute Engine 默认服务账号用作工作器服务账号。此服务账号的电子邮件如下所示：

[e-mail]

当您从 Google Cloud 控制台中的 API 库为项目启用 Compute Engine API 时，系统会自动创建此服务账号。

Compute Engine 默认服务账号拥有对项目资源的广泛访问权限，可帮助您开始使用 Dataflow。但是，对于生产工作负载，我们建议您仅使用您所需的角色和权限创建新的服务账号。

注意： 在过去，Dataflow 用户可以部署已通过 Compute Engine 默认服务账号进行身份验证的应用，即使他们无权模拟 Compute Engine 默认服务账号也是如此。这种旧版行为仍会影响某些组织。如需了解详情，请参阅在将服务账号附加到资源时要求具备模拟权限。

指定用户管理的工作器服务账号

如果您要创建和使用具有精细访问权限控制的资源，则可以创建一个用户管理的服务账号。将此账号用作工作器服务账号。

1. 如果您没有用户管理的服务账号，请创建一个服务账号。

2. 为您的服务账号设置所需的 IAM 角色。

   • 为了让服务账号能够创建、运行和检查作业，它必须具有 roles/dataflow.admin 和 roles/dataflow.worker 角色，或者具有这些角色所需权限的自定义 IAM 角色。如需查看所需权限的列表，请参阅角色。
   • 并且可能还需要其他角色才能使用作业所需的 Cloud Platform 资源，例如 BigQuery、Pub/Sub 或 Cloud Storage。例如，如果您的作业会从 BigQuery 读取数据，则您的服务账号还必须至少具有 roles/bigquery.dataViewer 角色。
   • 请确保您的用户管理的服务账号对 Dataflow 作业中指定的暂存位置和临时位置具有读写权限。
   • 如需模拟服务账号，您的用户账号必须具有 iam.serviceAccounts.actAs 权限。

3. 将以下角色授予 Dataflow 服务账号 ([e-mail]) 以及 Compute Engine 服务代理 ([e-mail])。这两个账号都是用户管理的服务账号上的 Google 管理的服务账号。这些账号与用户管理的服务账号位于同一项目中，即使 Dataflow 作业在其他项目中运行也是如此。

   • Service Account Token Creator 角色 (iam.serviceAccountTokenCreator)
   • Service Account User 角色 (iam.serviceAccountUser)

   如需查看演示如何向服务账号授予角色的说明，请参阅“管理对服务账号的访问权限”页面中的授予单个角色部分。

4. 运行流水线作业时，请指定您的服务账号。

   Java

   从命令行运行流水线作业时，请使用 --serviceAccount 选项并指定服务账号： --serviceAccount=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

   将流水线作业作为 Flex 模板运行时，请使用 --service-account-email 选项并指定服务账号： --service-account-email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

   Python

   运行流水线作业时，请使用 --service_account_email 选项并指定服务账号： --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

   Go

   运行流水线作业时，请使用 --service_account_email 选项并指定服务账号： --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

您可以从 Google Cloud 控制台中的“权限”页面获取与项目关联的服务账号列表。

用户管理的服务账号可以与作业位于同一项目中，也可以位于其他项目中。如果服务账号和作业位于不同的项目中，则必须先配置服务账号，然后才能运行作业。

访问 Google Cloud 资源

您的 Apache Beam 流水线可以访问同一 Google Cloud 项目或其他项目中的 Google Cloud 资源。这些资源包括：

• Artifact Registry 制品库
• Cloud Storage 存储桶
• BigQuery 数据集
• Pub/Sub 主题和订阅
• Firestore 数据集

要确保 Apache Beam 流水线可以访问这些资源，您需要使用这些资源的相应访问权限控制机制向您的 Dataflow 项目的工作器服务账号明确授予访问权限。

如果您将 Assured Workloads 功能与 Dataflow 搭配使用，例如具有主权管制的欧盟区域和支持、流水线访问的所有 Cloud Storage、BigQuery、Pub/Sub、I/O 连接器以及其他资源必须位于组织的 Assured Workloads 项目或文件夹中。

如果您使用的是用户管理的工作器服务账号或要访问其他项目中的资源，则可能需要执行其他操作。以下示例假定使用的是 Compute Engine 默认服务账号，但您也可以使用用户管理的工作器服务账号。

访问 Artifact Registry 制品库

将自定义容器与 Dataflow 搭配使用时，您可以将工件上传到 Artifact Registry 制品库。

如需将 Artifact Registry 与 Dataflow 搭配使用，您必须至少向运行 Dataflow 作业的工作器服务账号授予 Artifact Registry Writer 权限 (role/artifactregistry.writer)。

所有代码库内容都已使用 Google 管理的加密密钥或客户管理的加密密钥进行加密。Artifact Registry 默认使用 Google 管理的加密密钥，此选项无需进行任何配置。

访问 Cloud Storage 存储桶

如需授权您的 Dataflow 项目访问 Cloud Storage 存储桶，请向 Dataflow 项目的工作器服务账号授予对该存储桶的访问权限。您的服务账号至少需要拥有存储桶及其内容的读写权限。您可以使用适用于 Cloud Storage 的 IAM 权限来授予所需的访问权限。

如需为您的工作器服务账号授予在存储桶中读取和写入数据所需的权限，请使用 gcloud storage buckets add-iam-policy-binding 命令。此命令会将您的 Dataflow 项目服务账号添加到存储桶级政策中。

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member="serviceAccount:[e-mail]" --role=SERVICE_ACCOUNT_ROLE

替换以下内容：

• BUCKET_NAME：Cloud Storage 存储桶的名称
• PROJECT_NUMBER：您的 Dataflow 项目编号。如需查找您的项目编号，请参阅识别项目或使用 gcloud projects describe 命令。
• SERVICE_ACCOUNT_ROLE：IAM 角色

如果您的服务账号需要完全控制存储对象（包括列出、创建、查看和删除对象及托管式文件夹），请为您的服务账号授予 Storage Object Admin (roles/storage.objectAdmin) 角色。

如需检索 Google Cloud 项目中的 Cloud Storage 存储桶列表，请使用 gcloud storage buckets list 命令：

gcloud storage buckets list --project= PROJECT_ID

将 PROJECT_ID 替换为相应项目的 ID。

除非您受到限制资源共享的组织政策的限制，否则您可以访问与 Dataflow 流水线位于不同项目中的存储桶。如需详细了解网域限制，请参阅按网域限制身份。

如果您没有存储桶，请创建一个新存储桶。然后，为您的工作器服务账号授予在存储桶中读取和写入数据所需的权限。

您还可以在 Google Cloud 控制台中设置存储桶权限。如需了解详情，请参阅设置存储桶权限。

在 Cloud Storage 中，您可以通过以下两个系统为用户授予存储桶和对象的访问权限：IAM 和访问控制列表 (ACL)。在大多数情况下，建议使用 IAM 来控制资源的访问权限。

• IAM 可控制整个 Google Cloud 中的权限，并可让您在存储桶级层和项目级层授予权限。如需查看与 Cloud Storage 关联的 IAM 角色列表以及每个角色提供的权限，请参阅适用于 Cloud Storage 的 IAM 角色。如果您需要更好地控制权限，请创建自定义角色。

• 如果您使用 ACL 来控制访问权限，请确保您的工作器服务账号权限与 IAM 设置一致。由于 IAM 和 ACL 政策之间的不一致，当 Cloud Storage 存储桶从细粒度访问权限迁移到统一存储桶级别访问权限时，您的 Dataflow 作业可能无法访问 Cloud Storage 存储桶。如需了解详情，请参阅常见错误指导。

访问 BigQuery 数据集

您可以使用 BigQueryIO API 访问 BigQuery 数据集，数据集可能位于使用 Dataflow 的同一项目中或另一个项目中。如要让 BigQuery 来源和接收器正常运行，下列两个账号必须要有权访问您的 Dataflow 作业从中读取数据或向其中写入数据的所有 BigQuery 数据集：

• 您用于运行 Dataflow 作业的 Google Cloud 账号。
• 运行 Dataflow 作业的工作器服务账号。

您可能需要配置 BigQuery，以向这些账号明确授予访问权限。请参阅BigQuery 访问权限控制，详细了解如何使用 BigQuery 页面或 BigQuery API 授予 BigQuery 数据集的访问权限。

在必要的 BigQuery 权限中，bigquery.datasets.get IAM 权限是流水线访问 BigQuery 数据集所必需的权限。通常，大多数 BigQuery IAM 角色都包含 bigquery.datasets.get 权限，但 roles/bigquery.jobUser 角色属于例外。

例如，如果您的 Google Cloud 账号为 [e-mail]，并且您在其中执行 Dataflow 作业的项目的编号为 123456789，则以下账号都必须获得所使用的 BigQuery 数据集的访问权限：[e-mail] 和 [e-mail]。

访问 Pub/Sub 主题和订阅

如需访问 Pub/Sub 主题或订阅，请使用 Pub/Sub 的 Identity and Access Management 功能为工作器服务账号设置权限。

以下 Pub/Sub 角色的权限是相关的：

• roles/pubsub.subscriber 是使用数据所必需的。
• roles/pubsub.editor 是创建 Pub/Sub 订阅所必需的。
• roles/pubsub.viewer 是推荐的权限，以便 Dataflow 可以查询主题和订阅的配置。此配置有两个优势：
  • Dataflow 可以检查可能无法按预期运行的订阅上不受支持的设置。
  • 如果订阅不使用默认 10 秒的 确认时限，则性能会提升。Dataflow 在流水线处理消息时反复延长该消息的确认时限。如果没有 pubsub.viewer 权限，Dataflow 将无法查询确认时限，因此必须假定默认时限。此配置会导致 Dataflow 发出的 modifyAckDeadline 请求数量超出需求。
  • 如果拥有订阅或主题的项目启用了 VPC Service Controls，则基于 IP 地址的入站流量规则不允许 Dataflow 查询配置。在这种情况下，需要基于工作器服务账号的入站流量规则。

如需了解详情以及演示如何使用 Pub/Sub 的 Identity and Access Management 功能的一些代码示例，请参阅示例使用场景：跨项目通信。

访问 Firestore

如需访问 Firestore 数据库（原生模式或 Datastore 模式），请添加您的 Dataflow 工作器服务账号（例如 [e-mail]）作为拥有该数据库的项目的编辑者或使用更严格的 Datastore 角色，例如 roles/datastore.viewer。另外，您可以通过 Google Cloud 控制台中的 API 库在两个项目中启用 Firestore API。

使用可信映像政策访问项目的映像

如果您为您的项目设置了可信映像政策，并且启动映像位于其他项目中，请确保将可信映像政策配置为有权访问该映像。 例如，如果您运行模板化 Dataflow 作业，请确保该政策文件具有对 dataflow-service-producer-prod 项目的访问权限。 此 Google Cloud 项目包含模板作业的映像。

数据访问权限和安全

Dataflow 服务适用于两种类型的数据：

• 最终用户数据。此数据由 Dataflow 流水线进行处理。一个典型的流水线从一个或多个来源读取数据，实现数据转换，并将结果写入一个或多个接收器。所有来源和接收器都是不由 Dataflow 直接管理的存储服务。

• 运营数据。此数据包括管理 Dataflow 流水线所需的所有元数据。此数据既包括用户提供的元数据（例如作业名称或流水线选项），也包括系统生成的元数据（例如作业 ID）。

Dataflow 服务使用多种安全机制来确保数据的安全性和私密性。这些机制适用于下列情景：

• 向服务提交流水线
• 评估流水线
• 在流水线执行期间和执行之后请求访问遥测数据和指标
• 使用 Dataflow 服务（例如 Shuffle 或 Streaming Engine）

数据存放区域

注意：我们建议您在运行流水线时始终指定区域。未来的版本将不再支持默认区域。

Dataflow 服务的所有核心数据处理都在流水线代码中指定的区域中执行。如果未指定区域，则使用默认区域 us-central1。 如果您在流水线代码中指定该选项，则流水线作业可以选择从其他区域的来源和接收器读取和写入。但是，实际的数据处理仅在指定运行 Dataflow 虚拟机的区域中进行。

针对各个工作器虚拟机实例评估流水线逻辑。您可以指定这些实例以及它们用来进行通信的专用网络所在的可用区。平台的辅助计算取决于 Cloud Storage 位置或文件大小等元数据。

Dataflow 是区域级服务。如需详细了解数据存储区域和区域，请参阅 Dataflow 区域。

流水线提交中的数据

Google Cloud 项目的 IAM 权限控制对 Dataflow 服务的访问权限。任何获得项目编辑者或所有者权限的主账号都可以向该服务提交流水线。如需提交流水线，您必须使用 Google Cloud CLI 进行身份验证。您完成身份验证后，系统将使用 HTTPS 协议提交您的流水线。如需了解如何使用 Google Cloud 账号凭据进行身份验证，请参阅与您使用的语言对应的快速入门。

流水线评估中的数据

评估流水线时，可能会生成临时数据，这些临时数据会存储在本地工作器虚拟机实例中或 Cloud Storage 中。临时数据会进行静态加密，并且在流水线评估结束后不会持久保存。这些数据也可以存储在 Shuffle 服务或 Streaming Engine 服务中（如果您已选择该服务），并且位于 Dataflow 流水线中指定的相同区域。

Java

默认情况下，系统会在 Dataflow 作业完成后删除 Compute Engine 虚拟机，无论作业成功与否都是如此。因此，关联的 Persistent Disk 以及所有可能存储在该磁盘上的中间数据都会被删除。如需查看 Cloud Storage 中存储的中间数据，请前往您作为 --stagingLocation 或 --tempLocation 提供的 Cloud Storage 路径子位置。如果您要将输出写入 Cloud Storage 文件，则系统可能会在写入操作完成之前，在输出位置创建临时文件。

Python

默认情况下，系统会在 Dataflow 作业完成后删除 Compute Engine 虚拟机，无论作业成功与否都是如此。因此，关联的 Persistent Disk 以及所有可能存储在该磁盘上的中间数据都会被删除。如需查看 Cloud Storage 中存储的中间数据，请前往您作为 --staging_location 或 --temp_location 提供的 Cloud Storage 路径子位置。如果您要将输出写入 Cloud Storage 文件，则系统可能会在写入操作完成之前，在输出位置创建临时文件。

Go

默认情况下，系统会在 Dataflow 作业完成后删除 Compute Engine 虚拟机，无论作业成功与否都是如此。因此，关联的 Persistent Disk 以及所有可能存储在该磁盘上的中间数据都会被删除。如需查看 Cloud Storage 中存储的中间数据，请前往您作为 --staging_location 或 --temp_location 提供的 Cloud Storage 路径子位置。如果您要将输出写入 Cloud Storage 文件，则系统可能会在写入操作完成之前，在输出位置创建临时文件。

流水线日志和遥测中的数据

Cloud Logging 中存储的信息主要由您的 Dataflow 程序中的代码生成。Dataflow 服务可能还会在 Cloud Logging 中生成警告和错误数据，不过这些数据是该服务添加到日志中的唯一中间数据。Cloud Logging 是全球性服务。

遥测数据和关联指标均进行了静态加密，并且这些数据的访问权限由您的 Google Cloud 项目的读取权限控制。

Dataflow 服务中的数据

如果您为流水线使用 Dataflow Shuffle 或 Dataflow Streaming，请勿指定可用区流水线选项。而应指定区域并将其值设置为提供 Shuffle 或 Streaming 的区域之一。Dataflow 会自动选择指定区域中的可用区。传输中的最终用户数据保留在工作器虚拟机中，并且位于同一可用区中。这些 Dataflow 作业仍然可以读取和写入虚拟机可用区之外的来源和接收器。传输中的数据也可以发送到 Dataflow Shuffle 或 Dataflow Streaming 服务，但数据始终保留在流水线代码中指定的区域中。

推荐做法

建议您使用流水线的基础云端资源中提供的安全机制。这些机制包括数据源和接收器（如 BigQuery 和 Cloud Storage）的数据安全功能。此外，最好不要在单个项目中混用不同的信任级别。