Allow CI_JOB_TOKEN to access the new discussion thread API endpoint
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Proposal
The CI_JOB_TOKEN has very limited access to the API in the project while CI jobs are running. I believe that this should be extended to include creating new discussion threads under controlled circumstances.
In the current implementation, CI jobs have only two very basic mechanisms for providing feedback to the user about tests: the pass/fail state and the job's log output. The pass/fail state provides almost no information and the log output often provides far too much. I think it would make sense to allow CI jobs to access the discussion thread API so that job writers can give custom feedback (that also shows up in email notifications).
Security Considerations
Giving the job token greater access carries risk, as a malicious merge request might seek to extract the token and use it for nefarious purposes. Giving it the right to start new discussion threads runs the risk of spam-bots abusing this.
My proposal to counter this risk is to grant the discussion creation access if-and-only-if the CI yaml definition is not read from the current project. In other words, the "CI/CD configuration file" field in the "General Pipelines" section of the CI/CD settings must be pointing at a YAML document external to the current project (such as another project on Gitlab or a URL).
This virtually eliminates the spam risk, as there are now only two ways to gain access to the token:
- The user has access to modify the test configuration on the remote machine, in which case they already have enough privilege to execute arbitrary code in the test runners, including extracting the token.
- The user has access to modify the "CI/CD configuration file" option on this repository, in which case they already have enough privilege to execute arbitrary code in the test runners, including extracting the token.
By requiring that the configuration points to a different location, we eliminate the risk of extracting and using the job token as part of a merge request, since the MR won't be able to modify the CI config the way it could if the default .gitlab-ci.yml was in use.