ContextQMD
Back to Gitlabhq

Control access and visibility

doc/administration/settings/visibility_and_access_controls.md

18.11.214.4 KB
Original Source

{{< details >}}

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

Administrators of GitLab instances can enforce specific controls on branches, projects, snippets, groups, and more. For example, you can define:

  • Which roles can create or delete projects.
  • Retention periods for deleted projects and groups.
  • Visibility of groups, projects, and snippets.
  • Allowed types and lengths for SSH keys.
  • Git settings, such as accepted protocols (SSH or HTTPS) and clone URLs.
  • Allow or prevent push mirroring and pull mirroring.

Prerequisites:

  • You must be an administrator.

To access the visibility and access control options:

  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand Visibility and access controls.

Define which roles can create projects

You can add project creation protections to your instance. These protections define which roles can add projects to a group on the instance.

When you configure the Default minimum role required to create projects setting, you set the default for new groups. Existing groups retain their current permissions.

Prerequisites:

  • You must be an administrator.
  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand Visibility and access controls.
  4. For Default minimum role required to create projects, select the desired role:
    • No one.
    • Administrators.
    • Owners.
    • Maintainers.
    • Developers.
  5. Select Save changes.

[!note] If you select Administrators and Admin Mode is enabled, administrators must enter Admin Mode to create new projects.

Restrict project deletion to administrators

{{< details >}}

  • Tier: Premium, Ultimate
  • Offering: GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

Prerequisites:

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

To restrict project deletion to only administrators:

  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand Visibility and access controls.
  4. Scroll to Allowed to delete projects, and select Administrators.
  5. Select Save changes.

To disable the restriction:

  1. Select Owners and administrators.
  2. Select Save changes.

Deletion protection

{{< history >}}

  • Generally available in GitLab 16.0. Premium and Ultimate only.
  • Moved from GitLab Premium to GitLab Free in GitLab 18.0.

{{< /history >}}

Deletion protection prevents accidental deletion of groups and projects on your instance.

Retention period

Groups and projects remain restorable during the retention period you define. By default, the retention period is 30 days, but you can change it to a value between 1 and 90 days.

Prerequisites:

  • You must have administrator access.

To configure deletion protection for groups and projects:

  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand Visibility and access controls.
  4. Scroll to Retention period and set the retention period to a value between 1 and 90 days.
  5. Select Save changes.

Override defaults and delete permanently

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

  1. Restore the project.
  2. Delete the project as described in administering projects.

Configure project visibility defaults

To set the default visibility levels for new projects:

Prerequisites:

  • You must be an administrator.
  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand Visibility and access controls.
  4. Select the desired default project visibility:
    • Private - Grant project access explicitly to each user. If this project is part of a group, grants access to members of the group.
    • Internal - Any authenticated user, except external users, can access the project.
    • Public - Any user can access the project without any authentication.
  5. Select Save changes.

Configure snippet visibility defaults

To set the default visibility levels for new snippets:

Prerequisites:

  • You must be an administrator.
  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand Visibility and access controls.
  4. For Default snippet visibility, select your desired visibility level:
    • Private.
    • Internal. This setting is disabled for new projects, groups, and snippets on GitLab.com. Existing snippets using the Internal visibility setting keep this setting. To learn more about this change, see issue 12388.
    • Public.
  5. Select Save changes.

Configure group visibility defaults

To set the default visibility levels for new groups:

Prerequisites:

  • You must be an administrator.
  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand Visibility and access controls.
  4. For Default group visibility, select your desired visibility level:
    • 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

{{< history >}}

  • 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.

{{< /history >}}

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.

This setting does not apply to projects created under a personal namespace. There is a feature request to extend this functionality to enterprise users.

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

Prerequisites:

  • You must be an administrator.
  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand Visibility and access controls.
  4. For Restricted visibility levels, 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 are not visible through the GraphQL API.
    • 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 restrict a visibility level that is set as the default for new projects or groups. Conversely, you cannot set a restricted visibility level as the default for new projects or 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.

GitLab allows Git actions only for the protocols you select:

  • If you enable both SSH and HTTP(S), users can choose either protocol.
  • If you enable only one protocol, project pages show only the allowed protocol's URL, with no option to change it.

To specify the enabled Git access protocols for all projects on your instance:

Prerequisites:

  • You must be an administrator.
  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand Visibility and access controls.
  4. For Enabled Git access protocols, select your desired protocols:
    • Both SSH and HTTP(S).
    • Only SSH.
    • Only HTTP(S).
  5. Select Save changes.

[!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)

{{< details >}}

  • Offering: GitLab Self-Managed

{{< /details >}}

You can customize project Git clone URLs for HTTP(S), which affects the clone panel shown to users on a project's page. 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 a new value from the GitLab UI:

Prerequisites:

  • You must be an administrator.
  1. In the upper-right corner, select Admin.
  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. In the upper-right corner, select Admin.
  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.

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 per project:

Prerequisites:

  • You must be an administrator.
  1. In the upper-right corner, select Admin.
  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

Administrators can combine IP address ranges with IP restrictions per group. Globally-allowed IP addresses enable aspects of the GitLab installation to work properly, even when groups set their own IP address restrictions.

For example, if the GitLab Pages daemon runs on the 10.0.0.0/24 range, globally allow that range. GitLab Pages can still fetch artifacts from pipelines, even if IP address restrictions for the group don't include the 10.0.0.0/24 range.

To add a IP address range to the allowlist for a group:

Prerequisites:

  • You must be an administrator.
  1. In the upper-right corner, select Admin.
  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.
    • Applies to both SSH or HTTP authorized IP address ranges. You cannot split this list by authorization type.
  5. Select Save changes.

Prevent invitations to groups and projects

{{< history >}}

{{< /history >}}

Administrators can prevent non-administrators from inviting users to all groups or projects on the instance. When you configure this setting, only administrators can invite users to groups or projects on the instance.

[!note] Features such as sharing or migrations can still allow access to these groups and projects.

Prerequisites:

  • You must be an administrator.

To prevent invitations:

  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand Visibility and access controls.
  4. Select the Prevent group member invitations checkbox.
  5. Select Save changes.

Display GitLab Credits user data

{{< details >}}

  • Tier: Premium, Ultimate
  • Offering: GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

{{< history >}}

{{< /history >}}

Prerequisites:

  • You must be an administrator.

To turn on the display of user data on the GitLab Credits dashboard:

  1. In the upper-right corner, select Admin.
  2. Select Settings > General.
  3. Expand Visibility and access controls.
  4. For the GitLab Credits dashboard, select the Display user data checkbox.
  5. Select Save changes.