Cloud Dataflow のセキュリティと権限

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

始める前に

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

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

Google Cloud Platform アカウント

Apache Beam パイプラインをローカルで実行するときは、gcloud コマンドライン ツール実行可能プログラムで構成された GCP アカウントとして実行されます。したがって、ローカルで実行される Apache Beam SDK のオペレーションからアクセスできるのは、その GCP アカウントが権限を持つファイルとリソースに限られます。

デフォルトとして選択されている GCP アカウントを一覧表示するには、gcloud config list コマンドを実行します。

注: ローカル パイプラインからのデータの出力先は、ローカルの場所(たとえばローカル ファイル)とすることも、クラウドの場所(たとえば Cloud Storage や BigQuery)とすることもできます。ローカルで実行するパイプラインでファイルを Cloud Storage などのクラウドベースのリソースに書き込む場合は、GCP アカウントの認証情報と、gcloud コマンドライン ツールのデフォルトとして構成した GCP プロジェクトが使用されます。GCP アカウントの認証情報で認証する方法については、使用している言語のクイックスタートをご覧ください。

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

Cloud Platform 上でパイプラインを実行するときは、Cloud Dataflow は 2 つのサービス アカウント(Cloud Dataflow サービス アカウントとコントローラ サービス アカウント)を使用してセキュリティと権限を管理します。Cloud Dataflow サービス アカウントは、ジョブ作成リクエスト(プロジェクト割り当ての確認、ユーザーの代理でのワーカー インスタンスの作成など)の一環として、またジョブ実行時のジョブ管理を目的として使用され、コントローラ サービス アカウントは、ユーザーがジョブを送信した後にワーカー インスタンスが入力リソースや出力リソースにアクセスする目的で使用されます。

注: 2017 年 10 月 4 日の時点で、Cloud Dataflow はメタデータのオペレーションにコントローラ サービス アカウントを使用しています。Cloud Dataflow でのメタデータのオペレーションに cloudservices アカウントが使用されることはありません。

Cloud Dataflow サービス アカウント

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

gcloud コマンドライン ツールを使用して Cloud Dataflow サービス アカウントの権限を確認するには、シェルまたはターミナル ウィンドウで次のコマンドを入力します。

gcloud iam roles describe roles/dataflow.serviceAgent

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

ベスト プラクティス: プロジェクトを所有者とするバケットを作成し、Cloud Dataflow のステージング バケットとして使用します。このようにすると、パイプラインの実行可能ファイルのステージングに必要な権限を確実に自動設定できます。

コントローラ サービス アカウント

Compute Engine インスタンスは Apache Beam SDK のオペレーションをクラウドで実行します。これらのワーカーは、プロジェクトのコントローラ サービス アカウントを使用して、パイプラインのファイルとその他のリソースにアクセスします。コントローラ サービス アカウントは、Cloud Dataflow による「メタデータ」オペレーションにも使用されます。これは、ローカル クライアントでも Compute Engine ワーカーでも実行されないオペレーションで、たとえば入力サイズの特定や、Cloud Storage ファイルへのアクセスといったタスクを実行します。

デフォルトのコントローラ サービス アカウント

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

さらに、プロジェクトに関連付けられた Compute Engine サービス アカウントには、プロジェクトが所有する Cloud Storage バケットとリソースに対するアクセス権がデフォルトで付与されます。ほとんどの Compute Engine ワーカーはプロジェクト リソースに対する読み取り / 書き込みアクセス権が付与されていることが前提となっているため、プロジェクトに対して自動的に設定されるデフォルト権限は変更しないことをおすすめします。

プロジェクトのサービス アカウントのリストは、GCP Console の [権限] ページから取得できます。

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

アクセス権と制御をきめ細かく設定したリソースを作成して使用する必要がある場合は、ジョブのプロジェクトのサービス アカウントをユーザー管理のコントローラ サービス アカウントとして使用できます。

ユーザー管理のサービス アカウントがない場合は、ジョブと同じプロジェクトにサービス アカウントを作成し、サービス アカウントに必要な IAM 役割を設定する必要があります。少なくとも、Dataflow ワーカーの役割をサービス アカウントに付与してください。また、ジョブで必要とされる Cloud Platform リソースを使用するための他の役割(BigQuery、Cloud Pub / Sub、Cloud Storage への書き込みなど)が必要となる場合もあります。たとえば、BigQuery から読み取りを行うジョブがある場合は、少なくとも bigquery.dataViewer 役割をサービス アカウントに付与する必要があります。

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

他の Google Cloud Platform プロジェクトの Google Cloud Platform リソースにアクセスする

Apache Beam パイプラインで他の GCP プロジェクトの GCP リソースにアクセスできます。たとえば、次のようなものがあります。

Java

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

Python

  • Cloud Storage バケット
  • BigQuery データセット
  • Cloud Datastore データセット

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

他の Google Cloud Platform プロジェクトの Cloud Storage バケットにアクセスする

