Dataflow のセキュリティと権限

Dataflow パイプラインは、(小さなデータセットでテストを行うために)ローカルで実行することも、Google Cloud のマネージド リソース上で Dataflow マネージド サービスを使用して実行することもできます。実行される場所に関係なく、パイプラインとそのワーカーは権限システムを利用してパイプライン ファイルとリソースへのセキュアなアクセスを維持します。Dataflow の権限は、パイプライン リソースへのアクセスに使用されるロールに従って割り当てられます。このドキュメントでは、次のコンセプトについて説明します。

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

始める前に

プラットフォームの概要で、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 コマンドを実行します。

Google Cloud 上のパイプラインのセキュリティと権限

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

  • Dataflow サービス アカウント。Dataflow サービスは、ジョブ作成リクエスト(プロジェクト割り当ての確認、ユーザーの代理でのワーカー インスタンスの作成など)の一環として、またジョブ実行時のジョブ管理を目的として、Dataflow サービス アカウントを使用します。

  • ワーカー サービス アカウント。ワーカー サービス アカウントは、ユーザーがジョブを送信した後にワーカー インスタンスが入力リソースや出力リソースにアクセスする目的で使用されます。

Dataflow サービス アカウント

Dataflow パイプラインの実行の一環として、Dataflow サービスはユーザーの代わりにリソースを操作します(たとえば、追加の VM の作成など)。Dataflow サービス上でパイプラインを実行するときには、Dataflow サービス アカウント(service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com)が使用されます。Dataflow サービス アカウントは、Dataflow Job リソースの最初の使用時に作成されます。このアカウントには、プロジェクトに対する Dataflow サービス エージェントのロールが割り当てられます。さらに、そのプロジェクトで Dataflow ジョブの実行に必要な権限が付与されます(これには Compute Engine ワーカーの起動も含まれます)。このアカウントは Dataflow サービスによってのみ使用され、プロジェクトに固有のものです。

Dataflow サービス アカウントの権限は、コンソールまたは Google Cloud CLI で確認できます。

コンソール

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

    [ロール] に移動

  2. コンソールのツールバーでプロジェクトを選択します。

  3. Dataflow サービス アカウントの権限を表示するには、右上の [Google 提供のロール付与を含みます] チェックボックスをオンにし、[Cloud Dataflow サービス エージェント] チェックボックスをオンにします。

gcloud

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

gcloud iam roles describe roles/dataflow.serviceAgent

Google Cloud のサービスは、プロジェクトとそのリソースへの読み取り / 書き込みアクセス権が付与されていることが前提となっているため、プロジェクトに対して自動的に設定されたデフォルトの権限を変更しないことをおすすめします。Identity and Access Management(IAM)ポリシーからサービス アカウントの権限を削除しても、アカウントは Dataflow サービスによって所有されているため、引き続き存在します。Dataflow サービス アカウントがプロジェクトに対する権限を失うと、Dataflow が VM を起動することや、その他の管理タスクを実行することができなくなります。

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

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

ワーカー サービス アカウントでジョブを作成、実行、確認できるようにするには、roles/dataflow.admin ロールと roles/dataflow.worker ロールがあることを確認してください。また、サービス アカウントの権限を借用するには、ユーザー アカウントに iam.serviceAccounts.actAs 権限が必要です。

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

デフォルトでは、ワーカーはプロジェクトの Compute Engine のデフォルト サービス アカウントをワーカー サービス アカウントとして使用します。このサービス アカウント(<project-number>-compute@developer.gserviceaccount.com)は、コンソールの API ライブラリでプロジェクトの Compute Engine API を有効にすると、自動的に作成されます。

Compute Engine のデフォルト サービス アカウントは、プロジェクトのリソースに幅広くアクセスできるため、Dataflow を簡単に開始できます。ただし、本番環境のワークロードでは、必要なロールと権限のみを持つ新しいサービス アカウントを作成することをおすすめします。

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

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

ユーザー管理のサービス アカウントがない場合は、サービス アカウントを作成し、サービス アカウントに必要な IAM ロールを設定する必要があります。少なくとも、Dataflow ワーカーロールか、ロールroles/dataflow.worker に登録された必要な権限を含むカスタム IAM ロールをサービス アカウントに付与する必要があります。

