Dataproc 協調型マルチテナンシー
Google Cloud Japan Team
※この投稿は米国時間 2020 年 11 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。
Dataproc では、データ アナリストが BI ワークロードを実行し、ダッシュボード、レポート、分析情報の生成が行えます。さまざまなチームのデータ アナリストがデータを分析して、多様なレポート、ダッシュボード、分析情報を生成しており、Dataproc ワークロードに対するマルチテナンシーへの需要は高まりつつあります。現在、クラスタ上のすべてのユーザーのワークロードは単一のサービス アカウントとして実行されるため、すべてのワークロードが同じデータアクセスを共有します。Dataproc 協調型マルチテナンシーを使用すると、データアクセスの異なる複数のユーザーが同じクラスタでワークロードを実行できます。
Dataproc クラスタでは通常、ワークロードをクラスタ サービス アカウントとして実行します。Dataproc 協調型マルチテナンシーを使用して Dataproc クラスタを作成すると、Cloud Storage リソースにアクセスするジョブの実行時にユーザー ID を分離できます。サービス アカウントへの Cloud IAM ユーザーのマッピングはクラスタの作成時に指定され、任意のクラスタに対して多くのサービス アカウントを構成することができます。これは、Cloud Storage とのインタラクションが、クラスタ サービス アカウントではなく、ジョブを送信するユーザーにマッピングされるサービス アカウントとして認証されることを意味します。
考慮事項
Dataproc 協調型マルチテナンシーでは以下を考慮する必要があります。
dataproc:ataproc.cooperative.multi-tenancy.user.mapping プロパティを有効にして、Cloud IAM ユーザーのサービス アカウントへのマッピングを設定します。ユーザーがクラスタにジョブを送信すると、VM サービス アカウントはこのユーザーにマッピングされたサービス アカウントとして動作し、GCS コネクタを介してそのサービス アカウントとして Cloud Storage とインタラクションを行います。
GCS コネクタのバージョンは、少なくとも 2 1 4 である必要があります。
Kerberos が有効なクラスタはサポートされていません。
Dataproc Jobs API を介して送信されたジョブのみを対象としています。
目標
このブログでは、以下の項目について説明します。
Dataproc 協調型マルチテナンシーを有効にして Dataproc クラスタを作成する
さまざまなユーザー ID を使用してジョブをクラスタに送信し、Cloud Storage とのインタラクション発生時に適用されるさまざまなアクセスルールを識別およびモニターする
Stackdriver Logging を使用して、さまざまなサービス アカウントで Cloud Storage とのインタラクションが認証されることを確認
始める前に
プロジェクトを作成する
1.Cloud Console のプロジェクト セレクタページで、Cloud プロジェクトを選択または作成します。
2.Google Cloud プロジェクトの課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法
3.Dataproc API を有効にします。
4.Stackdriver API を有効にします。
2 番目のユーザーをシミュレートする
通常、2 番目のユーザーとして別のユーザーがいますが、さらに別のサービス アカウントを使用して 2 番目のユーザーをシミュレートすることもできます。異なるユーザーとしてクラスタにジョブを送信するので、2 番目のユーザーをシミュレートするために gcloud 設定でサービス アカウントをアクティブ化できます。
まず、gcloud で現在アクティブ化されているアカウントを取得します。ほとんどの場合、これはユーザーの個人アカウントです。
- サービス アカウントを作成します。
- Dataproc クラスタにジョブ送信するための適切なアクセス許可をサービス アカウントに付与します。
サービス アカウントのキーを作成し、そのキーを使用して gcloud でアクティブ化します。キーファイルは、サービス アカウントがアクティブ化されたら削除できます。
ここで、次のコマンドを実行します。
すると、このサービス アカウントがアクティブ アカウントとして表示されます。以下の例に進むには、元のアクティブ アカウントに切り替えてください。
サービス アカウントを構成する
3 つのサービス アカウントを追加で作成します。1 つは Dataproc VM サービス アカウントとして、残りの 2 つはユーザーにマッピングするサービス アカウント（ユーザー サービス アカウント）として作成します。注: クラスタごとに VM サービス アカウントを使用し、特定のクラスタで使用する予定のユーザー サービス アカウントにのみ元のアカウントの代わりになることを許可するようおすすめします。
2 つのユーザー サービス アカウントに対する VM サービス アカウントに iam.serviceAccountTokenCreator ロールを付与して、元のアカウントの代わりとなるようにします。
および
クラスタ VM で必要なジョブを実行できるように、VM サービス アカウントに dataproc.worker ロールを付与します。
Cloud Storage のリソースを作成しサービス アカウントを構成する
バケットを作成します。
- バケットに簡単なファイルを書き込みます。
1 番目のユーザー サービス アカウントにのみバケットへの管理者権限である USER_SA_ALLOW を付与します。
クラスタを作成し、サービス アカウントを構成する
この例では、ユーザー「FIRST_USER」（個人ユーザー）を GCS 管理者権限を持つサービス アカウントにマッピングし、ユーザー「SECOND_USER」（サービス アカウントとしてシミュレート）を GCS アクセスを持たないサービス アカウントにマッピングします。
協調型マルチテナンシーが使用できるのは、バージョン 2.1.4 以降の GCS コネクタのみである点に注意してください。これは Dataproc イメージのバージョン 1.5.11 以降にプリインストールされていますが、コネクタの初期化アクションを使用すると、古い Dataproc イメージに特定のバージョンの GCS コネクタをインストールできます。
VM サービス アカウントは、generateAccessToken API を呼び出して、ジョブ サービス アカウントのアクセス トークンをフェッチする必要があるため、クラスタに適切なスコープがあることを確認してください。以下の例では、クラウド プラットフォーム スコープを使用します。
注:
1. ユーザー サービス アカウントは、ジョブを実行するためクラスタに関連付けられた構成バケットへのアクセス権が必要となる場合があるため、必ずユーザー サービス アカウントにアクセス権を付与してください。
2. 1.5+ のイメージを含む Dataproc クラスタでは、デフォルトで、Spark と MapReduce の履歴ファイルがクラスタに関連付けられた一時バケットに送信されるため、ユーザー サービス アカウントにこのバケットへのアクセスを付与しておくとよいでしょう。
サンプルジョブを実行する
Spark ジョブを「FIRST_USER」として実行すると、マッピングされたサービス アカウントが GCS ファイルの gs://${BUCKET}/file にアクセスできるため、ジョブは成功します。
ジョブが正常に実行されると、次のような出力が得られます。
ここで、「SECOND_USER」と同じジョブを実行します。マッピングされたサービス アカウントが GCS ファイル gs://${BUCKET}/file にアクセスできないことからジョブが失敗し、ドライバの出力には原因として権限エラーが示されます。
また、ジョブドライバは、使用されているサービス アカウントに GCS ファイルへの storage.get.access がないことが原因であることも示します。
同様に、Hive ジョブ（GCS で外部テーブルを作成し、レコードを挿入してからレコードを読み取る）で、ユーザー「FIRST_USER」として以下を実行すると、マッピングされたサービス アカウントがバケット <BUCKET> にアクセスできるため成功します。
ただし、テーブル employee を別のユーザー 「SECOND_USER」としてクエリすると、ジョブはバケットにアクセスできない 2 番目のユーザー サービス アカウントを使用するので、ジョブは失敗します。
Stackdriver Logging で、Cloud Storage でのサービス アカウント認証を確認する
まず、バケットにアクセスできる 1 番目のサービス アカウントの使用状況を確認します。
gcloud のアクティブ アカウントが個人アカウントであることを確認します。
- GCS 権限を持つサービス アカウントを使用してバケットへのアクセスに関するログを検索します。
アクセス許可が常に付与されていることが確認できます。
protoPayload:
'@type': type.googleapis.com/google.cloud.audit.AuditLog
authenticationInfo:
principalEmail: [USER_SA_ALLOW]
...
authorizationInfo:
- granted: true
permission: storage.objects.get
resource: projects/_/buckets/[BUCKET]/objects/file
resourceAttributes: {}
バケットにアクセスできないサービス アカウントを確認します。
アクセス許可が付与されていないことが確認できます。
VM サービス アカウントがバケットへのアクセスに直接使用されたことのないことが確認できます（次の gcloud コマンドで 0 のログエントリが返される）。
クリーンアップ
クラスタを削除します。
- バケットを削除します。
- 2 番目のユーザーのシミュレーションに使用されたサービス アカウントを非アクティブ化します。
- サービス アカウントを削除します。
注
1.協調型マルチテナンシー機能は、Kerberos が有効なクラスタではまだ利用できません。
2.サービス アカウントがマッピングされていないユーザーが送信したジョブは、GCS リソースへのアクセス時にフォールバックして VM サービス アカウントを使用します。ただし、`core:fs.gs.auth.impersonation.service.account` プロパティを設定して、フォールバックするときのサービス アカウントを変更できます。このフォールバック サービス アカウントのアクセス トークンをフェッチするため、VM サービス アカウントは `generateAccessToken` を呼び出す必要があります。
以上、このブログでは、Dataproc 協調型マルチテナンシーを使用して、複数のユーザー間で Dataproc クラスタを共有する方法について説明しました。
-データ分析担当プロダクト マネージャー Susheel Kaushik
-ソフトウェア エンジニア Chao Yuan
