Support GitLab fine-grained access token scopes instead of requiring full `api`

[RahulGautamSingh]

Discussed in #43874

^{Originally posted by yasp-pland June 8, 2026}
The GitLab platform module currently requires a token with the api scope:

https://docs.renovatebot.com/modules/platform/gitlab/
"You must use a Personal Access Token (or Project/Group access token), and configure it with the api scope."

api is GitLab's most permissive scope — it grants full read/write access to every API endpoint the user can reach (admin endpoints, group settings, package registry pushes, runner registration, etc.). For organizations with security policies that mandate least-privilege tokens, this is a non-starter, and forces teams to either:

• Provision a dedicated bot user with no access to anything else (extra cost on paid tiers), or
• Skip self-hosted Renovate entirely.

Since last year, GitLab will now switch to fine-grained Personal/Project Access Token permissions (https://about.gitlab.com/blog/fine-grained-job-tokens-ga/) covering individual resources.

Proposed change

1. Document the minimum set of fine-grained permissions needed to avoid experimentation
2. Enable less permissive scopes to avoid an attack vector

• Possibly make use of Gitlab's CI_JOB_TOKEN (update gitlab-bot-security documentation with focus on gitlab's ci_job_token's new abilities #34320)

References

• GitLab fine-grained access token scopes: https://docs.gitlab.com/auth/tokens/fine_grained_access_tokens/
• Similar issue for Github: Support github fine-grained token #18459