Repository navigation
Trust GitHub Actions alongside the Source issuer #223
Description
Phase 4 — First shippable milestone.
Today
CI already exchanges real GitHub Actions tokens at /.sts on every same-repo run — but by swapping the trusted issuer, never running GitHub alongside our own. AUTH_ISSUER is a single String, while AUTH_AUDIENCE is already a list.
Do
- Trust both issuers at once.
- Pin subjects to a repository and ref. No organization-wide wildcards.
- Wire GitHub up as an Integration type end to end.
Done when
A workflow in an unrelated repository writes to a product using only its ambient OIDC token, with no stored secret.
Watch
aws-actions/configure-aws-credentialswill not work: it callsGetCallerIdentityafter the exchange, which is unimplemented upstream (feat(sts): GetCallerIdentity + real configure-aws-credentials integration test developmentseed/multistore#126). The SDKs' built-in web-identity credential providers do work. This is the way most people will first try it, so it needs saying in the docs.- Config plumbing spans three environments (
wrangler.tomlproduction and staging, pluswrangler.preview.toml).
Reconciled: source-cooperative/source.coop#432 was closed in favour of source-cooperative/source.coop#491, which absorbs it; this issue is that epic's proxy step for GitHub Actions. The work is in #237.
See ADR-009.
Depends on source-cooperative/source.coop#546, #221 and #222.
Part of source-cooperative/source.coop#491.
Activity
alukach commentedon Sep 21, 2026
Reconciled with source-cooperative/source.coop#491:
repo:*wildcards and the^repo:prefix as trust boundary are out; this issue's model (subjects pinned to repository and ref, issuer-qualified namespace via Namespace the credential subject by verified issuer #222) stands.GetCallerIdentityreference: feat(sts): GetCallerIdentity + real configure-aws-credentials integration test developmentseed/multistore#126 is the PR, open since 2026-07-23 and conflicting since 2026-07-27; the issue is multistore-sts: implement GetCallerIdentity (unblocks aws-actions/configure-aws-credentials) developmentseed/multistore#127. That stall is the schedule risk here.Vecchange — audience and subject conditions are per-Role, not per-issuer (STS roles should support multiple trusted OIDC providers, each with their own audience and subject conditions #152).alukach commentedon Sep 23, 2026
Contract change from source-cooperative/source.coop#566: no proof of control and no challenge. A manager trusts a GitHub subject on a service account from settings; the workflow mints its token for the proxy (
audience=the proxy origin), setsAWS_ROLE_ARN=arn:aws:iam::<service-account-id>:role/FullAccess,AWS_WEB_IDENTITY_TOKEN_FILE,AWS_ENDPOINT_URL_STS=<proxy>/.stsandAWS_ENDPOINT_URL_S3=<proxy>, and the SDK's web-identity provider does the exchange. The proxy verifies the GitHub token, reads the account fromRoleArn, asksPOST /api/v1/accounts/{id}/trusts/exchanges(#222), and mints from the account's memberships. Subjects stay pinned to one repository and one ref or environment. This is the step the settings page hands out: source-cooperative/source.coop#567alukach commentedon Sep 23, 2026
Update: the workflow step the settings page hands out now uses
aws-actions/configure-aws-credentials@v6withsts-endpointat the proxy,audience= the proxy origin androle-to-assume: arn:aws:iam::<service-account-id>:role/FullAccess(the action requires theawspartition). That makes developmentseed/multistore#126 (GetCallerIdentity, and/.sts/for the JS SDK's trailing slash) a hard dependency of this issue: the action validates the credentials it exports with a signedGetCallerIdentity. ItsAccountin the response should be the account segment the caller named, so the action'saws-account-idoutput is the service account.feat(accounts): trust subjects per account, the way a role's trust po…
feat(sts): serve the FullAccess and ReadOnly roles (#236)
feat(sts): let platform IdP tokens act as accounts that trust them (#237
feat(sts): answer GetCallerIdentity with multistore 0.8.0 (#248)