Dataflow のセキュリティと権限

Dataflow ランナーを使用して、ローカルまたは Google Cloud のマネージド リソース上で Dataflow パイプラインを実行できます。パイプラインをローカルで実行する場合でもクラウドで実行する場合でも、パイプラインとそのワーカーは権限システムを使用して、パイプライン ファイルとリソースへの安全なアクセスを維持します。Dataflow の権限は、パイプライン リソースへのアクセスに使用されるロールに従って割り当てられます。このドキュメントでは、次のコンセプトについて説明します。

• Dataflow VM のアップグレード
• ローカル パイプラインと Google Cloud パイプラインの実行に必要なロールと権限
• パイプライン リソースにアクセスするために必要なロールと権限
• Dataflow サービスとデータ セキュリティで使用されるデータのタイプ

始める前に

Google Cloud の概要で、Google Cloud プロジェクトの識別子についての記事をご覧ください。識別子とは、プロジェクト名、プロジェクト ID、プロジェクト番号などです。

Dataflow VM のアップグレードとパッチの適用

Dataflow は Container-Optimized OS を使用します。Container-Optimized OS のセキュリティ プロセスが Dataflow に適用されます。

バッチ パイプラインには時間制限があります。メンテナンスの必要はありません。新しいバッチ パイプラインを開始すると、最新の Dataflow イメージが使用されます。

ストリーミング パイプラインでセキュリティ パッチがすぐに必要な場合、Google Cloud はセキュリティに関する情報でそのことを通知します。ストリーミング パイプラインの場合は、--update オプションを使用して、最新の Dataflow イメージでジョブを再起動することをおすすめします。

Dataflow コンテナ イメージは、Google Cloud Console で入手できます。

ローカル パイプラインのセキュリティと権限

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 上のパイプラインのセキュリティと権限

Cloud Platform 上でパイプラインを実行するときは、Dataflow は 2 つのサービス アカウントを使用してセキュリティと権限を管理します。

• Dataflow サービス アカウント。Dataflow サービスは、プロジェクトの割り当ての確認や、ユーザーの代理でのワーカー インスタンスの作成など、ジョブ作成リクエストの一部として Dataflow サービス アカウントを使用します。また、Dataflow はジョブの実行中に Dataflow サービス アカウントを使用して、ジョブを管理します。このアカウントは、Dataflow サービス エージェントとも呼ばれます。

• ワーカー サービス アカウント。 ワーカー サービス アカウントは、ユーザーがジョブを送信した後にワーカー インスタンスが入力リソースや出力リソースにアクセスする目的で使用されます。デフォルトでは、ワーカーはプロジェクトに関連付けられた Compute Engine のデフォルトのサービス アカウントをワーカー サービス アカウントとして使用します。ベスト プラクティスとして、デフォルトのワーカー サービス アカウントを使用する代わりに、ユーザー管理のサービス アカウントを指定することをおすすめします。

サービス アカウントの権限を借用するには、パイプラインを起動するアカウントに iam.serviceAccounts.actAs ロールが必要です。

他のプロジェクトの権限によっては、ユーザー アカウントに roles/dataflow.developer ロールも必要になる場合があります。プロジェクトのオーナーまたは編集者の場合は、roles/dataflow.developer ロールに含まれる権限がすでに付与されています。

ベスト プラクティス

• 可能であれば、ワーカー サービス アカウントに、デフォルトのワーカー サービス アカウントを使用する代わりに、ユーザー管理のサービス アカウントを指定します。
• リソースに権限を付与する場合は、タスクに必要な最小限の権限を含むロールを付与します。必要な権限のみを含むカスタムロールを作成できます。
• リソースにアクセスするためにロールを付与する場合は、可能な限り低いリソースレベルを使用してください。たとえば、プロジェクトまたはフォルダに roles/bigquery.dataEditor ロールを付与する代わりに、BigQuery テーブルにロールを付与します。
• プロジェクトが所有するバケットを作成し、Dataflow のステージング バケットとして使用します。デフォルトのバケット権限により、Dataflow はそのバケットを使用してパイプラインの実行ファイルをステージングできます。

Dataflow サービス アカウント

リソース Dataflow Job を使用したすべてのプロジェクトには、Dataflow サービス アカウント（Dataflow サービス エージェント）があります。このアカウントには、次のメールアドレスが設定されています。

[e-mail]

このサービス アカウントは Google によって作成、管理され、リソース Dataflow Job の初回使用時にプロジェクトに自動的に割り当てられます。

