REST API endpoint for job token scope

Problem

Following release of the inbound CI_JOB_TOKEN setting users who automate creation of projects cannot also automate adding the projects allowed to use a CI_JOB_TOKEN with the project.

This is possible with the GraphQL endpoints

This is needed because some users prefer to use REST over graphql or use libraries to interact with the api that do not support graphql.

Proposal

Endpoint to implement	Description	Merge Request	Author
`GET projects/:id/job_token_scope`	Get settings `inbound_enabled` and `outbound_enabled` (no allowlists because it needs pagination)	!117842 (merged)	@gerardo-navarro
`GET projects/:id/job_token_scope/allowlist/:direction`	Get the allowlist of projects (where `direction` is `inbound/outbound`)	!118495 (merged)	@gerardo-navarro
`PATCH projects/:id/job_token_scope`	update params such as `inbound_scope_enabled` and `outbound_scope_enabled`	!118357 (merged)	@gerardo-navarro
`POST projects/:id/job_token_scope/allowlist/:direction?project_id=123`	add a project to the allowlist	!119675 (merged)	@gerardo-navarro
`DELETE projects/:id/job_token_scope/allowlist/:direction?project_id=123`	remove project from the allowlist This does not include the projects that are allowed to access the project though.	!119687 (merged)	@dbiryukov

For context, we decided to keep the setting toggle off of project since it should only be set by maintainers and to avoid making the project api responsible for too much. The discussion is here: #378339 (closed)

Permissions

This should only be shown to users with a Maintainer or higher role within the project to match existing permissions for CI/CD settings.

Implementation Guide

GET use ProjectCiCdSettings inbound_job_token_scope_enabled method or Project's inbound_job_token_scope_enabled` method
- Currently, the outbound setting is on project but I think it's ok to keep this inconsistency for now given that we are retiring that feature entirely.
PATCH use ProjectCiCdSettings update method or =inbound_job_token_scope_enabled as delegated through project.
GET use Ci::JobToken::Scope
DELETE use ::Ci::JobTokenScope::RemoveProjectService
POST use ::Ci::JobTokenScope::AddProjectService

targetProject refers to the project to add to the allowlist in the graphql api currently and not the project we are trying to access.

Old Writeup

Note 2023-02-23

This was re-written as a feature request as there was not an endpoint exposed for the token previously in the projects API.

Summary

Following the documentation for CI/CD Job Access Token Limits, https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#limit-gitlab-cicd-job-token-access I want to enable this setting for all my projects in a group. I have many subgroups and projects, and my goal is to automate this process now and later run the script in a scheduled cronjob to ensure the setting remains enabled for every project.

Steps to reproduce

Create a new project, note the project ID
Export GITLAB_TOKEN into the environment, needs at least maintainer permissions
Use the API to update the setting following this command

# https://gitlab.com/everyonecancontribute/dev/learn-wasm-assemblyscript.git = 37766828 

curl --request PUT --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
     --url 'https://gitlab.com/api/v4/projects/37766828' \
     --data "ci_job_token_scope_enabled=true"

Alternatively, test with a group, export GROUP_ID as environment variable, and download the script from this MR draft: dnsmichi/api-playground!12 (diffs) I wrote the script to update all projects within a group. Requires pip install python-gitlab before executing.

Example Project

What is the current bug behavior?

Updating the settings throws an error, saying that other attributes are missing in the PUT request.

{"error":"allow_merge_on_skipped_pipeline, analytics_access_level, autoclose_referenced_issues, auto_devops_enabled, auto_devops_deploy_strategy, auto_cancel_pending_pipelines, build_git_strategy, build_timeout, builds_access_level, ci_config_path, ci_default_git_depth, ci_allow_fork_pipelines_to_run_in_parent_project, ci_forward_deployment_enabled, ci_separated_caches, container_registry_access_level, container_expiration_policy_attributes, default_branch, description, emails_disabled, forking_access_level, issues_access_level, lfs_enabled, merge_pipelines_enabled, merge_requests_access_level, merge_requests_template, merge_trains_enabled, merge_method, name, only_allow_merge_if_all_discussions_are_resolved, only_allow_merge_if_pipeline_succeeds, operations_access_level, pages_access_level, path, printing_merge_request_link_enabled, public_builds, remove_source_branch_after_merge, repository_access_level, request_access_enabled, resolve_outdated_diff_discussions, restrict_user_defined_variables, security_and_compliance_access_level, squash_option, shared_runners_enabled, snippets_access_level, tag_list, topics, visibility, wiki_access_level, avatar, suggestion_commit_message, merge_commit_template, squash_commit_template, repository_storage, packages_enabled, service_desk_enabled, keep_latest_artifact, mr_default_target_self, enforce_auth_checks_on_uploads, issues_enabled, jobs_enabled, merge_requests_enabled, wiki_enabled, snippets_enabled, container_registry_enabled, approvals_before_merge, external_authorization_classification_label, fallback_approvals_required, import_url, issues_template, merge_requests_template, merge_pipelines_enabled, merge_trains_enabled, requirements_access_level are missing, at least one parameter must be provided"}%

What is the expected correct behavior?

Updating the project setting works, and I can automate the security settings for CI/CD Job Token Access Limits.

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

Expand for output related to GitLab environment info


(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)

Possible fixes

Either the field is hidden in the REST API, it is not expected as a PUT/POST body, or it does not exist yet.

</details.

Related issues:

Edited May 05, 2023 by Max Orefice