Control access and visibility

DETAILS: Tier: Free, Premium, Ultimate Offering: Self-managed

GitLab enables users with administrator access to enforce specific controls on branches, projects, snippets, groups, and more.

Prerequisites:

• You must be an administrator.

To access the visibility and access control options:

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.

Define which roles can create projects

Instance-level protections for project creation define which roles can add projects to a group on the instance. To alter which roles have permission to create projects:

Prerequisites:

• You must be an administrator.

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.
4. For Default project creation protection, select the desired roles:
   • No one.
   • Maintainers.
   • Developers and Maintainers.
5. Select Save changes.

Restrict project deletion to administrators

DETAILS: Tier: Premium, Ultimate Offering: Self-managed

• User interface changed in GitLab 15.1.

Prerequisites:

• You must be an administrator, or have the Owner role in a project.

To restrict project deletion to only administrators:

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.
4. Scroll to:
   • (GitLab 15.1 and later) Allowed to delete projects, and select Administrators.
   • (GitLab 15.0 and earlier) Default project deletion protection and select Only admins can delete project.
5. Select Save changes.

Deletion protection

DETAILS: Tier: Premium, Ultimate Offering: Self-managed

• Renamed from default delayed project deletion in GitLab 15.1.
• Enabled for projects in personal namespaces in GitLab 15.1.
• Disabled for projects in personal namespaces in GitLab 15.3.
• Removed option to delete immediately in GitLab 15.11 with a flag named always_perform_delayed_deletion. Disabled by default.
• Enabled delayed deletion by default and removed the option to delete immediately on GitLab.com and on self-managed in GitLab 16.0.

Instance-level protection against accidental deletion of groups and projects.

Retention period

• Changed in GitLab 15.1.

Groups and projects remain restorable during the retention period you define. By default, this is 7 days, but you can change it. If you set the retention period to 0, GitLab removes deleted groups and projects immediately. You can't restore them.

In GitLab 15.1 and later, the retention period must be between 1 and 90. If the retention period was 0 before the 15.1 update, the next time you change any application setting, GitLab:

• Changes the retention period to 1.
• Disables deletion protection.

Delayed project deletion

• User interface changed in GitLab 15.1.
• Enabled delayed deletion by default and removed the option to delete immediately on GitLab.com and on self-managed in GitLab 16.0.

Prerequisites:

• You must be an administrator.

To configure delayed project deletion:

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.
4. Scroll to:
   • In GitLab 16.0 and later: Deletion protection and set the retention period to a value between 1 and 90.
   • In GitLab 15.11 with always_perform_delayed_deletion feature flag enabled: Deletion protection and set the retention period to a value between 1 and 90.
   • In GitLab 15.1 to 15.10: Deletion protection and select Keep deleted groups and projects, then set the retention period.
   • In GitLab 15.0 and earlier: Default delayed project protection and select Enable delayed project deletion by default for newly-created groups, then set the retention period.
5. Select Save changes.

Deletion protection is not available for projects only (without being also being enabled for groups).

GitLab 15.1 and later enforces this setting on groups when disabled. You can't override this setting.

Delayed group deletion

• User interface introduced in GitLab 15.1.
• Changed to default behavior on the Premium and Ultimate tier in GitLab 16.0.

Groups remain restorable if the retention period is 1 or more days.

In GitLab 15.1 and later, enable delayed group deletion by setting Deletion projection to Keep deleted. In GitLab 15.11 and later with the always_perform_delayed_deletion feature flag enabled, or in GitLab 16.0 and later:

• The Keep deleted option is removed.
• Delayed group deletion is the default.

Override defaults and delete immediately

To override the delay, and immediately delete a project marked for removal:

1. Restore the project.
2. Delete the project as described in the Administering Projects page.

Configure project visibility defaults

To set the default visibility levels for new projects:

Prerequisites:

• You must be an administrator.

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.
4. Select the desired default project visibility:
   • Private - Project access must be granted explicitly to each user. If this project is part of a group, access is granted to members of the group.
   • Internal - The project can be accessed by any authenticated user except external users.
   • Public - The project can be accessed without any authentication.
5. Select Save changes.

For more details on project visibility, see Project visibility.

Configure snippet visibility defaults

To set the default visibility levels for new snippets:

Prerequisites:

• You must be an administrator.

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.
4. Select the desired default snippet visibility.
5. Select Save changes.

For more details on snippet visibility, read Snippet visibility.

Configure group visibility defaults

To set the default visibility levels for new groups:

Prerequisites:

• You must be an administrator.

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.
4. Select the desired default group visibility:
   • Private - Only members can view the group and its projects.
   • Internal - Any authenticated user (except external users) can view the group and any internal projects.
   • Public - Authentication is not required to view the group and any public projects.
5. Select Save changes.

For more details on group visibility, see Group visibility.

Restrict visibility levels