Dataflow パイプラインの実行の一環として、Dataflow はユーザーの代わりにリソースを操作します。たとえば、追加の VM を作成します。Dataflow でパイプラインを実行する場合は、このサービス アカウントが使用されます。

このアカウントには、プロジェクトの Dataflow サービス エージェントのロールが割り当てられます。Compute Engine ワーカーの起動など、プロジェクトで Dataflow ジョブを実行するために必要な権限があります。このアカウントは Dataflow によってのみ使用され、プロジェクトに固有のものです。

Dataflow サービス アカウントに割り当てられたロールは、Google Cloud コンソールまたは Google Cloud CLI で確認できます。

Console

1. [ロール] ページに移動します。

   [ロール] に移動

2. プロジェクトを選択します（該当する場合）。

3. リストで「Cloud Dataflow Service Agent」というタイトルをクリックします。ページが開き、Dataflow サービス アカウントに割り当てられた権限が一覧表示されます。

gcloud CLI

Dataflow サービス アカウントの権限を表示します。

gcloud iam roles describe roles/dataflow.serviceAgent

Google Cloud のサービスは、プロジェクトとそのリソースへの読み取り / 書き込みアクセス権が付与されていることが前提となっているため、プロジェクトに対して自動的に設定されたデフォルトの権限を変更しないことをおすすめします。Dataflow サービス アカウントがプロジェクトに対する権限を失うと、Dataflow が VM を起動することや、その他の管理タスクを実行することができなくなります。

Identity and Access Management（IAM）ポリシーからサービス アカウントの権限を削除しても、アカウントは Dataflow サービスによって所有されているため、引き続き存在します。

ワーカー サービス アカウント

Compute Engine インスタンスは Apache Beam SDK のオペレーションをクラウドで実行します。これらのワーカーは、プロジェクトのワーカー サービス アカウントを使用して、パイプラインに関連付けられたファイルやその他のリソースにアクセスします。ワーカー サービス アカウントはすべてのワーカー VM の ID として使用され、VM からのすべてのリクエストでワーカー サービス アカウントを使用します。このサービス アカウントは、Cloud Storage バケットや Pub/Sub トピックなどのリソースの操作にも使用されます。

• ワーカー サービス アカウントでジョブを実行できるようにするには、roles/dataflow.worker ロールが必要です。
• ワーカー サービス アカウントでジョブを作成または確認できるようにするには、roles/dataflow.admin ロールが必要です。

また、Apache Beam パイプラインが Google Cloud リソースにアクセスする場合は、必要なロールを Dataflow プロジェクトのワーカー サービス アカウントに付与する必要があります。ワーカー サービス アカウントは、Dataflow ジョブの実行中にリソースにアクセスできる必要があります。たとえば、ジョブで BigQuery に書き込む場合は、サービス アカウントにも BigQuery テーブルに対する roles/bigquery.dataEditor 以上のロールが必要です。リソースの例:

• Cloud Storage バケット
• BigQuery データセット
• Pub/Sub トピックとサブスクリプション
• Firestore データセット

デフォルトのワーカー サービス アカウント

デフォルトでは、ワーカーはプロジェクトの Compute Engine のデフォルト サービス アカウントをワーカー サービス アカウントとして使用します。このサービス アカウントのメールアドレスは次の形式です。

[e-mail]

このサービス アカウントは、Google Cloud コンソールの API ライブラリでプロジェクトの Compute Engine API を有効にすると、自動的に作成されます。

Compute Engine のデフォルトのサービス アカウントを Dataflow ワーカー サービス アカウントとして使用できますが、必要なロールと権限のみを持つ専用の Dataflow ワーカー サービス アカウントを作成することをおすすめします。

組織のポリシーの構成によっては、デフォルトのサービス アカウントにプロジェクトの編集者のロールが自動的に付与される場合があります。iam.automaticIamGrantsForDefaultServiceAccounts 組織ポリシー制約を適用して、自動的なロール付与を無効にすることを強くおすすめします。2024 年 5 月 3 日以降に組織を作成した場合、この制約はデフォルトで適用されます。

自動ロール付与を無効にする場合、デフォルトのサービス アカウントに付与するロールを決定し、これらのロールを付与する必要があります。

デフォルトのサービス アカウントにすでに編集者ロールが設定されている場合は、編集者ロールを権限の低いロールに置き換えることをおすすめします。サービス アカウントのロールを安全に変更するには、Policy Simulator を使用して変更の影響を確認してから、適切なロールを付与または取り消す操作を行います。

