adjust read_registry access token scope: add api right to get registry informations
Problem to solve
Check inside a gitlab-ci build if a private repository / specific tag exist (without fetching it).
Or more general: Get private repository infos inside scripts.
Intended users
The users wo define gitlab-ci builds, or any other scripts handling with private repositories. e.g.
Further details
By the container registry api accessing registry/tags is possible.
e.g. curl "https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab-development-kit/registry/repositories?tags=1"
e.g. curl "https://gitlab.com/api/v4/groups//registry/repositories"
But this only work for public projects.
To do same with private projects/groups an authentication is needed.
e.g. curl --header "Private-Token: your_access_token
" "https://gitlab.com/api/v4/projects/ private group
%2Fprivate project
/registry/repositories".
The token used here need to have the api scope, otherwise insufficient_scope error returned:
{"error":"insufficient_scope","error_description":"The request requires higher privileges than provided by the access token.","scope":"api"}
Proposal
As read informations about existance of repositories / tags in the registry mostly fit to the read_registry scope, this right should be added there.
Using of api scoped access token is not practicable in ci context, as give far too much rights there, I claim.
An alternative would be make it possible define more detailed rights for api access.
Permissions and Security
That's the Problem here, reading information about the registry by api need to much permissions, as the read_registry scope is not enought.
As with authentication method gitlab-ci-job-token only some api actions are allowed, this / something similar should be done here also.
Better example (after analyse code) is the Files API here is also read access allowed with other scope.
Documentation
Adding new right info on scope overview
Add hint only read_registry scoped needed on container registry api page. Same view as on Files API.
A special hint on api authentication or personal-access-tokens seams not to be needed as they link to scope overview.
Testing
Potential risk here is messup with Permissions / access token concept?
additional tests:
- Verify the get container registry api calls work with the read_registry scope.
- Verify the delete registry API calls still NOT possible with read_registry scope.
- Verify the get registry API calls still possible with api scope.
- Verify other API calls still only possible with api scope (or as applicable befor).
- Verify all API calls still work if read_registry and api scope apply (or as applicable befor).
- Verify all still work as expected for public repositories / groups.
What does success look like, and how can we measure that?
acceptance criteria
An private access token with read_registry scope can use the get container registry api methods.
No other unexpected permision changes (as verified in Testing).
success metrics
The get calls as defined on dokumentation work with a only read_registry scoped private access token:
curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/registry/repositories"
curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/2/registry/repositories?tags=1"
curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/registry/repositories/2/tags"
curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/registry/repositories/2/tags/v10.0.0"
What is the type of buyer?
As this is "only" a general fix / adjustment of the permisson scope, this should apply to all,
so Core/Free tiers.
Links / references
container registry api
api authentication
potential related issue
/label feature