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 Console 中提供了 Dataflow 容器映像。

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

您在本地运行时,您的 Apache Beam 流水线将以使用 gcloud 命令行工具可执行文件配置的 Google Cloud 帐号运行。因此,在本地运行的 Apache Beam SDK 操作和您的 Google Cloud 帐号可以访问相同的文件和资源。

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

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

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

  • Dataflow 服务帐号。Dataflow 服务会在作业创建请求发出期间使用 Dataflow 服务帐号来执行各种操作(例如,代表您检查项目配额以及创建工作器实例),并在作业执行期间使用该帐号来管理作业。

  • 工作器服务帐号。在您提交作业后,工作器实例使用工作器服务帐号访问输入和输出资源。

Dataflow 服务帐号

在运行 Dataflow 流水线的过程中,Dataflow 服务会代表您操作资源(例如,创建额外的虚拟机)。当您在 Dataflow 服务上运行流水线时,它会使用 Dataflow 服务帐号 (service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com)。在首次使用资源 Dataflow Job 时,系统会创建 Dataflow 服务帐号。此帐号会获得项目的 Dataflow Service Agent 角色,并且拥有在项目下运行 Dataflow 作业所必需的权限,包括启动 Compute Engine 工作器。此帐号专供 Dataflow 服务使用,并且是您项目的专属帐号。

您可以在 Cloud Console 或 gcloud 命令行工具中查看 Dataflow 服务帐号的权限。

控制台

  1. 转到角色页面。

    转到“角色”

  2. 在 Cloud Console 工具栏中,选择您的项目。

  3. 如需查看 Dataflow 服务帐号的权限,请选中 Cloud Dataflow Service Agent 复选框。

gcloud

查看 Dataflow 服务帐号的权限:

gcloud iam roles describe roles/dataflow.serviceAgent

由于 Google Cloud 服务预期会拥有相应项目及其资源的读写权限,因此建议您不要更改系统为您的项目自动设定的默认权限。如果您从 Identity and Access Management (IAM) 政策中移除该服务帐号的权限,相关帐号将仍然存在,因为它们归 Dataflow 服务所有。如果 Dataflow 服务帐号失去对某个项目的权限,Dataflow 将无法启动虚拟机,也无法执行其他管理任务。

工作器服务帐号

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

如需使工作器服务帐号能够创建、运行和检查作业,请确保它具有 roles/dataflow.adminroles/dataflow.worker 角色。此外,您的用户帐号需要 iam.serviceAccounts.actAs 权限才能模拟服务帐号。

默认工作器服务帐号

默认情况下,工作器将您项目的 Compute Engine 默认服务帐号用作工作器服务帐号。当您从 Cloud Console 的 API 库为项目启用 Compute Engine API 时,系统会自动创建此服务帐号 (<project-number>-compute@developer.gserviceaccount.com)。

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

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

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

如果您没有用户管理的服务帐号,则必须创建服务帐号并设置服务帐号所需的 IAM 角色。您的服务帐号必须至少拥有 Dataflow Worker 角色,并且可能还需要其他角色才能使用作业所需的 Cloud Platform 资源(例如 BigQuery、Pub/Sub,或者向 Cloud Storage 写入数据)。例如,如果您的作业会从 BigQuery 读取数据,则您的服务帐号还必须至少具有 roles/bigquery.dataViewer 角色。 此外,请确保您的用户管理的服务帐号对 Dataflow 作业中指定的暂存位置和临时位置具有读写权限。

用户管理的服务帐号可以与作业位于同一项目中,也可以位于其他项目中。如果服务帐号和作业位于不同的项目中,则必须先配置服务帐号,然后才能运行作业。您还必须将 Service Account Token Creator 角色授予用户管理的服务帐号上的以下 Google 管理的服务帐号:

  • Compute Engine 默认服务帐号 (<project-number>-compute@developer.gserviceaccount.com)
  • Dataflow Service Agent (service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com)

Java

运行流水线作业时,请使用 --serviceAccount 选项并指定服务帐号: --serviceAccount=my-service-account-name@<project-id>.iam.gserviceaccount.com

Python

运行流水线作业时,请使用 --service_account_email 选项并指定服务帐号: --service_account_email=my-service-account-name@<project-id>.iam.gserviceaccount.com

