- Group push rules
- Restrict Git access protocols
- Restrict group access by IP address
- Restrict group access by domain
- Prevent group sharing outside the group hierarchy
- Prevent a project from being shared with groups
- Prevent users from requesting access to a group
- Prevent project forking outside group
- Prevent members from being added to projects in a group
- Manage group memberships via LDAP
- Troubleshooting
Group access and permissions
Configure your groups to control group permissions and access.
Group push rules
- Introduced in GitLab 12.8.
- Feature flag removed in GitLab 13.4.
- Moved to Settings/Repository in GitLab 15.4.
Group push rules allow group maintainers to set push rules for newly created projects in the specific group.
In GitLab 15.4 and later, to configure push rules for a group:
- On the left sidebar, select Settings > Repository.
- Expand the Pre-defined push rules section.
- Select the settings you want.
- Select Save Push Rules.
In GitLab 15.3 and earlier, to configure push rules for a group:
- On the left sidebar, select Push rules.
- Select the settings you want.
- Select Save Push Rules.
The group’s new subgroups have push rules set for them based on either:
- The closest parent group with push rules defined.
- Push rules set at the instance level, if no parent groups have push rules defined.
Restrict Git access protocols
- Introduced in GitLab 15.1.
- Feature flag removed in GitLab 16.0.
You can set the permitted protocols used to access a group’s repositories to either SSH, HTTPS, or both. This setting is disabled when the instance setting is configured by an administrator.
To change the permitted Git access protocols for a group:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Permissions and group features section.
- Choose the permitted protocols from Enabled Git access protocols.
- Select Save changes.
Restrict group access by IP address
- Introduced in GitLab 12.0.
- Moved from GitLab Ultimate to GitLab Premium in 13.1.
To ensure only people from your organization can access particular resources, you can restrict access to groups by IP address. This top-level group setting applies to:
- The GitLab UI, including subgroups, projects, and issues. It does not apply to GitLab Pages.
- In GitLab 12.3 and later, the API.
- In self-managed installations of GitLab 15.1 and later, you can also configure globally-allowed IP address ranges at the group level.
Administrators can combine restricted access by IP address with globally-allowed IP addresses.
To restrict group access by IP address:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Permissions and group features section.
- In the Restrict access by IP address text box, enter a list of IPv4 or IPv6
address ranges in CIDR notation. This list:
- Has no limit on the number of IP address ranges.
- Has a size limit of 1 GB.
- Applies to both SSH or HTTP authorized IP address ranges. You cannot split this list by type of authorization.
- Select Save changes.
Security implications
Keep in mind that restricting group access by IP address has the following implications:
- Administrators and group Owners can access group settings from any IP address, regardless of IP restriction. However:
- Group Owners can access the subgroups, but not the projects belonging to the group or subgroups, when accessing from a disallowed IP address.
- Administrators can access projects belonging to the group when accessing from a disallowed IP address. Access to projects includes cloning code from them.
- Users can still see group and project names and hierarchies. Only the following are restricted:
- Groups, including all group resources.
- Project, including all project resources.
- When you register a runner, it is not bound by the IP restrictions. When the runner requests a new job or an update to a job’s state, it is also not bound by the IP restrictions. But when the running CI/CD job sends Git requests from a restricted IP address, the IP restriction prevents code from being cloned.
- Users might still see some events from the IP-restricted groups and projects on their dashboard. Activity might include push, merge, issue, or comment events.
- IP access restrictions for Git operations via SSH are supported on GitLab SaaS.
IP access restrictions applied to self-managed instances are possible with
gitlab-sshd
with PROXY protocol enabled. - IP restriction is not applicable to shared resources belonging to a group. Any shared resource is accessible to a user even if that user is not able to access the group.
- While IP restrictions apply to public projects, they aren’t a complete firewall and cached files for a project may still be accessible to users not in the IP block
GitLab.com access restrictions
On GitLab.com shared runners are added to the global allowlist, so that they are available regardless of IP restrictions.
Artifact and Registry downloading from runners is sourced from any Google or, in the case of MacOS runners, Amazon IP address in that region. The download is therefore not added to the global allowlist. To allow runner downloading, add the outbound runner CIDR ranges to your group allowlist.
Restrict group access by domain
You can prevent users with email addresses in specific domains from being added to a group and its projects.
To restrict group access by domain:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Permissions and group features section.
- In the Restrict membership by email field, enter the domain names.
- Select Save changes.
Any time you attempt to add a new user, the user’s primary email is compared against this list. Only users with a primary email that matches any of the configured email domain restrictions can be added to the group.
The most popular public email domains cannot be restricted, such as:
-
aol.com
,gmail.com
,hotmail.co.uk
,hotmail.com
, -
hotmail.fr
,icloud.com
,live.com
,mail.com
, -
me.com
,msn.com
,outlook.com
, -
proton.me
,protonmail.com
,tutanota.com
, -
yahoo.com
,yandex.com
,zohomail.com
When you share a group, both the source and target namespaces must allow the domains of the members’ email addresses.
Prevent group sharing outside the group hierarchy
You can configure a top-level group so its subgroups and projects cannot invite other groups outside of the top-level group’s hierarchy. This option is only available for top-level groups.
For example, in the following group and project hierarchy:
- Animals > Dogs > Dog Project
- Animals > Cats
- Plants > Trees
If you prevent group sharing outside the hierarchy for the Animals group:
- Dogs can invite the group Cats.
- Dogs cannot invite the group Trees.
- Dog Project can invite the group Cats.
- Dog Project cannot invite the group Trees.
To prevent sharing outside of the group’s hierarchy:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand Permissions and group features.
- Select Members cannot invite groups outside of
<group_name>
and its subgroups. - Select Save changes.
Prevent a project from being shared with groups
Sharing a project with another group increases the number of users who can invite yet more members to the project. Each (sub)group can be an additional source of access permissions, which can be confusing and difficult to control.
To restrict the permission to invite project members to a single source, prevent a project from being shared with other groups:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Permissions and group features section.
- Select Projects in
<group_name>
cannot be shared with other groups. - Select Save changes.
This setting, when enabled, applies to all subgroups unless overridden by a group Owner. Groups already added to a project lose access when the setting is enabled.
Prevent users from requesting access to a group
As a group Owner, you can prevent non-members from requesting access to your group.
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Permissions and group features section.
- Clear the Allow users to request access checkbox.
- Select Save changes.
Prevent project forking outside group
Introduced in GitLab 13.3.
By default, projects in a group can be forked. Optionally, on GitLab Premium and Ultimate tiers, you can prevent the projects in a group from being forked outside of the current top-level group.
This setting is removed from the SAML setting page, and migrated to the
group settings page. In the interim period, both of these settings are taken into consideration.
If even one is set to true
, then the group does not allow outside forks.
To prevent projects from being forked outside the group:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Permissions and group features section.
- Check Prevent project forking outside current group.
- Select Save changes.
Existing forks are not removed.
Prevent members from being added to projects in a group
As a group Owner, you can prevent any new project membership for all projects in a group, allowing tighter control over project membership.
For example, if you want to lock the group for an Audit Event, you can guarantee that project membership cannot be modified during the audit.
If group membership lock is enabled, the group Owner can still:
- Invite groups or add members to groups to give them access to projects in the locked group.
- Change the role of group members.
The setting does not cascade. Projects in subgroups observe the subgroup configuration, ignoring the parent group.
To prevent members from being added to projects in a group:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Permissions and group features section.
- Under Membership, select Users cannot be added to projects in this group.
- Select Save changes.
After you lock the membership for a group:
- All users who previously had permissions can no longer add members to a group.
- API requests to add a new user to a project are not possible.
Manage group memberships via LDAP
Group syncing allows LDAP groups to be mapped to GitLab groups. This provides more control over per-group user management. To configure group syncing, edit the group_base
DN ('OU=Global Groups,OU=GitLab INT,DC=GitLab,DC=org'
). This OU contains all groups that are associated with GitLab groups.
Group links can be created by using either a CN or a filter. To create these group links, go to the group’s Settings > LDAP Synchronization page. After configuring the link, it may take more than an hour for the users to sync with the GitLab group.
For more information on the administration of LDAP and group sync, refer to the main LDAP documentation.
You can use a workaround to manage project access through LDAP groups.
Create group links via CN
To create group links via CN:
- Select the LDAP Server for the link.
- As the Sync method, select
LDAP Group cn
. - In the LDAP Group cn field, begin typing the CN of the group. There is a dropdown list with matching CNs in the configured
group_base
. Select your CN from this list. - In the LDAP Access section, select the permission level for users synced in this group.
- Select Add Synchronization.
Create group links via filter
To create group links via filter:
- Select the LDAP Server for the link.
- As the Sync method, select
LDAP user filter
. - Input your filter in the LDAP User filter box. Follow the documentation on user filters.
- In the LDAP Access section, select the permission level for users synced in this group.
- Select Add Synchronization.
Override user permissions
LDAP user permissions can be manually overridden by an administrator. To override a user’s permissions:
- On the left sidebar, select Search or go to and find your group.
- On the left sidebar, select Manage > Members. If LDAP synchronization
has granted a user a role with:
- More permissions than the parent group membership, that user is displayed as having direct membership of the group.
- The same or fewer permissions than the parent group membership, that user is displayed as having inherited membership of the group.
- Optional. If the user you want to edit is displayed as having inherited membership, filter the subgroup to show direct members before overriding LDAP user permissions.
- In the row for the user you are editing, select the pencil () icon.
- Select Edit permissions in the modal.
Now you can edit the user’s permissions from the Members page.
Troubleshooting
Verify if access is blocked by IP restriction
If a user sees a 404 when they would usually expect access, and the problem is limited to a specific group, search the auth.log
rails log for one or more of the following:
-
json.message
:'Attempting to access IP restricted group'
-
json.allowed
:false
In viewing the log entries, compare remote.ip
with the list of allowed IP addresses for the group.
Cannot update permissions for a group member
If a group Owner cannot update permissions for a group member, check which memberships are listed. Group Owners can only update direct memberships.
If a parent group membership has the same or higher role than a subgroup, the inherited membership is listed on the subgroup members page, even if a direct membership on the group exists.
To view and update direct memberships, filter the group to show direct members.
The need to filter members by type through a redesigned members page that lists both direct and inherited memberships is proposed in issue 337539.