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

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

始める前に

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

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

Google Cloud Platform アカウント

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

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

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

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

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

Cloud Dataflow サービス アカウント

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

Dataflow サービス アカウントの権限は、gcloud コマンドライン ツールで、次のコマンドをシェルまたはターミナルに入力することで参照できます。

gcloud iam roles describe roles/dataflow.serviceAgent

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

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

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

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

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

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

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

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

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

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

ユーザー管理のサービス アカウントがない場合は、ジョブと同じプロジェクトにサービス アカウントを作成し、サービス アカウントに必要な IAM 役割を設定する必要があります。少なくとも、Dataflow ワーカーの役割をサービス アカウントに付与してください。また、ジョブで必要とされる Cloud Platform リソースを使用するための他の役割(BigQuery、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 パイプラインで他の Google Cloud プロジェクトの Google Cloud リソースにアクセスできます。たとえば、次のようなものがあります。

Java

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

Python

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

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

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

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

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

Dataflow プロジェクトのサービス アカウントのリストを取得するには、Cloud Console で [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>

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

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

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

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

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

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

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

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

次の Pub/Sub の役割の権限が必要です。

  • roles/pubsub.subscriber
  • roles/pubsub.viewer

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

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

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

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

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

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

パイプラインの送信

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

パイプラインの評価

一時データ

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

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 ファイルに書き込む場合、書き込みオペレーションがファイナライズされる前に一時ファイルが出力場所に作成されることがあります。

ログデータ

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

処理中のデータ

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

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

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

データの局所性

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

テレメトリーと指標

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

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