Skip to content

[WIP] feat: add STS credential vending to Catalog API - #1

Open
briangallagher wants to merge 2 commits into
Fiona-Waters:catalog-api-saved-datasetfrom
briangallagher:feat/sts-credential-vending
Open

briangallagher wants to merge 2 commits into
Fiona-Waters:catalog-api-saved-datasetfrom
briangallagher:feat/sts-credential-vending

Conversation

@briangallagher

Copy link
Copy Markdown

Summary

Adds scoped, temporary S3 credential vending to the Catalog API's loadTable and getVolume handlers via MinIO/AWS STS AssumeRole.

When STS_ENDPOINT, STS_ACCESS_KEY, and STS_SECRET_KEY environment variables are set on the Feast server pod, the server mints per-request credentials scoped to each asset's S3 prefix using an inline IAM session policy. Credentials are returned in the response config map, following the Iceberg REST Catalog spec's credential vending pattern.

Changes

  • New credentials.py — STSCredentialVender class that calls STS AssumeRole with an inline policy restricting access to the specific table/volume S3 prefix
  • tables.py — loadTable handler populates config with vended s3.access-key-id, s3.secret-access-key, s3.session-token when STS is configured and the table has an s3:// location
  • volumes.py — getVolume handler does the same; VolumeInfo model gains a config field
  • __init__.py — creates the vender at startup from env vars and passes it to table/volume routers

What this does NOT change

  • No DB or proto changes — STS config is env-var-only, vended credentials are ephemeral (never persisted)
  • No changes to existing Feast registry behaviour
  • Graceful fallback — if STS is not configured or vending fails, responses are unchanged (no credentials in config)

How it works with PyIceberg

PyIceberg's REST catalog client automatically reads s3.access-key-id, s3.secret-access-key, s3.session-token from the loadTable config map — so credential vending is transparent to the user. No code changes needed in notebooks.

Testing

To be validated on the Option 2 POC cluster against MinIO STS (AssumeRole with inline policy scoping). A demo notebook comparing static vs STS credential flows is in progress.

Made with Cursor

Add scoped, temporary S3 credential vending to the loadTable and
getVolume handlers via MinIO/AWS STS AssumeRole. When STS_ENDPOINT,
STS_ACCESS_KEY, and STS_SECRET_KEY env vars are set, the server
mints per-request credentials scoped to each asset's S3 prefix.

Changes:
- New credentials.py with STSCredentialVender class
- loadTable returns vended creds in the config map (Iceberg REST spec)
- getVolume returns vended creds in a new config field on VolumeInfo
- No DB or proto changes — config is env-var-only, vending is
  request-scoped and never persisted
MinIO STS rejects s3:prefix as a condition key for s3:GetObject.
Separate into two statements: GetObject scoped by resource ARN,
ListBucket scoped by s3:prefix condition.
@briangallagher briangallagher changed the title feat: add STS credential vending to Catalog API [WIP] feat: add STS credential vending to Catalog API Jul 13, 2026
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