Credential Vending
A security architecture where a control plane issues short-lived, narrowly scoped S3 credentials at query time rather than relying on long-lived IAM roles or bucket policies for data access.
Summary
A security architecture where a control plane issues short-lived, narrowly scoped S3 credentials at query time rather than relying on long-lived IAM roles or bucket policies for data access.
The mechanism behind Iceberg REST Catalog's credential vending endpoint, Unity Catalog's external-location tokens, and Apache Polaris's scoped access. This is how modern lakehouse catalogs enforce fine-grained (table/row/column) access control over data stored in S3 without requiring consumers to have direct bucket access.
- Not the same as pre-signed URLs — credential vending issues full STS tokens scoped to specific S3 prefixes, supporting reads, writes, and listing.
- Requires a catalog that understands table-level metadata to scope tokens correctly. Without a catalog, credential vending degrades to bucket-level access.
- Token refresh and caching are performance-critical. Poorly implemented vending can add 50–200ms per query.
- Core enabler for Apache Polaris, Unity Catalog, and Iceberg REST Catalog Spec security models.
- Solves Policy Sprawl by centralizing access decisions in the catalog rather than in IAM.
- Enables Tenant Isolation without per-tenant buckets or prefix-based IAM policies.
Definition
An access control architecture where a central service issues short-lived, scoped credentials (typically STS tokens or signed URLs) to data consumers at query time, rather than granting persistent IAM roles or long-lived keys to storage buckets.
Traditional S3 access patterns use long-lived IAM credentials or bucket policies that grant broad access. Credential vending creates a control plane that evaluates policies (table-level, row-level, column-level) and mints temporary credentials scoped to exactly the S3 prefixes and objects a query needs. This is the mechanism behind Iceberg REST Catalog credential vending and how Unity Catalog and Apache Polaris enforce fine-grained access.
Multi-tenant lakehouse deployments, cross-engine S3 access with uniform security, row/column-level access control enforcement, zero-trust data lake architectures.
Recent developments
- The May 2026 Apache Polaris CVE cluster is the canonical real-world demonstration of the credential-vending threat model. Credential vending means the catalog issues short-lived, table-scoped cloud credentials on the client's behalf instead of sharing static keys; CVE-2026-42810 (CVSS 9.9 on 3.1 / 9.4 on 4.0) shows that when the scoping logic is wrong, that convenience becomes cross-tenant access — a table name with literal
*characters flows unescaped into the generated S3 IAM resource patterns ands3:prefixconditions, so credentials nominally scoped to one table match every table's prefix. CVE-2026-42811 is the identical failure against GCS Credential Access Boundary CEL expressions. Per CVE-2026-42810 (ThreatInt). - The generalized lesson: any identifier that reaches IAM/CEL policy generation must be escaped, validated, and authorized first. The Polaris failures cluster into two classes — injection (untrusted table/namespace names interpolated into policy strings without escaping, 42810/42811) and premature/under-validated vending (credentials minted from attacker-supplied
write.data.path/write.metadata.pathbefore location validation, 42809/42812). The defensive pattern for any credential-vending catalog: treat object names as untrusted input, escape wildcard/CEL metacharacters before policy synthesis, and validate-then-reserve the storage location before issuing scoped credentials — all addressed in Polaris 1.4.1. Per GHSA-w76p-3cgp-qfcm · Apache Polaris metadata write bypass (GitHub Advisory). - Iceberg REST Catalog credential vending is the canonical pattern. Catalog vends short-lived, scoped credentials per table instead of clients holding long-lived object-storage credentials — the table metadata is returned alongside short-lived storage credentials scoped to the table's storage location. Per IOMETE — Iceberg Access Delegation: Credential Vending and Remote Signing.
- Apache Polaris v1.4 (April 2026) ships AWS STS Session Tag Customization. Polaris v1.4 introduced several production-deployment updates centered on temporary credential vending — STS session tag customization is the headline. The Polaris server negotiates temporary tokens (STS scoped sessions, GCS service-account impersonation) instead of sharing raw IAM keys. Per DataLakeHouseHub — Choosing the Right Iceberg Control Plane.
- Google Cloud Lakehouse documents credential vending as default. Google Cloud's Lakehouse runtime catalog supports storage access delegation (credential vending) as the recommended pattern — improves security by removing the need for direct Cloud Storage bucket access by each engine. Per Google Cloud — Credential vending overview.
- Dremio implementation walk-through published. Dremio's engineering blog covers credential vending in Iceberg REST Catalogs with end-to-end deployment walk-through. Per Dremio — Credential Vending with Iceberg REST Catalogs.
- Cross-implementation feature request thread. The Apicurio Registry's REST-catalog implementation has an open feature request for credential vending support, signaling the pattern is becoming a standard expectation across REST-catalog implementations. Per GitHub — apicurio-registry issue #7669.
Connections 6
Outbound 6
scoped_to2enables2Resources 3
Iceberg REST Catalog specification including the credential vending endpoint that enables scoped S3 token issuance per table/namespace.
Unity Catalog open-source documentation covering external-location credential vending for Delta Lake tables on S3.
AWS Lake Formation credential vending documentation — the AWS-native implementation of scoped temporary credentials for data lake access.