What if instead of issuing GitHub tokens, OctoSTS could also act as a proxy?
Clients would never receive their GitHub token, they'd call https://octo-sts.dev/github-api/repos/octo-sts/app/contents/README.md using an OIDC token as credentials, and the octo-sts service would swap the tokens before making the request to https://api.github.com/repos/octo-sts/app/contents/README.md and returning the response.
To clients it would be a GitHub Enterprise Server endpoint. The octo-sts/setup-proxy-action might export the GH_HOST and GH_ENTERPRISE_TOKEN variables, so tools like the gh CLI prefer the custom endpoint.
It could generate an installation token for each API call, or use a cache and revoke upon eviction.
The goal is to allow trust policies to get even more restrictive: instead of granting an identity contents:write to the repository, the client could be artificially restricted to updating the ref that triggered an actions workflow, or restricted to accessing certain paths. In the future an actor could be prevented from using [ci-skip] in commit messages, or only allowed to create (not edit/close) issues that include generated by an LLM.
Between the v3/REST, the v4/GraphQL and various Git transports - I would not want to fund its bug bounty 😆 . Researchers will work around the additional restrictions, but the "fail open" behaviour is identical to today's model of giving the client the token.
It's an interesting thought. I'd be a bit wary of proxying that volume of (potentially sensitive) data though, which I suspect could become a meaningful amount of egress as well.
What if instead of issuing GitHub tokens, OctoSTS could also act as a proxy?
Clients would never receive their GitHub token, they'd call
https://octo-sts.dev/github-api/repos/octo-sts/app/contents/README.md
using an OIDC token as credentials, and the octo-sts service would swap the tokens before making the request tohttps://api.github.com/repos/octo-sts/app/contents/README.md
and returning the response.To clients it would be a GitHub Enterprise Server endpoint. The
octo-sts/setup-proxy-action
might export theGH_HOST
andGH_ENTERPRISE_TOKEN
variables, so tools like thegh
CLI prefer the custom endpoint.It could generate an installation token for each API call, or use a cache and revoke upon eviction.
The goal is to allow trust policies to get even more restrictive: instead of granting an identity
contents:write
to the repository, the client could be artificially restricted to updating theref
that triggered an actions workflow, or restricted to accessing certain paths. In the future an actor could be prevented from using[ci-skip]
in commit messages, or only allowed to create (not edit/close) issues that includegenerated by an LLM
.Between the v3/REST, the v4/GraphQL and various Git transports - I would not want to fund its bug bounty 😆 . Researchers will work around the additional restrictions, but the "fail open" behaviour is identical to today's model of giving the client the token.