Skip to content

Draft: Add advanced token scopes proof of concept

Joern Schneeweisz requested to merge joern-advanced-token into master

What does this MR do and why?

This proof of concept implements Fine grained access controls of tokens (#368904), fine grained access controls for Personal Access Token to be used with our REST API. This MR is not intended to be merged it's rather here to discuss the approach and to find out what is missing for an actual addition to the product.

How does it work?

On the UI side it adds a textarea under /-/profile/personal_access_tokens for Advanced scopes:

image

For this proof of concept the Advanced scopes are implemented with two Gitlab::UntrustedRegexp per line, the regular expressions are separated by a space.

The first regular expression is the HTTP verb which is allowed for the operation on the API. So for instance

^GET$

will only allow GET operations which mean the rule will only allow to read values from the API by REST definition.

If we'd additionally like to create new entities we would have to also allow the POST method like so:

^GET$|^POST$

The second regular expression describes the allowed path for the operation:

^GET$|^POST$ ^/api/v4/projects/9/issues$
^GET$ ^/api/v4/projects/9/issues/\d*$

Will allow the token to read and created issues in the project with ID 9 but not allow to alter existing issues (this would be a PUT operation). The second line will allow reading specific issues by ID in the same project.

Things that are missing

  • UI for displaying the advanced scopes
  • Remove the need for a "regular" scope (it will be overridden by an advanced scope anyhow)
  • Documentation
  • Address scalability concerns by limiting the number of advanced scope entries
  • Either do additional validation of the regular expressions or switch to a more simple way to describe allowed pattern (e.g. wildcards)

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Joern Schneeweisz

Merge request reports