Thanks for your reply and for opening an internal issue.
One of the example would be spawning a docker container to do some git operation on a repo and push the result back on a branch potentially after a build step. The cloning would happen via
git clone https://x-token-access:$token/org/repo, (some operations) and then push on a branch. As build step (for example Python) could execute arbitrary code I would prefer for this token to only have push access. (Well technically I would like to generate a token that can only push on a specific org/repo/branch but I’m not hoping that much).
While I, or my organisation would (ultimately) control all the code/deployment, I want to be able to put a task in a queue (with a token) and this token has (only) the permission the tasks needs.
The task code might not be written by me, but another team. If I can focus on only auditing the permission requests and the code that actually require crazy permissions the security aspect a tiny bit easier. Just a question of safety in case there is a breach or a bug.
Generally I need (rarely) write permission to a repository, I’d like most of the time to work on read-only manner.
Technically I could implement it myself, write a proxy that substitute the integration token for it’s own, keep a map of
newtoken => permissions and check on each requests that the
newtoken allows the given request, and if so put back the original token. That seem like an hassle to implement if it’s not too hard on your side.
I might just be paranoid with security.
Does that make some sens ?