External users
- Tier: Free, Premium, Ultimate
- Offering: GitLab Self-Managed
In cases where it is desired that a user has access only to some internal or private projects, there is the option of creating External Users. This feature may be useful when for example a contractor is working on a given project and should only have access to that project.
External users:
- Cannot create project, groups, and snippets in their personal namespaces.
- Can only create projects (including forks), subgroups, and snippets within top-level groups to which they are explicitly granted access.
- Can access public groups and public projects.
- Can only access projects and groups to which they are explicitly granted access. External users cannot access internal or private projects or groups that they are not granted access to.
- Can only access public snippets.
Access can be granted by adding the user as member to the project or group. Like usual users, they receive a role for the project or group with all the abilities that are mentioned in the permissions table. For example, if an external user is added as Guest, and your project is internal or private, they do not have access to the code; you need to grant the external user access at the Reporter level or above if you want them to have access to the code. You should always take into account the project’s visibility and permissions settings as well as the permission level of the user.
External users still count towards a license seat, unless the user has the Guest role in the Ultimate tier.
An administrator can flag a user as external by either of the following methods:
- Through the API.
- Using the GitLab UI:
- On the left sidebar, at the bottom, select Admin.
- On the left sidebar, select Overview > Users to create a new user or edit an existing one. There, you can find the option to flag the user as external.
Additionally, users can be set as external users using:
Set a new user to external
By default, new users are not set as external users. This behavior can be changed by an administrator:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand the Account and limit section.
If you change the default behavior of creating new users as external, you have the option to narrow it down by defining a set of internal users. The Internal users field allows specifying an email address regex pattern to identify default internal users. New users whose email address matches the regex pattern are set to internal by default rather than an external collaborator.
The regex pattern format is in Ruby, but it needs to be convertible to JavaScript,
and the ignore case flag is set (/regex pattern/i
). Here are some examples:
- Use
\.internal@domain\.com$
to mark email addresses ending with.internal@domain.com
as internal. - Use
^(?:(?!\.ext@domain\.com).)*$\r?
to mark users with email addresses not including.ext@domain.com
as internal.
WARNING: Be aware that this regex could lead to a regular expression denial of service (ReDoS) attack.
Docs
Edit this page to fix an error or add an improvement in a merge request.
Create an issue to suggest an improvement to this page.
Product
Create an issue if there's something you don't like about this feature.
Propose functionality by submitting a feature request.
Feature availability and product trials
View pricing to see all GitLab tiers and features, or to upgrade.
Try GitLab for free with access to all features for 30 days.
Get help
If you didn't find what you were looking for, search the docs.
If you want help with something specific and could use community support, post on the GitLab forum.
For problems setting up or using this feature (depending on your GitLab subscription).
Request support