Support AWS SDK-native credential acquisition against /.sts

[alukach]

Goal

Let standard AWS tooling exchange OIDC tokens for proxy credentials directly against /.sts, with no custom exchange code:

• AWS SDK built-in web-identity providers: set AWS_WEB_IDENTITY_TOKEN_FILE, AWS_ROLE_ARN, and AWS_ENDPOINT_URL_STS, and boto3 / aws-cli / SDK-JS auto-exchange and auto-refresh credentials.
• aws-actions/configure-aws-credentials in GitHub Actions: mint the runner's OIDC token and exchange it at the proxy in two lines of YAML (the audience: input maps onto AUTH_AUDIENCE), replacing hand-rolled curl/exchange plumbing like the one in tests/test_writes.py.

/.sts already speaks AssumeRoleWithWebIdentity semantics and returns AWS-shaped XML that SDKs can parse, so this is close to working already.

Blockers

Exactly two mismatches stand in the way:

1. Transport (fix in multistore) — AWS SDK STS clients send AssumeRoleWithWebIdentity as a form-encoded POST body; the multistore-sts handler parses the query string only (try_parse_sts_request reads req.query). Real AWS STS accepts both, so accepting body params is protocol-faithful.

2. Role naming (fix in this repo) — the proxy serves a single role with the literal id _default (src/sts.rs), but AWS clients validate RoleArn client-side before sending (botocore enforces ARN shape and a 20-char minimum), so RoleArn=_default never reaches the server. Accepting an ARN-shaped alias (e.g. arn:aws:iam::000000000000:role/_default) unblocks SDK clients without changing the trust model — it's the same role under a longer name. This also dovetails with the existing TODO in src/sts.rs about per-product roles, which would want ARN-shaped ids anyway.

Acceptance

With both changes deployed (and the multistore dependency bumped here):

export AWS_WEB_IDENTITY_TOKEN_FILE=/path/to/oidc-token
export AWS_ROLE_ARN=arn:aws:iam::000000000000:role/_default
export AWS_ENDPOINT_URL_STS=https://data.source.coop/.sts
aws s3 ls s3://cholmes/ --endpoint-url https://data.source.coop

acquires and refreshes proxy credentials with no custom code, and aws-actions/configure-aws-credentials pointed at the proxy works in CI.

🤖 Generated with Claude Code

Compatibility bar

/.sts must be a drop-in replacement for AWS STS for AssumeRoleWithWebIdentity: an unmodified AWS SDK or the configure-aws-credentials action pointed at it via AWS_ENDPOINT_URL_STS must work without proxy-specific code paths. That means accepting both query-string and form-encoded body parameters, honoring Action/Version/DurationSeconds as STS does, and returning STS-shaped success and error XML.

[alukach]

Implementation status:

• feat(sts): accept ARN-shaped alias for the _default role #185 — accept ARN-shaped alias (arn:*…:role/_default) for the _default role, unblocking AWS clients' client-side RoleArn validation (draft)
• feat(sts): accept AssumeRoleWithWebIdentity params from form-encoded POST bodies developmentseed/multistore#112 — accept AssumeRoleWithWebIdentity params from form-encoded POST bodies, the shape AWS SDKs send (draft)
• multistore release containing feat(sts): accept AssumeRoleWithWebIdentity params from form-encoded POST bodies developmentseed/multistore#112
• bump multistore dependency here (also picks up the runtime wiring: call RequestParts::absorb_form_body in src/lib.rs before dispatch, mirroring the updated cf-workers example)
• verify end-to-end: boto3 web-identity provider + aws-actions/configure-aws-credentials with AWS_ENDPOINT_URL_STS against a deployed worker; a CI test can then use the SDK-native flow instead of the hand-rolled exchange in tests/test_writes.py

[alukach]

Review: gaps found before configure-aws-credentials can work

Verified against the action's current source, multistore-sts 0.6.4, and this repo. Two corrections to the plan above:

New blocker: the action requires GetCallerIdentity

After AssumeRoleWithWebIdentity succeeds, aws-actions/configure-aws-credentials unconditionally validates the returned credentials with a SigV4-signed sts:GetCallerIdentity against the same sts-endpoint (index.ts post-assume validateCredentials → getCallerIdentity, which throws unless Account and Arn come back). There is no input to skip it; it retries 12× with backoff, then fails the step.

multistore-sts only parses Action=AssumeRoleWithWebIdentity (request.rs), so the action fails even with #185 + multistore#112 deployed. The plain SDK path (boto3 / aws-cli via AWS_ENDPOINT_URL_STS) is unaffected — SDK web-identity providers never call GetCallerIdentity.

Filed developmentseed/multistore#127 for the fix: implement Action=GetCallerIdentity — verify SigV4 (service sts, region-agnostic) over the sealed-token credentials, return Account/Arn/UserId XML with the fabricated account (000000000000, consistent with the ARN alias). Gotcha: the JS SDK POSTs to /.sts/ (it builds basePath + "/") and signs that canonical URI, so signature verification must use the raw sent path; this repo already normalizes /.sts/ → /.sts for routing only.

Correction: the audience: input does NOT map onto AUTH_AUDIENCE

The action's built-in OIDC path (core.getIDToken(audience)) mints a token issued by token.actions.githubusercontent.com. The proxy's _default role trusts only the Source Cooperative issuer, so that token fails JWKS verification regardless of audience. Adding GitHub as a trusted issuer is not an option either: _default has no subject_conditions, so any GitHub repo's workflow could mint aud=AUTH_AUDIENCE tokens and obtain credentials.

The workable action config is web-identity-token-file: pointing at a Source-Coop-issued token — the action replaces the exchange plumbing (the hand-rolled curl in tests/test_writes.py), not the token minting.

Confirmed fine

• Endpoint path prefix: botocore preserves /.sts exactly; the JS SDK sends /.sts/, which src/lib.rs already normalizes. The action's sts-endpoint: input wires straight into STSClient({endpoint}) — no reliance on AWS_ENDPOINT_URL_STS.
• The action's extra params (DurationSeconds=3600, RoleSessionName) are ignored harmlessly.
• Cosmetic: the action's aws-account-id output / allowed-account-ids guardrail will see 000000000000.

Updated checklist item to add: multistore-sts GetCallerIdentity support (developmentseed/multistore#127 — blocks the configure-aws-credentials half of the acceptance criteria; the boto3/CLI half needs only the existing items).

🤖 Generated with Claude Code