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 学習する。
- 認証情報 ベンダー用にクライアント アプリケーションを構成する方法を学習する。