Cloud Dataflow プロジェクトに対して、別の GCP プロジェクトが所有する Cloud Storage バケットへのアクセスを許可するには、Cloud Dataflow プロジェクトのコントローラ サービス アカウントからそのバケットにアクセスできるようにする必要があります。必要なアクセス権は Cloud Storage Access Controls を使用して付与できます。

注: デフォルトのサービス アカウントを使用していない場合には、権限を IAM 設定に一致させる必要があります。

Cloud Dataflow プロジェクトのサービス アカウントの一覧を取得するには、GCP Console の [IAM と管理] ページを調べます。アカウント名が明らかになれば、gsutil コマンドを実行してバケットとその内容の両方の所有権(読み取り / 書き込み権限)をプロジェクトのサービス アカウントに付与できます。

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

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

注: -m オプションを指定すると、コマンドが並列で実行されるため処理が速くなります。-r オプションを指定すると、コマンドがバケット内のリソースに対して再帰的に実行されます。

前述のコマンドで付与されるのは、既存のリソースに対するアクセス権のみであるので注意してください。次のように Cloud Dataflow プロジェクトのサービス アカウントにバケットへのデフォルト権限を付与すると、それ以降そのバケットに追加されるリソースへのアクセスが許可されます。gsutil defacl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

他の Google Cloud Platform プロジェクトの BigQuery データセットにアクセスする

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

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

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

他の Google Cloud Platform プロジェクトの Cloud Pub/Sub トピックとサブスクリプションにアクセスする

あるプロジェクトで Cloud Dataflow を使用しているときに、別の GCP プロジェクトが所有する Cloud Pub/Sub のトピックまたはサブスクリプションにアクセスするには、Cloud Pub/Sub の Identity and Access Management 機能を使用してクロス プロジェクト権限を設定する必要があります。Cloud Dataflow はコントローラ サービス アカウントを使用してジョブを実行するので、このサービス アカウントに、別のプロジェクトの Cloud Pub/Sub リソースへのアクセス権を付与する必要があります。

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

他の Google Cloud Platform プロジェクトの Cloud Datastore にアクセスする

別の GCP プロジェクトが所有する Cloud Datastore にアクセスするには、Cloud Dataflow プロジェクトの Compute Engine(<project-number>-compute@developer.gserviceaccount.com)サービス アカウントを、Cloud Datastore を所有するプロジェクトの編集者として追加する必要があります。両方のプロジェクトで Cloud Datastore API を有効にすることも必要です。これは、https://console.cloud.google.com/project/<project-id>/apiui/apiview/datastore/overview で行います。

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

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

  • パイプラインをサービスに送信するとき
  • サービスがパイプラインを評価するとき
  • パイプラインの実行中と実行後にテレメトリーと指標へのアクセスをリクエストするとき

パイプラインの送信

Cloud Dataflow サービスへのアクセスは Google Cloud プロジェクトの権限によって制御します。編集またはオーナーの権利を付与されたプロジェクトのメンバーは、パイプラインをサービスに送信できます。パイプラインを送信するには、gcloud コマンドライン ツールを使用した認証が必要です。認証されると、パイプラインは HTTPS プロトコルを使用して送信されます。GCP アカウントの認証情報で認証する方法については、使用している言語のクイックスタートをご覧ください。

パイプラインの評価

一時データ

パイプラインを評価するときに、一時的なデータが生成されてワーカーのローカル環境または Cloud Storage に保存されることがあります。一時データは保存時に暗号化され、パイプラインの評価が終了した後は保持されません。

Java

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

Python

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

ログデータ

Cloud Logging に格納される情報は、主に Cloud Dataflow プログラムのコードによって生成されます。Cloud Dataflow サービスが警告やエラーのデータを生成して Cloud Logging に出力することもありますが、これはサービスがログに追加する中間データにすぎません。

処理中のデータ

パイプラインの評価中にデータが転送されるモードが 2 つあります。

  • ソースとシンクからの読み取り / 書き込み時。
  • ワーカー インスタンス間(パイプライン内で処理されるデータ部分)。

GCP のソースやシンクとの通信はすべて暗号化され、HTTPS を介して伝送されます。ワーカー間通信はすべてプライベート ネットワーク上で行われ、プロジェクトの権限とファイアウォール ルールの対象になります。

データの局所性

パイプラインのロジックは、個々の Compute Engine インスタンスで評価されます。これらのインスタンスのゾーンと、それらが通信するプライベート ネットワークの場所を指定できます。Google のインフラストラクチャで行われる補助的な計算は、メタデータ(Cloud Storage の場所やファイルサイズなど)に依存します。データがゾーンを離れたり、セキュリティ境界に違反したりすることはありません。

テレメトリーと指標

テレメトリー データと関連指標は暗号化した状態で保存され、このデータに対するアクセス権は GCP プロジェクトの読み取り権限によって制御されます。

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

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。