Allow service accounts to be primary owner of a top level groups

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Proposal

Customers have the desire to manage the infrastructure pipelines at the top level and keep to the principle of less privilege and separation of duties

Current functionality in 18.2 for service bots is as follows.

  • They can be added to a top-level group by an Owner
  • Primary use is for automation
  • Can be set to roles such as owner, dev etc
  • Service bots can create Groups and projects via the API
  • The intention is to work as a "normal" user but be unaffected by role changes in the company. This is reinforced by the documentation

You authenticate as a service account with a personal access token. Service accounts have the same abilities as human users, and can perform actions like interacting with package and container registries, performing Git operations, and accessing the API.

Historically, our customers have used service bots for automation tasks. Using a service bot is a clear indication of which pipelines run infrastructure tasks.

In previous versions of Gitlab and even on 17.11, we could allow service accounts to be the sole member of a group. Meaning, if you created a group, you could leave the service account bot user as the sole user. This is not available in 18.2

18.2

BBDC18A8-4059-4221-893B-2BD08623AFC5

17.11

8B929CC1-E341-4EFD-B944-2717ACAA25D1

After 17.11, we added something to the code base to prevent leaving a group if you are the only user, even if a service account is present. If you try to leave the group you receive the Groups require a human Owner message.

Customers would like the functionality of having a top-level group owned by a service bot user. This would provide the extra security of not providing access to lower-level users. Or having to use a dummy user account, which leads to confusion.

The proposal is to allow service accounts or at least instance-level service accounts to be the owner of top-level groups.

Below is the curl example I used to add groups via that api.

curl --request POST --header "PRIVATE-TOKEN: glpat-<LETTERS AND NUMBERS> \
     --header "Content-Type: application/json" \
     --data '{"path": "amazon_testing", "name": "Servicebotcreated", "parent_id": 9  }' \
     "https://sr-env-0551f149-omnibus.env-0551f149.gcp.gitlabsandbox.net/api/v4/groups/"
{"id":12,"web_url":"https://sr-env-0551f149-omnibus.env-0551f149.gcp.gitlabsandbox.net/groups/amazon_testing/amazon_testing","name":"Servicebotcreated","path":"amazon_testing","description":"","visibility":"private","share_with_group_lock":false,"require_two_factor_authentication":false,"two_factor_grace_period":48,"project_creation_level":"developer","auto_devops_enabled":null,"subgroup_creation_level":"maintainer","emails_disabled":false,"emails_enabled":true,"mentions_disabled":null,"lfs_enabled":true,"archived":false,"math_rendering_limits_enabled":true,"lock_math_rendering_limits_enabled":false,"default_branch":null,"default_branch_protection":2,"default_branch_protection_defaults":{"allowed_to_push":[{"access_level":40}],"allow_force_push":false,"allowed_to_merge":[{"access_level":40}],"developer_can_initial_push":false},"avatar_url":null,"request_access_enabled":true,"full_name":"Amazon_testing / Servicebotcreated","full_path":"amazon_testing/amazon_testing","created_at":"2025-08-08T16:14:03.256Z","parent_id":9,"organization_id":1,"shared_runners_setting":"enabled","max_artifacts_size":null,"marked_for_deletion_on":null,"ldap_cn":null,"ldap_access":null,"wiki_access_level":"enabled","duo_core_features_enabled":null,"duo_features_enabled":true,"lock_duo_features_enabled":false,"shared_with_groups":[],"shared_runners_minutes_limit":null,"extra_shared_runners_minutes_limit":null,"prevent_forking_outside_group":false,"membership_lock":false,"ip_restriction_ranges":null,"allowed_email_domains_list":null}

Ideally, we would want instance-level service accounts to function as close to normal users as possible, with all the benefits of being a service account. We want to use a Service Account to run automation, but their implementation is currently unpredictable and frustrating.

Service accounts should be able to :

  • Create a group or project via the API
  • be the sole owner of that group or project
Edited by 🤖 GitLab Bot 🤖