Control access and visibility (FREE SELF)

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

To access the visibility and access control options:

1. Sign in to GitLab as a user with Administrator access level.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.

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:

1. Sign in to GitLab as a user with Administrator access level.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.
5. For Default project creation protection, select the desired roles:
   • No one.
   • Maintainers.
   • Developers and Maintainers.
6. Select Save changes.

Restrict project deletion to administrators (PREMIUM SELF)

User interface changed in GitLab 15.1.

By default both administrators and anyone with the Owner role can delete a project. To restrict project deletion to only administrators:

1. Sign in to GitLab as a user with administrator access.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.
5. Scroll to:
   • (GitLab 15.1 and later) Allowed to delete projects, and select Administrators.
   • (GitLab 15.0 and earlier) Default project deletion projection and select Only admins can delete project.
6. Select Save changes.

Deletion protection (PREMIUM SELF)

• Introduced in GitLab 14.2 for groups created after August 12, 2021.
• 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.

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

Retention period

Changed in GitLab 15.1.

Groups and projects will remain restorable within a defined retention period. By default this is 7 days but it can be changed. Setting the retention period to 0 means that groups and project are removed immediately and cannot be restored.

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, then it will get automatically changed to 1 while also disabling deletion protection the next time any application setting is changed.

Delayed project deletion

User interface changed in GitLab 15.1.

Administrators can enable delayed project deletion by default for newly-created groups. Group owners can choose to disable this and existing groups will retain their existing setting. When enabled deleted groups will remain restorable within a retention period.

To configure delayed project deletion:

1. Sign in to GitLab as a user with administrator access.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.
5. Scroll to:
   • (GitLab 15.1 and later) Deletion projection and select keep deleted groups and projects, and select a retention period.
   • (GitLab 15.0 and earlier) Default delayed project projection and select Enable delayed project deletion by default for newly-created groups. Then set a retention period in Default deletion delay.
6. Select Save changes.

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

In GitLab 15.1, and later this setting is enforced on groups when disabled and it cannot be overridden.

Delayed group deletion

User interface introduced in GitLab 15.1.

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

In GitLab 15.1 and later, delayed group deletion can be enabled by setting Deletion projection to Keep deleted.

Override defaults and delete immediately

Alternatively, projects that are marked for removal can be deleted immediately. To do so:

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:

1. Sign in to GitLab as a user with Administrator access level.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.
5. 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 logged in user except external users.
   • Public - The project can be accessed without any authentication.
6. Select Save changes.

Configure snippet visibility defaults

To set the default visibility levels for new snippets:

1. Sign in to GitLab as a user with Administrator access level.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.
5. Select the desired default snippet visibility.
6. Select Save changes.

For more details on snippet visibility, read Project visibility.

Configure group visibility defaults

To set the default visibility levels for new groups:

1. Sign in to GitLab as a user with Administrator access level.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.
5. Select the desired default group visibility:
   • Private - The group and its projects can only be viewed by members.
   • Internal - The group and any internal projects can be viewed by any logged in user except external users.
   • Public - The group and any public projects can be viewed without any authentication.
6. Select Save changes.

For more details on group visibility, see Group visibility.

Restrict visibility levels

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

1. Sign in to GitLab as a user with Administrator access level.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.
5. In the Restricted visibility levels section, select the desired visibility levels to restrict. If you restrict the Public level:
   • User profiles are only visible to logged in users via the Web interface.
   • User attributes via the GraphQL API are:
     • Not visible in GitLab 15.1 and later.
     • Only visible to authenticated users between GitLab 13.1 and GitLab 15.0.
6. Select Save changes.

For more details on project visibility, see Project visibility.

Configure allowed import sources

You can specify from which hosting sites users can import their projects:

1. Sign in to GitLab as a user with Administrator access level.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.
5. Select each of Import sources to allow.
6. Select Save changes.

Enable project export

To enable the export of projects and their data:

1. Sign in to GitLab as a user with Administrator access level.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.
5. Select Project export enabled.
6. Select Save changes.

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:

1. Sign in to GitLab as a user with Administrator access level.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.
5. Select the desired Git access protocols:
   • Both SSH and HTTP(S)
   • Only SSH
   • Only HTTP(S)
6. Select Save changes.

When both SSH and HTTP(S) are enabled, users can choose either protocol. If only one protocol is enabled:

• 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 URL's protocol, 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 versions 10.7 and later, allow the HTTP(S) protocol for Git clone or fetch requests done by GitLab Runner from CI/CD jobs, even if you select Only SSH.

Customize Git clone URL for HTTP(S)

Introduced in GitLab 12.4.

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):

1. Enter a root URL for Custom Git clone URL for HTTP(S).
2. Select Save changes.

NOTE: SSH clone URLs can be customized in gitlab.rb by setting gitlab_rails['gitlab_ssh_host'] and other related settings.

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. Select the desired option from the dropdown.
2. Select Save changes.

For more details, see SSH key restrictions.

Enable project mirroring

This option is enabled by default. By disabling 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.

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.

This setting allows you to set IP address ranges to be combined with group-level IP allowlists. It helps administrators prevent aspects of the GitLab installation from being blocked from working as intended when an IP allowlist is used.

For example, if the GitLab Pages daemon runs on the 10.0.0.0/24 range, specify that range in this field, as otherwise any group-level restrictions that don't include that range cause the Pages daemon to be unable to fetch artifacts from the pipeline runs.

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

1. Sign in to GitLab as a user with Administrator access level.
2. On the top bar, select Main menu > Admin.
3. On the left sidebar, select Settings > General.
4. Expand the Visibility and access controls section.
5. In Globally-allowed IP ranges, provide a value.
6. Select Save changes.