Lakehouse ランタイム カタログの認証情報ベンダーを使用すると、ストレージ アクセスを委任し、データファイルにきめ細かい権限を適用できます。Lakehouse for Apache Iceberg の一部として、この機能を使用すると、Cloud Storage に保存されているテーブルの Identity and Access Management（IAM）ポリシーをテーブルレベルで管理できます。
gcloud CLI を使用して、これらのポリシーを取得して設定し、リソースへのアクセスを制御できます。
認証情報ベンディングの仕組み
認証情報ベンダーを使用すると、クエリ処理シーケンスがわずかに変更され、データの読み取り前にポリシーが適用されます。
- リクエスト: ユーザーがサポートされているエンジン（Apache Spark や BigQuery など）に SQL クエリを送信します。
- メタデータのルックアップ: エンジンは、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）を明示的に付与する必要があります。デフォルトでは、このサービス アカウントは閲覧者専用権限で作成されます。オブジェクト管理者アクセス権がない場合、ベンダーの認証情報でストレージの書き込みを実行できません。（注: コンソール UI で構成する場合は、[バケット権限を設定] をクリックすると、このロールが検証されます。gcloud、Terraform、API の設定では、このロールを手動で付与する必要があります。 - クエリエンジン サービス アカウント: クエリエンジン ジョブ（Managed Service for Apache Spark、Managed Service for Apache Spark、Dataflow など）を実行するサービス アカウントには、書き込みスコープでベンダー認証情報を取得するために、プロジェクト レベルで BigLake 編集者ロール（
roles/biglake.editor）が必要です。
次のステップ
- 認証情報ベンディング モードでカタログを作成する方法を学習する。
- Google Cloud コンソールを使用して既存のカタログで認証情報ベンダーを有効にする方法を確認する。
- 認証情報ベンディング用にクライアント アプリケーションを構成する方法を学習する。