Skip to content

GitLab Security Policy Bot can be blocked as a 'pending member' when user cap is enabled on a group

Summary

Since 16.3, "GitLab Security Policy Bots" are used to run scan execution policy activities on a project, ensuring this is kept separate to a standard user account.

It has been identified from this ticket, that on GitLab.com only, when a group owner enables a user cap and has reached the cap, these bot accounts are not added to a project automatically and become subject to manual approval in the UI. This creates concerns for customers because they might incorrectly assume that if these bots are added, they will use up a subscription user seat. From a security perspective, this could create a gap in enforcing execution policies, as the bot user cannot run on the project and run specific tasks without being accepted.

Steps to reproduce

This requires a GDK instance, as you need to simulate GitLab.com/SaaS:

  1. Create a GDK instance.
  2. Setup the GDK instance to simulate GitLab.com with: export GITLAB_SIMULATE_SAAS=1 in the env.runit file, and follow the steps to allow use of licensed EE features to be available to groups.
  3. Once the instance is operational, enable FF with: Feature.enable(:saas_user_caps) via GDK rails console. (This is enabled on GitLab.com).
  4. Create a new top-level group, and set a user-cap of 1. This will limit the max users to just the existing user that created the group.
  5. Within the Admin Area, set the new group to 'Ultimate'.
  6. Within the top-level group, create a new scan execution policy that attempts to run on a schedule, such as for Dependency Scanning every 15 minutes.
  7. Create a project beneath the top-level group.
  8. Go to the top-level group's Usage Quotas > Pending Members page (for example: http://localhost:3000/groups/<top-level-group>/-/usage_quotas/pending_members) and confirm that two GitLab Security Policy Bot users are present in the pending members list. Based on Project IDs in their usernames, these are for:
  • The Security policy project (tied to the group policy)
  • The project you created.

What is the current bug behavior?

GitLab Security Policy Bots should not need to be manually approved when a user cap is implemented, as they should not be using a seat.

What is the expected correct behavior?

GitLab Security Policy Bots should be added to a project without restriction.

Output of checks

This bug happens on GitLab.com

Possible fixes

When the member for the policy bot user is created, it's set to AWAITING state if there's not enough capacity because the method doesn't check whether the user is human?.

Even if the bot is approved by the group's owner, they are (correctly) not considered as billable users and they are not using a seat.

We could fix the required approval by adding an early return here similar to this method in Users::BuildService:

diff --git a/ee/app/models/ee/group.rb b/ee/app/models/ee/group.rb
index 76e33e2a7584..a580ba6fa48d 100644
--- a/ee/app/models/ee/group.rb
+++ b/ee/app/models/ee/group.rb
@@ -773,6 +773,7 @@ def has_free_or_no_subscription?
     override :capacity_left_for_user?
     def capacity_left_for_user?(user)
       return true unless user_cap_available?
+      return true unless user.human?
       return true if ::Member.in_hierarchy(root_ancestor).with_user(user).with_state(:active).exists?
 
       !user_cap_reached?
Edited by Martin Čavoj