• Changed in GitLab 16.3 to prevent restricting default project and group visibility, with a flag named prevent_visibility_restriction. Disabled by default.
• prevent_visibility_restriction enabled by default in GitLab 16.4.
• prevent_visibility_restriction removed in GitLab 16.7.

When restricting visibility levels, consider how these restrictions interact with permissions for subgroups and projects that inherit their visibility from the item you're changing.

To restrict visibility levels for groups, projects, snippets, and selected pages:

Prerequisites:

• You must be an administrator.

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.
4. In the Restricted visibility levels section, select the desired visibility levels to restrict.
   • If you restrict the Public level:
     • Only administrators can create public groups, projects, and snippets.
     • User profiles are visible to only authenticated users through the Web interface.
     • User attributes through the GraphQL API are:
       • Not visible in GitLab 15.1 and later.
       • Visible only to authenticated users in GitLab 15.0.
   • If you restrict the Internal level:
     • Only administrators can create internal groups, projects, and snippets.
   • If you restrict the Private level:
     • Only administrators can create private groups, projects, and snippets.
5. Select Save changes.

NOTE: You cannot select the restricted default visibility level for new projects and groups.

Configure enabled Git access protocols

With GitLab access restrictions, you can select the protocols users can use to communicate with GitLab. Disabling an access protocol does not block port access to the server itself. The ports used for the protocol, SSH or HTTP(S), are still accessible. The GitLab restrictions apply at the application level.

To specify the enabled Git access protocols:

Prerequisites:

• You must be an administrator.

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.
4. Select the desired Git access protocols:
   • Both SSH and HTTP(S)
   • Only SSH
   • Only HTTP(S)
5. Select Save changes.

If you enable both SSH and HTTP(S), users can choose either protocol. If you enable only one protocol:

• The project page shows only the allowed protocol's URL, with no option to change it.

• GitLab shows a tooltip when you hover over the protocol for the URL, if user action (such as adding a SSH key or setting a password) is required:

  

GitLab only allows Git actions for the protocols you select.

WARNING: GitLab allows the HTTP(S) protocol for Git clone or fetch requests performed with GitLab CI/CD job tokens. This happens even if you select Only SSH, because GitLab Runner and CI/CD jobs require this setting.

Customize Git clone URL for HTTP(S)

You can customize project Git clone URLs for HTTP(S), which affects the clone panel. For example, if:

• Your GitLab instance is at https://example.com, then project clone URLs are like https://example.com/foo/bar.git.
• You want clone URLs that look like https://git.example.com/gitlab/foo/bar.git instead, you can set this setting to https://git.example.com/gitlab/.

To specify a custom Git clone URL for HTTP(S) in gitlab.rb, set a new value for gitlab_rails['gitlab_ssh_host']. To specify it from the GitLab UI:

Prerequisites:

• You must be an administrator.

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.
4. Enter a root URL for Custom Git clone URL for HTTP(S).
5. Select Save changes.

Configure defaults for RSA, DSA, ECDSA, ED25519, ECDSA_SK, ED25519_SK SSH keys

These options specify the permitted types and lengths for SSH keys.

To specify a restriction for each key type:

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.
4. Go to RSA SSH keys.
5. For each key type, you can allow or prevent their use entirely, or allow only lengths of:
   • At least 1024 bits.
   • At least 2048 bits.
   • At least 3072 bits.
   • At least 4096 bits.
   • At least 1024 bits.
6. Select Save changes.

For more details, see SSH key restrictions.

Enable project mirroring

GitLab enables project mirroring by default. If you disable it, both pull mirroring and push mirroring no longer work in every repository. They can only be re-enabled by an administrator user on a per-project basis.

To allow project maintainers on your instance to configure mirroring at the project level:

Prerequisites:

• You must be an administrator.

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > Repository.
3. Expand Repository mirroring.
4. Select Allow project maintainers to configure repository mirroring.
5. Select Save changes.

Configure globally-allowed IP address ranges

• Introduced in GitLab 15.1 with a flag named group_ip_restrictions_allow_global. Disabled by default.
• Generally available in GitLab 15.4. Feature flag group_ip_restrictions_allow_global removed.

Administrators can combine IP address ranges with group-level IP restrictions. Use globally-allowed IP addresses to allow aspects of the GitLab installation to work even when group-level IP address restrictions are set.

For example, if the GitLab Pages daemon runs on the 10.0.0.0/24 range, you can specify that range as globally-allowed. This means GitLab Pages can still fetch artifacts from pipelines even if group-level IP address restrictions don't include the 10.0.0.0/24 range.

To add a IP address range to the group-level allowlist:

Prerequisites:

• You must be an administrator.

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > General.
3. Expand Visibility and access controls.
4. In Globally-allowed IP ranges, provide a list of IP address ranges. 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 authorization type.
5. Select Save changes.