また、ジョブで必要とされる Google Cloud リソースを使用するための他のロール(BigQuery、Pub/Sub、Cloud Storage への書き込みなど)が必要となる場合もあります。たとえば、ジョブで BigQuery から読み取る場合は、サービス アカウントは少なくとも roles/bigquery.dataViewer ロールを持つ必要があります。

また、ユーザー管理のサービス アカウントに、Dataflow ジョブで指定されたステージング済みの一時的な場所への読み取りと書き込みのアクセス権があることを確認してください。 また、サービス アカウントの権限を借用するには、ユーザー アカウントに iam.serviceAccounts.actAs 権限が必要です。

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

  • Compute Engine サービス エージェント(service-<project-number>@compute-system.iam.gserviceaccount.com
  • Dataflow サービス エージェント(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 パイプライン ジョブの実行時にサービス アカウントを指定します。

Go

--service_account_email オプションを使用して、--service_account_email=my-service-account-name@<project-id>.iam.gserviceaccount.com パイプライン ジョブの実行時にサービス アカウントを指定します。

プロジェクトのサービス アカウントのリストは、コンソールの権限ページで確認できます。

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

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

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

デフォルトのサービス アカウントには、プロジェクト内に存在するリソースに対して広範なアクセス権があります。Compute Engine のデフォルトのサービス アカウントをワーカー サービス アカウントとして使用し、同じプロジェクト内のリソースにのみアクセスする場合は、追加の操作は不要になることがあります。

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

Cloud Storage バケットにアクセスする

Dataflow プロジェクトに Cloud Storage バケットへのアクセスを許可するには、Dataflow プロジェクトのワーカー サービス アカウントからそのバケットにアクセスできるようにします。必要なアクセス権は Cloud Storage のアクセス制御を使用して付与できます。

Dataflow プロジェクトのサービス アカウントのリストを取得するには、コンソールで [IAM と管理] ページを確認します。アカウント名がわかっている場合は gsutil コマンドを実行して、プロジェクトのサービス アカウント オーナーシップ(読み取り / 書き込みの権限)を、バケットとそのコンテンツに付与します。

Dataflow プロジェクトのサービス アカウントに Cloud Storage バケットに対するアクセス権を付与するには、シェルまたはターミナル ウィンドウで次のコマンドを使用します。gsutil acl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Dataflow プロジェクトのサービス アカウントに別のプロジェクトの Cloud Storage バケットの既存のコンテンツに対するアクセス権を付与するには、シェルまたはターミナル ウィンドウで次のコマンドを使用します。 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>)にその後追加されるリソースへのアクセスが許可されます。

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

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

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

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

たとえば、Google Cloud アカウントが abcde@gmail.com で、Dataflow ジョブを実行するプロジェクトのプロジェクト番号が 123456789 の場合、使用する BigQuery データセットへのアクセス権をアカウント abcde@gmail.com123456789-compute@developer.gserviceaccount.com に付与する必要があります。

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

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

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

  • データの使用とサブスクリプションの作成には roles/pubsub.subscriber必要です。
  • 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 ワーカー サービス アカウント(<project-number>-compute@developer.gserviceaccount.com など)を追加するか、より制限の厳しい Datastore のロールroles/datastore.viewer など)を使用します。また、Google Cloud Console の API ライブラリで、両方のプロジェクトで Firestore API を有効にします。

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

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

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

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

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

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

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

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

データの局所性

Dataflow サービスのすべてのコアデータ処理は、パイプライン コードで指定されたリージョンで行われます。リージョンが指定されていない場合は、デフォルトのリージョン us-central1 が使用されます。パイプライン コードでパイプラインを指定すると、パイプライン ジョブは必要に応じて他のリージョンのソースやシンクへの読み書きを行います。ただし、実際のデータ処理は、Dataflow VM の実行が指定されたリージョンでのみ行われます。

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

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 など、データソースとシンクのデータ セキュリティ機能が含まれます。また、単一のプロジェクトに異なる信頼レベルが混在しないように配慮してください。