注: 以前は、Compute Engine のデフォルト サービス アカウントになり代わる権限がなくても、Dataflow ユーザーが Compute Engine のデフォルト サービス アカウントとして認証されたアプリケーションをデプロイできました。この従来の動作は、まだ一部の組織に影響しています。詳しくは、サービス アカウントをリソースに割り当てるときに権限借用を要求するをご覧ください。

ユーザー管理のワーカー サービス アカウントを指定する

きめ細かいアクセス制御を使用してリソースを作成して使用する場合は、ユーザー管理のサービス アカウントを作成します。このアカウントをワーカー サービス アカウントとして使用します。

1. ユーザー管理のサービス アカウントがない場合は、サービス アカウントを作成します。

2. サービス アカウントに必要な IAM ロールを設定します。

   • ワーカー サービス アカウントでジョブを実行できるようにするには、roles/dataflow.worker ロールが必要です。
   • ワーカー サービス アカウントでジョブを作成または確認できるようにするには、roles/dataflow.admin ロールが必要です。
   • 別の方法としては、必要な権限を持つカスタム IAM ロールを作成します。必要な権限の一覧については、ロールをご覧ください。
   • ジョブで必要とされる Google Cloud リソース（BigQuery、Pub/Sub、Cloud Storage）を使用するために、サービス アカウントに別のロールが必要となる場合があります。たとえば、ジョブで BigQuery から読み取りを行う場合は、サービス アカウントに BigQuery テーブルに対する roles/bigquery.dataViewer 以上のロールも必要です。
   • ユーザー管理のサービス アカウントに、Dataflow ジョブで指定されたステージング済みの一時的な場所に対する読み取りと書き込みのアクセス権があることを確認してください。
   • サービス アカウントの権限を借用するには、ユーザー アカウントに iam.serviceAccounts.actAs 権限が必要です。

3. ユーザー管理のワーカー サービス アカウントを含むプロジェクトでは、Dataflow サービス アカウント（[e-mail]）と Compute Engine サービス エージェント（[e-mail]）に、次のロールが必要となります。PROJECT_NUMBER は、Dataflow ジョブが実行されるプロジェクトの ID です。これらのアカウントはどちらもサービス エージェントです。

   • サービス アカウント トークン作成者のロール（iam.serviceAccountTokenCreator）
   • サービス アカウント ユーザー ロール（iam.serviceAccountUser）

   Dataflow ジョブが実行されるプロジェクトでは、デフォルトでこれらのロールがアカウントに付与されます。ユーザー管理のワーカー サービス アカウントとジョブが別々のプロジェクトに属している場合は、ユーザー管理のワーカー サービス アカウントで使用する Google 管理のサービス アカウントにもこれらのロールを付与します。これらのロールを付与する手順については、サービス アカウントの管理ページにある単一のロールを付与するをご覧ください。

4. ユーザー管理のワーカー サービス アカウントとジョブが別々のプロジェクトに属している場合は、ユーザー管理のサービス アカウントを所有するプロジェクトに iam.disableCrossProjectServiceAccountUsage ブール型制約が適用されていないことを確認します。詳細については、プロジェクト間でサービス アカウントの接続を有効にするをご覧ください。

5. パイプライン ジョブを実行するときに、サービス アカウントを指定します。

   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 パイプライン ジョブの実行時にサービス アカウントを指定します。

ユーザー管理のサービス アカウントは、ジョブと同じプロジェクトにあっても、別のプロジェクトにあってもかまいません。サービス アカウントとジョブが別々のプロジェクトに属している場合は、ジョブを実行する前にサービス アカウントを構成する必要があります。

ロールを追加する

プロジェクトにロールを追加するには、次の操作を行います。

コンソール

1. Google Cloud コンソールの [IAM] ページに移動します。

   [IAM] に移動

2. プロジェクトを選択します。

3. ユーザー アカウントを含む行で、「プリンシパルを編集します」をクリックし、[ 別のロールを追加] をクリックします。

4. プルダウン リストで、[サービス アカウント ユーザー] のロールを選択します。

5. ワーカー サービス アカウントを含む行で、「プリンシパルを編集します」をクリックし、[ 別のロールを追加] をクリックします。

6. プルダウン リストで、[Dataflow ワーカー] ロールを選択します。

