Outbound backend credential federation (OIDC identity → backend cloud STS)

Aperta
  • Qualcosa non va?
#56 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
aws, azure, google-cloud, rust
Ambito
authentication, backend-api-design, cloud, security

Direzione di ricerca

Non vengono nominati file o test; inizia leggendo i componenti esistenti multistore-sts e multistore-oidc-provider, quindi definisci l'ambito del nuovo crate multistore-federation sul branch feat/backend-federation. Il lavoro è completato quando la primitiva di scambio additivo della roadmap, il parsing XML e FederatedCredentials::apply_to(&mut BucketConfig) sono implementati e la validazione AWS end-to-end indicata va a buon fine.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

multistore federates identity inbound (callers → proxy, via multistore-sts + multistore-oidc-provider). The symmetric outbound half is missing: the proxy presenting its own identity to a backend cloud to obtain short-lived credentials for a private bucket.

Today a backend is either anonymous (anonymous_access / skip_signature) or configured with long-lived static keys in BucketConfig.backend_options. This issue tracks adding first-class outbound credential federation so deployments can serve private buckets without storing long-lived backend secrets. PRs below reference this issue.

Motivation

  • Operators increasingly want to front customer-owned buckets. Long-lived keys at the edge are a liability: rotation, blast radius, secret-at-rest.
  • With OIDC federation the bucket config holds only a role ARN; the proxy assumes a short-lived, optionally prefix-scoped role at request time. Trust and blast radius are governed by the bucket owner's IAM policies, not the proxy's correctness.
  • multistore already has the building blocks — it can act as an OIDC provider and already does inbound STS — so this simply completes the symmetry.

Design

At bucket-resolution time, per backend:

  1. Mint a short-lived OIDC assertion with the proxy's signing key (multistore-oidc-provider), scoped via its aud / sub claims.
  2. Exchange it at the backend cloud's STS — AWS AssumeRoleWithWebIdentity, with Azure / GCS workload-identity analogs — for temporary credentials.
  3. Inject those into BucketConfig.backend_options so the existing backend signs requests with them instead of going anonymous.

No long-lived secret is stored anywhere; credentials are short-lived and refreshed before expiry.

Constraints discovered while prototyping

  • S3 needs no core change. object_store's AmazonS3ConfigKey::Token accepts the token alias, and token is already in REDACTED_OPTION_KEYS, so temporary creds (access key + secret + session token) flow through and are redacted in logs.
  • Azure / GCS need a bearer-credential source. Workload-identity federation yields an OAuth bearer token, but the Azure backend takes a shared access_key and GCS a service_account_key — neither accepts a bearer token. Parity requires accepting bearer/access-token credentials (likely an object_store contribution).
  • Caching matters and is subtle. Short-lived creds must be cached and refreshed per backend, independent of the caller. Anything varied at assume-time is baked into the credential and fragments the cache, so the cache key should track the credential identity (role / subject), not the caller. This is a generic concern every integrator would otherwise reinvent.

Roadmap

  • Federation exchange primitive — new multistore-federation crate: a runtime-agnostic AssumeRoleWithWebIdentity request builder + XML response parser (caller owns HTTP), and FederatedCredentials::apply_to(&mut BucketConfig). Additive, no core changes. Branch: feat/backend-federation. Validated end-to-end against real AWS STS in a downstream deployment (mint → AssumeRoleWithWebIdentity → signed ListObjectsV2, including a sub trust-policy condition).
  • Caching credential provider — a BackendCredentialProvider trait + a caching wrapper (TTL, refresh-ahead, single-flight) so integrators get correct, non-thundering-herd refresh for free.
  • Azure / GCS bearer credential source — accept OAuth bearer tokens for the Azure and GCS backends to bring them to parity with S3.
  • Docs / example — wire federation into the example server / cf-workers runtimes.

Out of scope

Application-specific policy — which role to use for which bucket, and how the OIDC sub is structured/scoped — stays in the integrator's BucketRegistry. multistore provides the mechanism, not the policy.

Lingua principale
Rust
Stelle
21
Fork
1
Merge medio
16h 39m
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di developmentseed/multistore

Tutte le issue di developmentseed/multistore

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.