Basic Gitea Information
基本结构
基本的 Gitea 环境结构是通过 组织 来分组仓库,每个组织可以包含 多个仓库 和 多个团队。但是,请注意,正如在 GitHub 中,用户可以在组织外拥有仓库。
此外,用户 可以是 不同组织的成员。在组织内,用户可能对每个仓库拥有 不同的权限。
用户也可以是 不同团队的一部分,对不同仓库拥有不同的权限。
最后,仓库可能具有特殊的保护机制。
权限
组织
当 组织被创建 时,会创建一个名为 Owners 的团队,并将用户放入其中。该团队将提供对 组织 的 管理员访问,这些 权限 和团队的 名称 无法修改。
组织管理员(所有者)可以选择组织的 可见性:
公开
限制(仅限登录用户)
私有(仅限成员)
组织管理员 还可以指示 仓库管理员 是否可以 添加或移除 团队的访问权限。他们还可以指示最大仓库数量。
创建新团队时,会选择几个重要设置:
指定 团队成员可以访问的组织仓库:特定仓库(团队被添加的仓库)或所有仓库。
还指示 成员是否可以创建新仓库(创建者将获得管理员访问权限)
成员 在仓库中将 拥有的权限:
管理员 访问
特定 访问:
团队与用户
在仓库中,组织管理员 和 仓库管理员(如果组织允许)可以 管理 分配给合作者(其他用户)和团队的角色。可能的 角色 有 3 种:
管理员
写入
读取
Gitea 认证
网络访问
使用 用户名 + 密码,并可能(推荐)使用 2FA。
SSH 密钥
您可以使用一个或多个公钥配置您的帐户,允许相关的 私钥代表您执行操作。 http://localhost:3000/user/settings/keys
GPG 密钥
您 无法使用这些密钥冒充用户,但如果您不使用它,可能会因为 发送未签名的提交而被发现。
个人访问令牌
您可以生成个人访问令牌,以 授予应用程序访问您的帐户。个人访问令牌对您的帐户具有完全访问权限:http://localhost:3000/user/settings/applications
Oauth 应用程序
与个人访问令牌一样,Oauth 应用程序 将对您的帐户及其访问的地方具有 完全访问权限,因为如 文档 所示,范围尚不支持:
部署密钥
部署密钥可能对仓库具有只读或写入访问权限,因此它们可能对特定仓库的妥协很有趣。
分支保护
分支保护旨在 不将仓库的完全控制权授予用户。目标是在能够在某些分支中写入代码之前 设置几种保护方法。
仓库的分支保护 可以在 https://localhost:3000/<orgname>/<reponame>/settings/branches 中找到。
无法在组织级别设置分支保护。因此,所有保护必须在每个仓库中声明。
可以对分支(例如主分支)应用不同的保护:
禁用推送:无人可以推送到此分支
启用推送:任何有访问权限的人都可以推送,但不能强制推送。
白名单限制推送:只有选定的用户/团队可以推送到此分支(但不能强制推送)
启用合并白名单:只有白名单中的用户/团队可以合并 PR。
启用状态检查:要求状态检查在合并之前通过。
要求批准:指示在 PR 可以合并之前所需的批准数量。
限制批准给白名单:指示可以批准 PR 的用户/团队。
在拒绝审查时阻止合并:如果请求更改,则无法合并(即使其他检查通过)
在官方审查请求时阻止合并:如果有官方审查请求,则无法合并
撤销过期的批准:当有新提交时,旧的批准将被撤销。
要求签名提交:提交必须签名。
如果拉取请求过时则阻止合并
受保护/不受保护的文件模式:指示要保护/不保护的文件模式
正如您所看到的,即使您设法获得了用户的一些凭据,仓库可能受到保护,避免您将代码推送到主分支,例如,以妥协 CI/CD 管道。
Last updated