7. ワーカー サービス アカウントに Dataflow 管理者ロールが必要な場合は、Dataflow 管理者についても繰り返します。

8. ジョブで使用されるリソースに必要なロールに対してこの手順を繰り返し、[保存] をクリックします。

   ロール付与の詳細については、コンソールを使用して 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. ワーカー サービス アカウントにロールを付与します。roles/dataflow.worker IAM ロールと、ジョブで使用するリソースに必要なロールに対して、次のコマンドを実行します。ワーカー サービス アカウントに Dataflow 管理者ロールが必要な場合は、roles/dataflow.admin IAM ロールについても繰り返します。この例では Compute Engine のデフォルトのサービス アカウントを使用していますが、ユーザー管理のサービス アカウントを使用することをおすすめします。

   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 は、個々のロールに置き換えます。

Google Cloud リソースにアクセスする

Apache Beam パイプラインは、同じ Google Cloud プロジェクトまたは他のプロジェクトの Google Cloud リソースにアクセスできます。次のようなリソースが該当します。

• Artifact Registry リポジトリ
• Cloud Storage バケット
• BigQuery データセット
• Pub/Sub トピックとサブスクリプション
• Firestore データセット

Apache Beam パイプラインからこれらのリソースに確実にアクセスできるようにするには、各リソースのアクセス制御メカニズムを使用して、自分の Dataflow プロジェクトのワーカー サービス アカウントにアクセス権を明示的に付与する必要があります。

Dataflow で Assured Workloads 機能を使用する場合（主権管理のある EU リージョンとサポートなど）、すべての Cloud Storage、BigQuery、Pub/Sub、I/O コネクタ、パイプラインがアクセスするその他のリソースを、組織の Assured Workloads プロジェクトまたはフォルダに配置する必要があります。

ただし、ユーザー管理のワーカー サービス アカウントを使用している場合や、他のプロジェクトのリソースにアクセスしている場合は、追加の操作が必要になることがあります。次の例では、Compute Engine のデフォルトのサービス アカウントを使用していますが、ユーザー管理のワーカー サービス アカウントを使用することもできます。

Artifact Registry リポジトリにアクセスする

Dataflow でカスタム コンテナを使用するときに、アーティファクトを Artifact Registry リポジトリにアップロードする場合があります。

Dataflow で Artifact Registry を使用するには、Dataflow ジョブを実行するワーカー サービス アカウントに少なくとも Artifact Registry 書き込みアクセス権（role/artifactregistry.writer）を付与する必要があります。

リポジトリのコンテンツはすべて、Google が所有し Google が管理する鍵か、顧客管理の暗号鍵を使用して暗号化されます。Artifact Registry では Google が所有し 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.objectViewer）。

Google Cloud プロジェクト内の Cloud Storage バケットのリストを取得するには、gcloud storage buckets list コマンドを使用します。

gcloud storage buckets list --project= PROJECT_ID

PROJECT_ID は、プロジェクトの ID に置き換えます。

リソース共有を制限する組織のポリシーによって制限されていない限り、Dataflow パイプラインとは異なるプロジェクトのバケットにアクセスできます。ドメインの制限の詳細については、ドメイン別の ID の制限をご覧ください。

バケットがない場合は、新しいバケットを作成します。次に、バケットに対する読み取りと書き込みに必要な権限をワーカー サービス アカウントに付与します。

バケットの権限は Google Cloud コンソールで設定することもできます。詳細については、バケット権限の設定をご覧ください。

Cloud Storage には、バケットとオブジェクトにアクセスするためのユーザー権限を付与する 2 つのシステムが用意されています。1 つは IAM、もう 1 つはアクセス制御リスト（ACL）です。通常は、IAM を使用してリソースへのアクセスを制御することをおすすめします。

• IAM は、Google Cloud 全体の権限を制御し、バケットレベルとプロジェクト レベルで権限を付与できます。Cloud Storage に関連付けられている IAM ロールと各ロールに含まれる権限のリストについては、Cloud Storage に適用される IAM ロールをご覧ください。権限をより細かく制御する必要がある場合は、カスタムロールを作成します。

• ACL を使用してアクセスを制御する場合は、ワーカー サービス アカウントの権限が IAM 設定と一致していることを確認してください。IAM ポリシーと ACL ポリシーの不一致により、Cloud Storage バケットがきめ細かいアクセスから均一なバケットレベルのアクセスに移行されると、Cloud Storage バケットが Dataflow ジョブにアクセスできなくなる可能性があります。詳細については、一般的なエラーのガイダンスをご覧ください。

