Skip to content

fix(lakekeeper): set ACCESS_DELEGATION_MODE 'none' on Iceberg ATTACH#600

Merged
fuziontech merged 1 commit into
mainfrom
lakekeeper-attach-delegation-none
May 21, 2026
Merged

fix(lakekeeper): set ACCESS_DELEGATION_MODE 'none' on Iceberg ATTACH#600
fuziontech merged 1 commit into
mainfrom
lakekeeper-attach-delegation-none

Conversation

@fuziontech
Copy link
Copy Markdown
Member

Summary

The Lakekeeper Iceberg ATTACH omitted ACCESS_DELEGATION_MODE, on the assumption that omitting it meant "don't vend." It doesn't — DuckDB's iceberg extension defaults the mode to 'vended_credentials'. So the worker still requested credential delegation on every table load.

Since warehouse-side STS vending is disabled (#594, to avoid PackedPolicyTooLarge), Lakekeeper responded with a per-table storage config (region/endpoint) carrying no credentials. DuckDB materialized that into a path-scoped S3 secret with empty creds, and because its scope (the table's S3 prefix) is more specific than iceberg_sigv4's (s3://), it shadowed the duckling's real brokered-creds secret. Every data read/write then went out anonymous → S3 403 Forbidden.

Catalog metadata ops (CREATE SCHEMA/TABLE via the Lakekeeper REST API) worked fine — only the client-side S3 data path was broken, which is why provisioning looked green.

Fix

Set ACCESS_DELEGATION_MODE 'none' explicitly on both ATTACH branches (allowall + OAuth2). DuckDB then never creates the empty shadow secret and falls back to the ambient iceberg_sigv4 secret, which holds the duckling's own brokered S3 creds for the warehouse bucket.

Verification (live, ben in managed-warehouse-dev)

  • With the option omitted (current main): INSERT403 Forbidden writing the parquet data file; SELECT returned 0 rows.
  • After re-ATTACHing with ACCESS_DELEGATION_MODE 'none': CREATE SCHEMA / CREATE TABLE / INSERT / SELECT round-trip through Lakekeeper to S3 — parquet data + Iceberg metadata (metadata.json, manifest/snapshot .avro) land in s3://posthog-duckling-ben-mw-dev/lakekeeper/.../data/, and rows read back correctly.

Unit tests updated to assert the delegation option on both branches.

🤖 Generated with Claude Code

The Lakekeeper ATTACH omitted ACCESS_DELEGATION_MODE entirely, assuming
that meant "no vending." It doesn't: DuckDB's iceberg extension defaults
the mode to 'vended_credentials'. So the client still requested delegation,
and since warehouse-side STS vending is disabled (#594, PackedPolicyTooLarge),
Lakekeeper returned a per-table storage *config* (region/endpoint) with NO
credentials. DuckDB materialized that as a path-scoped S3 secret with empty
creds whose scope (the table's S3 prefix) is more specific than iceberg_sigv4's
(s3://), so it shadowed the duckling's real brokered-creds secret. Every data
read/write went out anonymous and S3 returned 403.

Set ACCESS_DELEGATION_MODE 'none' explicitly on both ATTACH branches so DuckDB
never creates that empty shadow secret and falls back to iceberg_sigv4.

Verified live on `ben` in managed-warehouse-dev: with the option omitted,
INSERT 403'd at the parquet write; with 'none', CREATE TABLE / INSERT / SELECT
round-trip through Lakekeeper to S3 (data + metadata land in the warehouse
bucket, rows read back).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@fuziontech fuziontech merged commit 70f4106 into main May 21, 2026
22 checks passed
@fuziontech fuziontech deleted the lakekeeper-attach-delegation-none branch May 21, 2026 16:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant