Within Google Cloud Lakehouse, you use the Lakehouse runtime catalog to manage metadata for your Lakehouse Iceberg REST catalog tables stored in Cloud Storage.
This document explains how to get and set Identity and Access Management (IAM) policies at
the table level to control access to these resources using the gcloud CLI.
How credential vending works
When you use credential vending, the query processing sequence changes slightly to enforce policies before data is read:
- Request: A user submits a SQL query to a supported engine (for example, Apache Spark or BigQuery).
- Metadata lookup: The engine sends a request to the Lakehouse runtime catalog to resolve the table.
- Authentication and policy: The catalog authenticates the user and checks their IAM permissions on the Google Cloud Lakehouse resources.
- Response: Because credential vending is enabled, the catalog returns the metadata and a short-lived storage token (downscoped storage credentials) to the engine.
- Read: The engine uses this token to read the specific authorized files directly from Cloud Storage.
- Compute: The engine processes the data and returns the results.
Supported engines
In order to use credential vending with query engines, your Lakehouse Iceberg REST catalog must be configured to support credential vending.
- Open source engines: Supported engines like Apache Spark and
Trino use short-lived storage tokens vended by the catalog. Your client
application must specify support for credential vending in the
X-Iceberg-Access-Delegationheader. - BigQuery: BigQuery uses vended credentials for Cloud Storage access instead of end-user credentials.
What's next
- Learn how to create a catalog in credential vending mode.
- Learn how to enable credential vending for an existing catalog using the Google Cloud console.
- Learn how to configure your client application for credential vending.