OXYGENHUB

Keyless bucket access: Workload Identity Federation for repositories on GCS (and the AWS/Azure equivalents) issue #122 open andymccall opened this · 0 comments

andymccall

A repository kept in its owner's bucket needs a long-lived credential sealed on the hub: for GCS a service account key. Organisations commonly forbid those (GCP enables constraints/iam.disableServiceAccountKeyCreation by default for new organisations): setting up doomsdayone/tetris on gs://doomsdayone-oxy-repos (2026-10-10) needed a temporary per-project exception to that policy to create one key.

Wanted: the hub as an identity the customer's cloud trusts, with no key to leak or rotate.

  • GCS: Workload Identity Federation. The hub already issues OIDC tokens (spec §13.5, keys/oidc.pem, used by Flow jobs); the customer creates a workload identity pool and provider trusting the hub's issuer, with an attribute condition on the repository (sub such as repo:doomsdayone/tetris), and lets that principal impersonate the service account (roles/iam.workloadIdentityUser). The hub exchanges a short-lived token it signs for a federated token (STS), then for a service account access token, and refreshes it.
  • AWS: AssumeRoleWithWebIdentity against an IAM OIDC provider for the hub's issuer.
  • Azure: a federated identity credential on the app registration.
  • The New repository form and Settings > Storage offer 'keyless' with the provider details (pool/provider resource name and service account, role ARN, tenant and client id), show the issuer URL and subject to configure, and run the same pre-flight check.
  • The token's subject names the repository, so one repository's trust cannot be used for another's prefix.
  • Docs: a walkthrough per cloud, as docs/strata.md has for keys.