Design: storage credential for per-user warehouses — assumed IAM role instead of a stored key

[mengw15]

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:

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.

[mengw15]

@madhusudancs — thanks for the helpful advice in our meeting! Would love to get your thoughts when you get a chance.

[parshimers]

+1 for supporting assuming a role from an instance profile. AsterixDB uses this preferentially when using S3 as a backing object store when running in "cloud" mode. It makes life easy when it's possible.

[mengw15]

Rollout plan

We split the implementation into three phases. Phase 1 delivers the model end-to-end; Phases 2–3 harden it. (local/MinIO keeps the static-key path).

1. Assume the user's role — build the assumed-role model on Lakekeeper (already supports assume-role + external-id + vending): the system identity assumes each user's IAM role → short-lived credentials → vend. Removes the per-user stored secret.
2. Authenticate the Computing Unit — hardens the CU ↔ Lakekeeper step from Phase 1: the CU authenticates (OIDC) so vended credentials reach only the right execution. Required for multi-tenant safety.
3. Deploy — provision the per-deployment system identity keyless (IRSA / instance profile) and wire it into the Kubernetes deployment via Terraform.