BigQuery データセットにアクセスする

BigQueryIO API を使用すると、Dataflow を使用しているプロジェクトと同じプロジェクト、または別のプロジェクトに含まれる BigQuery データセットにアクセスできます。BigQuery ソースとシンクが正しく動作するためには、Dataflow ジョブで読み書きする BigQuery データセットに対するアクセス権が次の 2 つのアカウントに付与されている必要があります。

• Dataflow ジョブの実行に使用する Google Cloud アカウント
• Dataflow ジョブを実行するワーカー サービス アカウント

場合によっては、BigQuery を構成してこれらのアカウントにアクセス権を明示的に付与する必要があります。BigQuery ページまたは BigQuery API を使用して BigQuery データセットに対するアクセス権を付与する方法については、BigQuery アクセス制御をご覧ください。

必要な BigQuery 権限の中で、BigQuery データセットにアクセスするにはパイプラインで bigquery.datasets.get IAM 権限が必要です。通常、BigQuery IAM ロールのほとんどに bigquery.datasets.get 権限が含まれていますが、roles/bigquery.jobUser ロールにはありません。

Pub/Sub トピックとサブスクリプションにアクセスする

Pub/Sub トピックまたはサブスクリプションにアクセスするには、Pub/Sub の Identity and Access Management 機能を使用して、ワーカー サービス アカウントの権限を設定します。

次の Pub/Sub のロールの権限が関連しています。

• データを使用するには、roles/pubsub.subscriber が必須です。
• Pub/Sub サブスクリプションを作成するには、roles/pubsub.editor が必要です。
• Dataflow がトピックとサブスクリプションの構成をクエリできるようにするため、roles/pubsub.viewer の使用をおすすめします。この構成には 2 つの利点があります。
  • Dataflow は、正常に動作しない可能性のあるサブスクリプションでサポートされていない設定をチェックします。
  • サブスクリプションがデフォルトの確認応答期限（10 秒）を使用していなければ、パフォーマンスが向上します。Dataflow は、メッセージがパイプラインで処理されている間、メッセージの確認応答期限を繰り返し延長します。pubsub.viewer 権限がないと、Dataflow は確認応答期限を確認できないため、デフォルトの期限を前提とします。この構成により、Dataflow は必要以上に modifyAckDeadline リクエストを発行します。
  • サブスクリプションまたはトピックを所有するプロジェクトで VPC Service Controls が有効になっている場合は、IP アドレスに基づく上り（内向き）ルールのため、Dataflow で構成をクエリすることはできません。この場合、ワーカー サービス アカウントに基づく上り（内向き）ルールが必要です。

Pub/Sub の Identity and Access Management 機能の詳細と使用方法を示すコードサンプルについては、サンプル ユースケース: プロジェクト間通信をご覧ください。

Firestore にアクセスする

ネイティブ モードまたは Datastore モードで Firestore データベースにアクセスするには、データベースを所有するプロジェクトの編集者として Dataflow ワーカー サービス アカウント（[e-mail] など）を追加するか、より制限の厳しい Datastore のロール（roles/datastore.viewer など）を使用します。また、Google Cloud コンソールの API ライブラリで、両方のプロジェクトで Firestore API を有効にします。

信頼できるイメージのポリシーを使用してプロジェクトのイメージにアクセスする

プロジェクトに信頼できるイメージのポリシーを設定していて、ブートイメージが別のプロジェクトにある場合は、そのイメージにアクセスできるように、信頼できるイメージのポリシーが構成されていることを確認します。たとえば、テンプレート化された Dataflow ジョブを実行する場合は、ポリシー ファイルに dataflow-service-producer-prod プロジェクトへのアクセス権が含まれていることを確認します。この Google Cloud プロジェクトには、テンプレート ジョブ用のイメージが含まれています。

データアクセスとセキュリティ

Dataflow サービスは 2 種類のデータを処理します。

• エンドユーザー データ。このデータは Dataflow パイプラインによって処理されます。一般的なパイプラインは 1 つ以上のソースからデータを読み取り、データの変換を実装して、結果を 1 つ以上のシンクに書き込みます。すべてのソースとシンクは、Dataflow によって直接管理されないストレージ サービスです。

• オペレーション データ。このデータには、Dataflow パイプラインの管理に必要なすべてのメタデータが含まれています。このデータには、ユーザーが提供するメタデータ（ジョブ名やパイプライン オプションなど）とシステムが生成したメタデータ（ジョブ ID など）の両方が含まれます。

