Lakehouse ランタイム カタログの認証情報ベンディングを使用すると、ストレージ アクセスを委任し、データファイルにきめ細かい権限を適用できます。これは Lakehouse for Apache Icebergの一部であり、Cloud Storage に保存されているテーブルのテーブルレベルで Identity and Access Management（IAM） ポリシーを管理できます。
gcloud CLI を使用して、これらのポリシーを取得して設定し、リソースへのアクセスを制御できます。
認証情報ベンディングの仕組み
認証情報ベンディングを使用する場合、ストレージにアクセスする前にポリシーを適用するために、オペレーションのシーケンスが若干変更されます。
- リクエスト: ユーザーは、クエリ、DML、DDL オペレーションなどの SQL ステートメントをサポートされているエンジンに送信します。たとえば、Apache Spark や BigQuery などです。
- メタデータのルックアップ: エンジンは、テーブルを解決するために Lakehouse ランタイム カタログにリクエストを送信します。
- 認証とポリシー: カタログはユーザーを認証し、Google Cloud の Lakehouse リソースに対する IAM 権限を確認します。
- レスポンス: 認証情報ベンディングが有効になっているため、カタログはメタデータと有効期間の短いストレージ トークン （スコープが縮小されたストレージ認証情報）をエンジンに返します。トークンはテーブルに関連付けられたパスにスコープ設定され、必要な最小限の権限（ファイルの書き込みを必要としないクエリの読み取り専用アクセスなど）にスコープが縮小されます。
- アクセス: エンジンはこのトークンを使用して、承認された特定のファイルを Cloud Storage から直接読み取りまたは書き込みます。
- コンピューティング: エンジンはデータを処理またはオペレーションを実行し、結果を返します。
サポートされているエンジン
クエリエンジンで認証情報ベンディングを使用するには、Lakehouse Iceberg REST カタログが認証情報ベンディングをサポートするように構成されている必要があります。
- オープンソース エンジン: Apache Spark や Trino などのサポートされているエンジンは、カタログによってベンディングされた有効期間の短いストレージ トークンを使用します。クライアント アプリケーションは、
X-Iceberg-Access-Delegationヘッダーで認証情報ベンディングのサポートを指定する必要があります。 - BigQuery: BigQuery は、エンドユーザーの認証情報の代わりに、Cloud Storage アクセスにベンディングされた認証情報を使用します。
サービス アカウントに必要な権限
認証情報ベンディングが有効になっている場合は、次のサービス アカウントに必要なロールがあることを確認してください。
- 自動プロビジョニングされた Lakehouse ランタイム カタログ サービス アカウント: 関連するすべての Cloud Storage バケットで、この
アカウントに Storage オブジェクト ユーザーロール（
roles/storage.objectUser）を付与する 必要があります。このアクセス権がないと、ベンディングされた認証情報でストレージの読み取りや書き込みを行うことはできません。コンソールを使用する場合は、[**バケット権限を設定**] をクリックすると、このロールが検証されます。Google Cloud gcloud CLI、Terraform、API の場合は、このロールを手動で付与する必要があります。 - クエリエンジン サービス アカウント: クエリエンジン
ジョブ（Managed Service for Apache Spark、Managed Service for Apache Spark、
Dataflow など）を実行するサービス アカウントには、BigLake 編集者ロール（
roles/biglake.editor）が 必要です。これは、書き込みスコープでベンディングされた認証情報を取得するためです。
次のステップ
- 認証情報ベンディング モードでカタログを作成する方法を学習する。
- コンソールを使用して既存のカタログで認証情報ベンディングを有効にする方法を
Google Cloud 学習する。
- 認証情報ベンディング用にクライアント アプリケーションを構成する方法を 学習する。