Outbound backend credential federation (OIDC identity → backend cloud STS)
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- aws, azure, google-cloud, rust
調査の方向性
ファイルやテストは指定されていないため、まず既存の multistore-sts と multistore-oidc-provider コンポーネントを読み、次にブランチ feat/backend-federation 上で新しい multistore-federation crate のスコープを定めます。完了とは、ロードマップの加算的交換プリミティブ、XML パース、および FederatedCredentials::apply_to(&mut BucketConfig) が実装され、記載された AWS エンドツーエンド検証に合格することです。
索引モデルが issue の本文から書いたものです。
説明
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:
- Mint a short-lived OIDC assertion with the proxy's signing key (
multistore-oidc-provider), scoped via itsaud/subclaims. - Exchange it at the backend cloud's STS — AWS
AssumeRoleWithWebIdentity, with Azure / GCS workload-identity analogs — for temporary credentials. - Inject those into
BucketConfig.backend_optionsso 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::Tokenaccepts thetokenalias, andtokenis already inREDACTED_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_keyand GCS aservice_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-federationcrate: a runtime-agnosticAssumeRoleWithWebIdentityrequest builder + XML response parser (caller owns HTTP), andFederatedCredentials::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→ signedListObjectsV2, including asubtrust-policy condition). - Caching credential provider — a
BackendCredentialProvidertrait + 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.
- 主要言語
- Rust
- スター
- 21
- フォーク
- 1
- 平均マージ
- 8時間 29分
- マージ済み PR（30日）
- 2
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
developmentseed/multistore のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
developmentseed/multistore#160 ·
-
List of a prefix 503s when a single object key contains an empty path segment (//)対応中かも @alukach が 106 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 55/100
developmentseed/multistore#116 · コメント 1 件 ·
-
enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 68/100
-
oidc-provider: optional `oidc_session_name` backend-option to override RoleSessionName derivationオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 35/100
-
Credential cache key (role ARN) doesn't capture the full minted identity (subject + extra_claims)オープン
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
developmentseed/multistore の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
near/near-sdk-rs#1676 ·
メンテナーはふだん 2 日以内に返信
-
auto:producer auto:security
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
fritzprix/libr-agent#2595 ·
メンテナーはふだん 1 日以内に返信
-
area:fs type:fix
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
Tripstack-Corp/spyc#1002 ·
メンテナーはふだん 1 日以内に返信
-
github_actions security
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
dekobon/big-code-analysis#1815 ·
メンテナーはふだん 1 日以内に返信
-
[Detail Bug] Request logs can be forged via control characters in fetch object keys (log injection)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
s2-streamstore/cachey#211 ·
メンテナーはふだん 1 日以内に返信