MergeRequestBypassSecurityPolicy does not support bot access tokens for authentication

Summary

The GraphQL mutation MergeRequestBypassSecurityPolicy does not support the same bypass authentication methods as git push operations, creating an inconsistent user experience. Users cannot use automation tokens (project access tokens, group access tokens) to bypass security policies via GraphQL, limiting CI/CD automation capabilities.

  • Git push operations support bypassing security policies via bypass_settings.access_tokens and bypass_settings.service_accounts
  • The GraphQL mutation only supports bypass_settings.users, bypass_settings.groups, and bypass_settings.roles
  • Users cannot use bot access tokens or service accounts to bypass policies via GraphQL, even though they can configure these in the policy

Reported in customer ticket:

Steps to reproduce

  1. Create a group and a project within it
  2. Create a Group Access Token for the group
  3. Create a MRAP at the group level, that targets the project
  4. Specify in the policy that the token is allowed to bypass (as below)
  5. Use the bots token in a curl call to the graphql endpoint with bypass mutation.
bypass_settings:
      access_tokens:
        - id: 5
GRAPHQL_QUERY='{"query":"mutation { mergeRequestBypassSecurityPolicy(input: { projectPath: \"'"${TARGET_PROJECT_PATH}"'\" iid: \"'"${MR_IID}"'\" reason: \"Automated bypass from pipeline '"${CI_PIPELINE_ID}"'\" securityPolicyIds: [\"'"${SECURITY_POLICY_ID}"'\"] }) { mergeRequest { iid title } errors } }"}'
      
      curl --silent --request POST --header "PRIVATE-TOKEN: ${BOT_TOKEN}" --header "Content-Type: application/json" --data "${GRAPHQL_QUERY}" "${GITLAB_GRAPHQL_URL}"

Example Project

What is the current bug behavior?

User configures bypass_settings.access_tokens in MRAP to allow a group access token to bypass the policy. Executing the graphql to bypass the violation returns:

"errors":["You are not allowed to bypass this security policy."]

User takes the same token and uses it with git push operation and is able to bypass the policy.

What is the expected correct behavior?

The mutation should be authorised according to the bypass_settings in the MRAP in the same way as git push operations.

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

Update BypassMergeRequestService to use PolicyBypassChecker logic instead of UserBypassChecker, or extend UserBypassChecker to support access token and service account bypass methods.

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