<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=495554) </details> <!--IssueSummary end--> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> It should be possible to access the API in the context of running git hooks in a safe and convenient manner. ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> We need to be able to enforce certain restrictions when users are pushing, but only to protected branches, and not to e.g. the user's own feature branches. Hence, we want to be able to use the API from a git hook to get the names of protected branches for the project, currently handled by the git hook. Right now, one way of achieving this is to store a personal access token somewhere, e.g. on disk, or directly as a string in the git hook code, possibly with elevated privileges. But storing an access token statically like this is not ideal for a couple of reasons: - Files on disk may be read by others, deleted, corrupted, etc. - A personal access token for the purpose of git hooks, on e.g. the administrator user, doesn't allow us to take into consideration the privileges of the user triggering the git hook. - If tokens need to have an expiration date, then this means that the git hooks periodically require administration even if the hooks themselves don't need to be updated. ### Intended users [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator) [Isaac (Infrastructure Engineer)](https://handbook.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer) [Alex (Security Operations Engineer)](https://handbook.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) ### User experience goal It should be possible to access the API from a git hook context without having to generate and store access tokens for a specific user or role on disk or in the git hook code as a clear text string. A benefit of this is that the Intended users do not have to: - Periodically renew these access tokens. - Keep GitLab and the stored token in sync. - Consider the security risks of having tokens stored in a potentially unsafe manner. - Consider the potential security risks of accessing the API with different privileges than that of the user that triggered the git hook. ### Proposal To allow admins to configure temporary access tokens in the context git hooks, similar to how GitLab already has [CI/CD job tokens](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html), such that they exist when the git hook(s) run and expire directly afterward. ### Documentation * See [CI/CD job tokens documentation](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html). ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the Quality Engineering quad planning and test planning processes and reach out to your counterpart Software Engineer in Test for assistance. Quad Planning: https://handbook.gitlab.com/handbook/engineering/infrastructure/test-platform/quad-planning/ Test Planning: https://handbook.gitlab.com/handbook/engineering/infrastructure/test-platform/test-engineering/#test-planning -->