Problem/Motivation

GitLab's existing personal access tokens are far too coarse-grained, and enabling something like write_repository grants full write access to all repositories the contributor has access to.

This leads to situations like #3379836: Allow full access to Gitlab API (subject to user permission limits) and https://git.drupalcode.org/project/ai_best_practices/-/work_items/3588920 where legitimate security concerns are running smack into legitimate agentic workflow concerns, both of which are legitimate.

Proposed resolution

Earlier this month, GitLab announced a beta feature for fine-grained personal access tokens which make both of these audiences happy.

Remaining tasks

  1. Ask GitLab if we can join their beta program
  2. Turn it on
  3. Profit! ;)

User interface changes

API changes

Data model changes

Comments

webchick created an issue.

drumm’s picture

drumm
he/him
Location NY, US
commented

In general, there is no opting-in or asking GitLab for access to features. What they provide in the GitLab self-managed product for any given version is what they provide. There may be a feature flag for early enablement, but I didn’t see that documented for this feature. The advertised beta program appears to be for GitLab.com users, where new features are often available a couple weeks earlier.

We’re currently on GitLab v18.11.4-ee, and will remain on GitLab 18.* for a few more weeks. Before upgrading to GitLab 19, we need to take an outage to upgrade GitLab’s Postgres installation, which will be an our or two outage to schedule.

cmlara’s picture

cmlara
he/him
commented

I mentioned in #3379836: Allow full access to Gitlab API (subject to user permission limits) that it appears this might be feature flag: granular_personal_access_tokens, not tested it on a lab install to confirm however that was the flag named mentioned in the issue queue around it. A bit odd they didn't include it in the user guide since they called it out for GitLab.com and self run installs as of 18.10.