GitHub user mengw15 created a discussion: Design: storage credential for
per-user warehouses — assumed IAM role instead of a stored key
## Summary
A per-user warehouse (#5293) needs a **storage credential** to reach the user's
S3. This is about which credential model to use:
- **Store a static access key** — (`LakekeeperClient` registers the warehouse
with `credential-type: access-key`, STS off). The key is a long-lived secret
held in Lakekeeper's DB.
- **Assume an IAM role (proposed)** — the warehouse stores only **non-secret
config** (role ARN + external ID); the credential is obtained **per execution
at runtime** (the system identity assumes the role → short-lived creds → vend).
No long-lived secret is stored.
#5293 already vends **short-lived** credentials per request on the data path;
with a stored key those are still derived from a long-lived root secret. The
assumed-role model removes that root secret entirely — nothing long-lived in
Texera or Lakekeeper.
This handshake is not new — it's the standard cross-account access pattern (an
IAM role assumed via STS, gated by an external ID) that the major managed data
platforms use for bring-your-own storage. We'd be adopting the proven
mechanism, not inventing one.
## Background / Motivation
Storing a static access key means a long-lived secret in Lakekeeper's encrypted
DB:
- it never expires — if it leaks, it stays valid until manually rotated;
- a Lakekeeper-DB compromise exposes **every** user's root credential.
It works, but a stored long-lived secret isn't what we want to ship.
## Proposed change
Make the warehouse's storage credential an **assumed role**, not a stored key:
at registration the user provides an IAM **role ARN** (no key), and Texera
stores only the role ARN + external ID (non-secret config). At runtime, per
execution, the deployment's system identity assumes the role → short-lived
creds → vend.
1. **Per-deployment system identity** — the platform's AWS identity that
assumes users' roles. Could be provisioned via IaC (e.g., Terraform).
2. **Per-warehouse external ID, minted upfront** — Texera reserves the external
ID when the user starts setup and shows `{system identity ARN + external ID}`,
so the role's trust policy is set in **one step** (no reveal round-trip).
3. **Server-side binding (security-critical)** — the external ID and role ARN
are always looked up from the authenticated user's own warehouse record, never
taken from client input. Prevents the cross-tenant confused-deputy problem.
**Sequence diagram:**
<img width="1137" height="637" alt="Screenshot 2026-06-30 at 3 52 39 PM"
src="https://github.com/user-attachments/assets/dbdeea19-2618-4e49-8720-cb64f2a56ea6";
/>
<img width="1138" height="633" alt="Screenshot 2026-06-30 at 3 53 24 PM"
src="https://github.com/user-attachments/assets/7c678a80-597c-4518-afbe-23d860231e07";
/>
## Scope
Same as #5293 — per-user warehouses are scoped to the Kubernetes deployment.
The assumed-role model applies to real AWS S3 + IAM. Local / dev deployments
could be backed by MinIO keep the static access-key path
## Why this is secure
- A leaked external ID + role ARN is **harmless**: the user's role trusts only
the deployment's system identity, and an attacker can't act as that identity
without its credentials.
- The external ID isn't a secret; its protection is being **unique per
warehouse + bound server-side**.
- The remaining risk is the system identity's **own** credentials leaking.
## Open questions
- External ID granularity: **per-warehouse** vs **per-user** (simpler if one
IAM role is reused across a user's warehouses).
GitHub link: https://github.com/apache/texera/discussions/6040
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
