BigQuery の承認済みビューの権限を Terraform で管理して、優先順位の競合状態を回避

※この投稿は米国時間 2023 年 2 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

Google BigQuery のインスタンス化などのインフラストラクチャのスピンアップを Terraform で行っている企業で、データセットと承認済みビューの両方に IAM アクセス権限リソース ブロックを使用する場合、どの権限を優先すべきかをめぐる競合状態に直面する可能性があります。

この問題が起きると、組織全体で BigQuery の運用に支障が生じ、データに一時的にアクセスできなくなるため、エンドユーザーに不便な思いをさせかねません。「限定公開データ」にアクセスできないエンドユーザーは、承認済みビューの使用頻度が非常に多くなる可能性があります。

このブログ投稿では、この競合状態の発生を回避する方法と、承認済みビューのアクセス権限を Terraform で正しく管理するための手順を説明します。内容は、ユースケース、問題の説明、解決策の 3 つの要素で構成されています。

1. ユースケース

ここで示すユースケースには、Google Cloud BigQuery と Hashicorp Terraform の 2 つのプロダクトが含まれます。両方のプロダクトのユースケースについて 1 つずつ見ていきましょう。

BigQuery は、ML、地理空間分析、ビジネス インテリジェンスなどの組み込み機能を使用してデータの管理と分析を支援する、Google Cloud のフルマネージド エンタープライズ データ ウェアハウスです。BigQuery を有効に活用するには、データセットが必要です。

データセットとは、BigQuery リソースへのアクセスを体系化して制御するために使用される論理コンテナ（特定のプロジェクト内に含まれる）のことです。データセットは他のデータベース システムのスキーマと似ています。テーブルまたはビューはデータセットに属していなければなりません。したがって、データを BigQuery に読み込む前に、1 つ以上のデータセットを作成する必要があります。

Cloud IAM は、メンバーのアクセスをテーブル レベルに制限できますが、「テーブルの一部」には制限できません。たとえば、データ閲覧者のロールを持つメンバーが、全従業員のアドレスにアクセスしなくても、テーブル内の特定の情報（部門ごとの特定の従業員の氏名や役職など）をクエリしてアクセスできるようにしたいとします。これを行うには、BigQuery の承認済みビューを作成します。承認済みビューを使用すると、元のソースデータへのアクセスを許可することなくクエリの結果を特定のユーザーやグループと共有することができます。

Google Cloud でのインフラストラクチャ プロビジョニングの業界基準は、HashiCorp の Terraform ツールを使用することです。Terraform は、すべてのインフラストラクチャ コンポーネントをインスタンス化するために使用され、BigQuery リソースをサポートしています。Terraform には、BigQuery データセットの IAM ポリシーを管理できるよう、google_bigquery_dataset_iam_policy、google_bigquery_dataset_iam_binding、google_bigquery_dataset_iam_member という 3 つの異なるリソースが用意されています。

2. 問題の説明

これらの BigQuery リソースは、BigQuery データセットの権限システムを標準の IAM インターフェースに変換することを目的としていますが、Terraform のドキュメントには、次のような警告が記載されています。「これらのリソースを使用すると、承認済みビューの権限がデータセットから削除されます。承認済みのビューの権限を割り当てて保持するには、google_bigquery_dataset_access を代わりに使用してください。」

これらのリソースはあらゆる状況に対応しているわけではなく、警告にあるように、「承認済みビュー」の権限に対しては適切に機能しません。BigQuery データセットの IAM ポリシーを管理する Google Terraform リソースには、それぞれ固有のユースケースがあります。

• google_bigquery_dataset_iam_policy: 権威。データセットの IAM ポリシーを設定して、すでにアタッチされている既存のポリシーを置き換えます。

• google_bigquery_dataset_iam_binding: 特定のロールに対する権威。IAM ポリシーを更新して、メンバーのリストにロールを付与します。データセットの IAM ポリシー内の他のロールは保持されます。

• google_bigquery_dataset_iam_member: 非権威。IAM ポリシーを更新して、新しいメンバーにロールを付与します。データセットのロールの他のメンバーは保持されます。

これらのリソースを承認済みビューと併せて使用すると、データセットから権限が削除されます。これらのリソースのいずれかを「google_bigquery_dataset_access」リソースまたは「google_bigquery_dataset」リソースの「access」フィールドと併用すると、どの権限を優先するかをめぐる競合状態がリソース間で発生します。つまり、Terraform コード内からのデータセットの作成と同時に、権限の作成と承認済みビューへの割り当てを行おうとすると、データセットと承認済みビューのポリシー間で競合が起き、その結果、承認済みビューの権限が削除されてしまいます。

この問題を次のように実際に再現して見てみましょう。

作成がうまくいったことは次のクエリとコンソールのスクリーンショットで確認できます。

Google Cloud コンソールから、作成されたデータセット、承認済みビュー、およびダミー SA を確認できます

次のコードを使用して、新規ユーザーをソース データセットに追加します。

これによって承認済みビューが取り消され、「dummy terraform」SA が以前は機能していたアクセスを失います。

前に説明したとおり、これは BQ データセットでの IAM の実装方法に基づく動作です。BigQuery データセットの IAM ポリシーに関連した制約事項をすべて考慮し、ニーズに最適な google_bigquery リソースを使用して Terraform を設計する必要があります。この例の問題の解決に役立ったリソースは google_bigquery_dataset_access です。このリソースは、データセットへのアクセス権を単一のエンティティに付与します。google_bigquery_dataset リソースに含めるアクセス ブロックの完全なリストをコンパイルできない場合に使用するもので、承認済みビューを作成するときに推奨されるリソースです。

以下の HCL コードでは、単一のエンティティにアクセス権を付与する google_bigquery_dataset_access の性質を踏まえ、データセット アクセス リソースに関するモジュールを作成しました。データセットのリストをループ処理して、データセットの詳細をモジュールに渡すことによって、そのデータセットから承認済みビューが削除されるのを回避できました。

結論として言えるのは、Terraform を使用した BigQuery での IAM の実装方法は独特で、他の Google Cloud サービスでの IAM の実装方法とは異なるということです。まず、特定の BigQuery 実装のアーキテクチャを理解してから、その理解に基づいて、どの BQ TF IAM リソースを使用するかを決定することが重要です。

以下のリンクにアクセスして、承認済みビューの作成についての詳細に目を通し、Google Cloud で利用可能な Terraform ブループリントを確認することをおすすめします。

• 承認済みビューを作成する

• Google Cloud の Terraform ブループリントとモジュール