Dataflow サービスは、データのセキュリティとプライバシーを保つためにさまざまなセキュリティ メカニズムが使用されています。こうしたメカニズムは次のシナリオに適用されます。

• サービスにパイプラインを送信する
• パイプラインを評価する
• パイプラインの実行中と実行後にテレメトリーと指標へのアクセスをリクエストする
• Shuffle や Streaming Engine などの Dataflow サービスを使用する

データの局所性

注: パイプラインの実行時には、常にリージョンを指定することをおすすめします。

Dataflow のすべてのコアデータ処理は、パイプライン コードで指定されたリージョンで行われます。リージョンが指定されていない場合は、デフォルトのリージョン us-central1 が使用されます。このオプションをパイプライン コードに指定すると、パイプライン ジョブは、他のリージョンのソースやシンクからの読み取りと書き込みを任意で行うことができます。ただし、実際のデータ処理は、Dataflow VM の実行が指定されたリージョンでのみ行われます。

パイプライン ロジックは個々のワーカー VM インスタンスで評価されます。これらのインスタンスのゾーンと、それらが通信するプライベート ネットワークの場所を指定できます。プラットフォームの補助的な計算は、Cloud Storage のロケーションやファイルサイズなどのメタデータによって異なります。

Dataflow はリージョン サービスです。データのロケーションとリージョンの詳細については、Dataflow リージョンをご覧ください。

パイプライン送信のデータ

Google Cloud プロジェクトの IAM 権限は、Dataflow サービスへのアクセスを制御します。プロジェクトの編集者またはオーナーの権利を付与されたプリンシパルは、パイプラインをサービスに送信できます。パイプラインを送信するには、Google Cloud CLI を使用して認証を行う必要があります。認証後、パイプラインは HTTPS プロトコルを使用して送信されます。Google Cloud アカウントの認証情報で認証する方法については、使用している言語のクイックスタートをご覧ください。

パイプライン評価のデータ

パイプラインの評価で一時的なデータが生成され、ローカルのワーカー VM インスタンスまたは Cloud Storage に保存されます。一時データは保存時に暗号化されますが、パイプライン評価の完了後は保持されません。このようなデータは、Shuffle サービスまたは Streaming Engine サービス（Dataflow を有効にしている場合）でも、Dataflow パイプラインで指定されたリージョンに保存できます。

Java

デフォルトでは、Dataflow ジョブが完了すると、そのジョブが成功したか失敗したかを問わず Compute Engine VM が削除されます。その結果、関連付けられている Persistent Disk と、その中に格納されている中間データも削除されます。Cloud Storage に格納されている中間データは、--stagingLocation や --tempLocation として提供する、Cloud Storage パスのサブロケーションにあります。出力を Cloud Storage ファイルに書き込む場合、書き込みオペレーションがファイナライズされる前に一時ファイルが出力場所に作成されることがあります。

Python

デフォルトでは、Dataflow ジョブが完了すると、そのジョブが成功したか失敗したかを問わず Compute Engine VM が削除されます。その結果、関連付けられている Persistent Disk と、その中に格納されている中間データも削除されます。Cloud Storage に格納されている中間データは、--staging_location や --temp_location として提供する、Cloud Storage パスのサブロケーションにあります。出力を Cloud Storage ファイルに書き込む場合、書き込みオペレーションがファイナライズされる前に一時ファイルが出力場所に作成されることがあります。

Go

デフォルトでは、Dataflow ジョブが完了すると、そのジョブが成功したか失敗したかを問わず Compute Engine VM が削除されます。その結果、関連付けられている 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 は、指定されたリージョンのゾーンを自動的に選択します。転送中のエンドユーザー データはワーカー VM 内と同じゾーン内に存在します。これらの Dataflow ジョブは引き続き、VM ゾーン外のソースとシンクに対する読み取りと書き込みを行うことができます。転送中のデータは、Dataflow Shuffle サービスまたは Dataflow ストリーミング サービスにも送信できますが、データは常にパイプライン コードで指定されたリージョンに残ります。

推奨事項

パイプラインの基盤となるクラウド リソースにあるセキュリティ メカニズムを使用することをおすすめします。これらのメカニズムには、BigQuery や Cloud Storage など、データソースとシンクのデータ セキュリティ機能が含まれます。また、単一のプロジェクトに異なる信頼レベルが混在しないように配慮してください。