Permissions
- Instance-wide user permissions
- Project features permissions
- Group members permissions
- External users
- Free Guest users
- Project features
- Running pipelines on protected branches
- Project aliases
Permissions
用户具有不同的能力,具体取决于他们在特定组或项目中具有的访问级别. 如果用户既属于项目组又属于项目本身,则使用最高权限级别.
在公共和内部项目上,不执行来宾角色. 所有用户将能够:
- 创造问题.
- 留言.
- 克隆或下载项目代码.
当成员离开团队的项目时,所有分配的” 问题”和” 将自动取消分配.
GitLab 管理员拥有所有权限.
要添加或导入用户,可以遵循 .
有关权限的信息,请参见我们的 .
Instance-wide user permissions
默认情况下,用户可以创建顶级组并更改其用户名. GitLab 管理员可以配置 GitLab 实例来 .
Project members permissions
注意:在 GitLab 11.0 中,”主”角色已重命名为”维护者”.
虽然维护者是项目级别的最高角色,但是某些操作只能由拥有所有权限的个人名称空间或组所有者或实例管理员执行. 有关更多信息,请参阅 .
下表描述了项目中的各种用户权限级别.
*所有者权限仅在组或个人名称空间级别(例如,管理员)可用,并由其项目继承.
- 来宾用户能够对公共和内部项目执行此操作,但不能对私有项目执行此操作.
- 来宾用户只能查看他们自己创建的机密问题.
- 如果在项目设置> CI / CD 中启用了公共管道 .
- 不允许访客,记者,开发人员,维护人员或所有者使用. 请参阅受保护的分支 .
- 如果 ,则取决于授予开发人员和维护人员的权限.
- 来宾用户可以访问 GitLab 版本来下载资产,但不能下载源代码,也不能查看存储库信息(例如标签和提交).
- 操作仅限于用户拥有(引用)的记录.
- 有关合并请求的信息,请参阅合格合并 .
Project features permissions
可以根据用户在项目设置上选择的可见性级别对用户隐藏 Wiki 和问题等项目功能.
- 禁用:所有人禁用
- 仅团队成员:即使您的项目是公开的或内部的,也只有团队成员才能看到
- 有访问权限的所有人:每个人都可以看到,具体取决于您的项目可见性级别
- 每个人:为所有人启用(仅适用于 GitLab 页面)
Protected branches
可以在每个分支的受保护分支上应用其他限制. 此外,您可以自定义权限,以允许或阻止项目维护者和开发者推送到受保护的分支. 阅读有关” 的文档以了解更多信息.
Value Stream Analytics permissions
如所述,在 Value Stream Analytics 仪表板上找到当前权限.
具有较高权限级别的开发人员和用户可以使用发行版的所有功能,即创建/删除列表并拖动发行版. 通读有关发行板权限的以了解更多信息.
File Locking permissions
锁定文件或目录的用户是唯一可以编辑并将其更改推回锁定对象所在存储库的用户.
Confidential Issues permissions
报告者和更高的权限级别以及创建机密问题的来宾用户都可以访问机密问题. 要了解更多信息,请通读有关权限和访问机密问题的文档.
注意:在 GitLab 11.0 中,”主”角色已重命名为”维护者”.
任何用户都可以将自己从组中删除,除非他们是该组的最后一个所有者. 下表描述了组中的各种用户权限级别.
- 可以设置组以
- 在 GitLab 12.2 中引入.
- 可以在以下位置更改默认项目创建角色:
- 实例级别 .
- .
- 不适用于子组.
将成员添加到子组时,它们将从父组继承成员资格和权限级别. 如果您是其父级成员之一,则该模型允许访问嵌套组.
To learn more, read through the documentation on subgroups memberships.
External users
如果希望用户只能访问某些内部或私有项目,则可以选择创建外部用户 . 例如,当承包商在给定项目上工作且仅应访问该项目时,此功能可能很有用.
外部用户:
- 无法创建群组,项目或个人摘要.
- 只能访问公共项目和显式授予其访问权限的项目,从而对它们隐藏所有其他内部或私有项目(例如注销).
可以通过将用户添加为项目或组的成员来授予访问权限. 与普通用户一样,他们将在项目或组中获得角色,具有上面权限表中提到的所有功能. 例如,如果将外部用户添加为 Guest,而您的项目是私有项目,则他们将无权访问该代码; 如果您希望外部用户具有访问代码的权限,则需要授予其外部访问权限. 您应始终考虑以及用户的权限级别.
注意:外部用户仍然计入许可证席位.
管理员可以通过以下两种方法之一将用户标记为外部用户:
- Either through the API.
- 或通过导航到管理区域>概述>用户来创建新用户或编辑现有用户. 在那里,您将找到将用户标记为外部的选项.
Setting new users to external
默认情况下,新用户未设置为外部用户. 管理员可以在” 帐户和限制”下的” 管理区域”>”设置”>”常规”页面上更改此行为.
如果更改了将新用户创建为外部用户的默认行为,则可以选择通过定义一组内部用户来缩小范围. 内部用户字段允许指定电子邮件地址正则表达式模式以标识默认内部用户. 默认情况下,其电子邮件地址与正则表达式模式匹配的新用户将设置为内部用户,而不是外部协作者.
正则表达式模式格式为 Ruby,但需要将其转换为 JavaScript,并将设置大小写忽略标志( ). 这里有些例子:
- 使用
\.internal@domain\.com$
将以结尾的电子邮件地址标记为内部. - 使用
^(?:(?!\.ext@domain\.com).)*$\r?
使用不包含电子邮件地址标记用户为内部用户.
警告:请注意,此正则表达式可能导致正则表达式拒绝服务(ReDoS)攻击 .
Free Guest users
如果为用户授予了项目,组或组或两者的来宾权限,并且对 GitLab 实例上的任何其他项目或组均没有更高的权限级别,则该用户被 GitLab 视为来宾用户,并且不会占用许可证席位. 对于新创建的用户,没有其他特定的”来宾”指定.
如果在任何项目或组上为用户分配了更高的角色,则该用户将获得许可席位. 如果用户创建项目,则该用户将成为该项目的维护者,从而导致使用许可证席位. 另外,请注意,如果您的项目是内部项目或私有项目,则来宾用户将具有上面的中提到的所有功能(例如,他们将无法浏览项目的存储库).
Auditor users
in GitLab Premium 8.17.
审核员用户被授予对 GitLab 实例上所有项目,组和其他资源的只读访问权限.
审核员用户应能够使用文档中所述的权限访问 GitLab 实例的所有项目和组.
Read more about Auditor users.
可以根据用户在项目设置上选择的可见性级别对用户隐藏 Wiki 和问题等项目功能.
- 禁用:所有人禁用
- 仅团队成员:即使您的项目是公开的或内部的,也只有团队成员才能看到
- 有访问权限的所有人:每个人都可以看到,具体取决于您的项目可见性级别
- 每个人:为所有人启用(仅适用于 GitLab 页面)
GitLab CI/CD permissions
注意:在 GitLab 11.0 中,”主”角色已重命名为”维护者”.
GitLab CI / CD 权限取决于用户在 GitLab 中的角色. 共有四个权限级别:
- admin
- maintainer
- developer
- guest/reporter
管理员用户可以在 GitLab 实例和项目范围内对 GitLab CI / CD 执行任何操作. 此外,所有管理员都可以使用/admin/runners
下的管理界面.
- 仅当工作是:
- 由用户触发
- 从 GitLab 13.0 开始 ,不为受保护的分支运行
Job permissions
注意:在 GitLab 11.0 中,”主”角色已重命名为”维护者”.
注意: GitLab 8.12 具有完全重新设计的作业权限系统. 阅读有关新模型及其含义的所有信息.
下表显示了由特定类型的用户触发的作业的授予特权:
- 仅当用户是项目成员时
GitLab 8.12 具有完全重新设计的工作权限系统. 要了解更多信息,请通读有关的文档.
Running pipelines on protected branches
合并或推送到受保护分支的权限用于定义用户是否可以运行 CI / CD 管道并在与那些分支相关的作业上执行操作.
有关管道安全模型的详细信息,请参阅的安全性.
LDAP users permissions
从 GitLab 8.15 开始,LDAP 用户权限现在可以由管理员用户手动覆盖. 通读有关的文档以了解更多信息.
项目别名只能由 GitLab 管理员读取,创建和删除. 通读有关项目别名的文档以了解更多信息.