您可以从 Cloud Console 的“权限”页面获取您项目的服务帐号列表。

跨多个 Google Cloud 项目访问 Google Cloud 资源

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

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

跨 Google Cloud 项目访问 Cloud Storage 存储桶

如需使您的 Dataflow 项目有权访问其他 Google Cloud 项目拥有的 Cloud Storage 存储桶,请为 Dataflow 项目的工作器服务帐号授予该存储桶的访问权限。您可以使用 Cloud Storage 访问权限控制机制来授予所需的访问权限。

如需获取您的 Dataflow 项目的服务帐号列表,请查看 Cloud Console 中的IAM 和管理”页面。获得帐号名称后,您可以运行 gsutil 命令,向项目的服务帐号授予该存储桶及其内容的所有权(读写权限)。

要授权您的 Dataflow 项目的服务帐号访问另一个项目中的 Cloud Storage 存储分区,请在 shell 或终端窗口中使用以下命令:gsutil acl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

授权您的 Dataflow 项目的服务帐号访问另一个项目中的 Cloud Storage 存储桶的现有内容,请在 shell 或终端窗口中使用以下命令:gsutil -m acl ch -r -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

前一个命令仅授予现有资源的访问权限。如果向 Dataflow 项目的服务帐号授予存储桶的默认权限,则该帐号可以访问未来会添加到该存储桶的资源:gsutil defacl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

跨 Google Cloud 项目访问 BigQuery 数据集

您可以使用 BigQueryIO API 访问其他 Google Cloud 项目(即不是您使用 Dataflow 的项目)拥有的 BigQuery 数据集。如要让 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 帐号是 abcde@gmail.com,并且您在项目编号为 123456789 的项目中执行 Dataflow 作业,则如下帐号都必须获得所用 BigQuery 数据集的访问权限:abcde@gmail.com123456789-compute@developer.gserviceaccount.com

跨 Google Cloud 项目访问 Pub/Sub 主题和订阅

如需访问归其他 Google Cloud 项目所有的 Pub/Sub 主题或订阅,请使用 Pub/Sub 的 Identity and Access Management 功能来设置跨项目权限。Dataflow 使用工作器服务帐号来运行您的作业,并向此服务帐号授予访问其他项目中的 Pub/Sub 资源的权限。

需要以下 Pub/Sub 角色的权限:

  • roles/pubsub.subscriber:使用数据和创建订阅
  • roles/pubsub.viewer:查询主题和订阅的配置。为了适当延长时限,Dataflow 需要订阅的确认时限的访问权限。此外,此权限允许 Dataflow 检查可能导致问题的不受支持的订阅和主题设置。

如需更多信息并了解演示如何使用 Pub/Sub 的 Identity and Access Management 功能的一些代码示例,请参阅示例使用场景:跨项目通信

跨 Google Cloud 项目访问 Firestore

如需访问其他 Google Cloud 项目拥有的 Firestore 数据库(采用原生模式或 Datastore 模式),请将 Dataflow 项目的 Compute Engine (<project-number>-compute@developer.gserviceaccount.com) 服务帐号添加为该 Firestore 所属项目的 Editor。另外,您可以通过 Google Cloud Console 的 API 库在这两个项目中启用 Firestore API。

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

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

数据访问权限和安全

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

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

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

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

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

数据存放区域

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

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

Dataflow 是区域级服务。如需详细了解数据位置和区域级端点,请参阅区域级端点

流水线提交中的数据

Google Cloud 项目的 IAM 权限控制对 Dataflow 服务的访问权限。任何被授予编辑者或所有者权限的项目成员均可向该服务提交流水线。如需提交流水线,您必须使用 gcloud 命令行工具进行身份验证。您完成身份验证后,系统将使用 HTTPS 协议提交您的流水线。如需了解如何使用 Google Cloud 帐号凭据进行身份验证,请参阅与您使用的语言对应的快速入门

流水线评估中的数据

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

Java

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

Python

默认情况下,系统会在 Dataflow 作业完成后删除 Compute Engine 虚拟机,无论作业成功与否都是如此。这意味着相关联的永久性磁盘以及所有可能存储在该磁盘上的中间数据都会被删除。如需查看 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)的数据安全功能。此外,最好不要在单个项目中混用不同的信任级别。