在 GitHub 产品之间迁移时管理访问权限

关于 GitHub Enterprise Importer 所需的访问权限

为了保护您的数据，GitHub 对使用 GitHub Enterprise Importer 实施了特定的访问要求。这些要求根据您尝试执行的任务而有所不同。为了防止错误，您应该仔细阅读本文并验证您是否满足要完成的任务的所有要求。

要运行迁移，您需要对迁移的源和目标都有足够的访问权限。源是您要从中迁移数据的 GitHub.com 或 GitHub Enterprise Server 上的组织。目标是 GitHub.com 上的组织帐户（如果您要迁移仓库），或者 GitHub.com 上的企业帐户（如果您要迁移整个组织）。

为了进行迁移，无论是源代码库还是目标代码库，您都需要以下内容。

组织或企业帐户中的必要角色
可以访问组织或企业帐户的个人访问令牌
- 个人访问令牌必须具有所有必需的范围，这些范围取决于您的角色和您要完成的任务。
- 如果源代码库或目标代码库使用 SAML 单点登录访问 GitHub.com，则您必须为 SSO 授权个人访问令牌。

此外，如果您在源代码库或目标代码库中使用 IP 允许列表，您可能需要配置允许列表以允许 GitHub Enterprise Importer 访问。

如果您是第一次从 GitHub Enterprise Server 3.8 或更高版本迁移，您还需要一位拥有管理控制台访问权限的人员来为您的 GitHub Enterprise Server 实例设置 Blob 存储。

关于迁移者角色

为了避免组织所有者完成迁移，GitHub.com 包含一个用于使用 GitHub Enterprise Importer 的独特角色。授予迁移者角色允许您指定其他团队或个人来处理您的迁移。您只能为 GitHub.com 上的组织授予迁移者角色。

您可以将迁移者角色授予单个用户或团队。我们强烈建议您将迁移者角色分配给团队。然后，您可以通过调整团队成员资格来进一步自定义谁可以运行迁移。有关更改团队成员资格的更多信息，请参阅“将组织成员添加到团队”或“从团队中删除组织成员”。

要授予迁移者角色，请参阅“授予迁移者角色”。

授予迁移者角色后，请确保迁移者使用满足运行迁移所有要求的个人访问令牌。

注意

如果您要在 GitHub.com 上的两个组织之间迁移代码库，您可以将迁移者角色授予同一人员或团队，但您必须分别授予每个组织。
您无法为企业帐户授予迁移者角色。因此，您只能在您是目标企业的所有者的情况下运行组织迁移。但是，您可以为源组织的企业所有者授予迁移者角色。
GitHub CLI 不支持为 GitHub Enterprise Server 上的组织授予迁移者角色，因此您必须是源组织的组织所有者才能从 GitHub Enterprise Server 迁移代码库。

所需角色

对于迁移的源和目标，不同的任务需要不同的角色。

源组织

下表列出了哪些角色可以执行哪些任务。

任务	组织所有者	迁移者
运行迁移
为仓库迁移分配迁移者角色

目标组织或企业

下表列出了哪些角色可以执行哪些任务。

任务	企业所有者	组织所有者	迁移者
将组织迁移到企业
为仓库迁移分配迁移者角色
将仓库迁移到组织
下载迁移日志
回收人偶

个人访问令牌所需的范围

要运行迁移，您需要一个可以访问目标组织（对于仓库迁移）或企业帐户（对于组织迁移）的个人访问令牌。您还需要另一个可以访问源组织的个人访问令牌。

对于其他任务，例如下载迁移日志，您只需要一个可以访问操作目标的个人访问令牌。

GitHub 个人访问令牌（经典）所需的范围取决于您的角色和您要完成的任务。

注意：您只能使用个人访问令牌（经典），不能使用细粒度个人访问令牌。这意味着，如果您的组织使用“限制个人访问令牌（经典）访问您的组织”策略，则无法使用 GitHub Enterprise Importer。有关更多信息，请参阅“在您的企业中实施个人访问令牌策略”。

任务	企业所有者	组织所有者	迁移者
为仓库迁移分配迁移者角色		`admin:org`
运行仓库迁移（目标组织）		`repo`, `admin:org`, `workflow`	`repo`, `read:org`, `workflow`
下载迁移日志		`repo`, `admin:org`, `workflow`	`repo`, `read:org`, `workflow`
回收人偶		`admin:org`
运行迁移（源组织）		`admin:org`, `repo`	`admin:org`, `repo`
运行组织迁移（目标企业）	`read:enterprise`, `admin:org`, `repo`, `workflow`

授予迁移者角色

要允许组织所有者以外的人运行仓库迁移或下载迁移日志，您可以将迁移者角色授予用户或团队。有关更多信息，请参阅“关于迁移者角色”。

您可以使用 GitHub CLI 的 GEI 扩展或 GraphQL API 来授予迁移者角色。

"使用 GEI 扩展授予迁移者角色"
"使用 GraphQL API 授予迁移者角色"

使用 GEI 扩展授予迁移者角色

要使用 CLI 授予迁移者角色，您必须已安装 GitHub CLI 的 GEI 扩展。有关更多信息，请参阅 "将存储库从 GitHub.com 迁移到 GitHub Enterprise Cloud。"。

在 GitHub.com 上，创建并记录一个满足授予迁移者角色所有要求的个人访问令牌。有关更多信息，请参阅 "为 GitHub Enterprise Importer 创建个人访问令牌。"。
将个人访问令牌设置为环境变量，在以下命令中用您记录的个人访问令牌替换 TOKEN。
- 如果您使用的是终端，请使用 export 命令。
  Shell
```
export GH_PAT="TOKEN"
```
```
export GH_PAT="TOKEN"
```
- 如果您使用的是 PowerShell，请使用 $env 命令。
  Shell
```
$env:GH_PAT="TOKEN"
```
```
$env:GH_PAT="TOKEN"
```
使用 gh gei grant-migrator-role 命令，将 ORGANIZATION 替换为要授予迁移者角色的组织，将 ACTOR 替换为用户或团队名称，并将 TYPE 替换为 USER 或 TEAM。
Shell
```
gh gei grant-migrator-role --github-org ORGANIZATION --actor ACTOR --actor-type TYPE
```
```
gh gei grant-migrator-role --github-org ORGANIZATION --actor ACTOR --actor-type TYPE
```

使用 GraphQL API 授予迁移者角色

您可以使用 grantMigratorRole GraphQL 变异来分配迁移者角色，并使用 revokeMigratorRole 变异来撤销迁移者角色。

您必须使用满足所有访问要求的个人访问令牌 (PAT)。有关更多信息，请参阅 "个人访问令牌所需的范围。"。

`grantMigratorRole` 变异

此 GraphQL 变异设置迁移角色。

mutation grantMigratorRole (
  $organizationId: ID!,
  $actor: String!,
  $actor_type: ActorType!
) {
  grantMigratorRole( input: {
    organizationId: $organizationId,
    actor: $actor,
    actorType: $actor_type
  })
   { success }
}

查询变量	描述
`organizationId`	您组织的 `ownerId`（或组织 ID），来自 `GetOrgInfo` 查询。
`actor`	您想要分配迁移角色的团队或用户名。
`actor_type`	指定迁移者是`USER`还是`TEAM`。

`revokeMigratorRole` 突变

此突变将删除迁移者角色。

mutation revokeMigratorRole (
  $organizationId: ID!,
  $actor: String!,
  $actor_type: ActorType!
) {
  revokeMigratorRole( input: {
    organizationId: $organizationId,
    actor: $actor,
    actorType: $actor_type
  })
   { success }
}

为 GitHub Enterprise Importer 创建个人访问令牌

验证您是否具有完成所需任务的足够角色。有关更多信息，请参阅“所需角色”。
创建一个个人访问令牌（经典），确保授予完成所需任务的所有范围。您只能使用个人访问令牌（经典），不能使用细粒度个人访问令牌。有关更多信息，请参阅“管理您的个人访问令牌”和“个人访问令牌所需范围”。
如果对您需要访问的组织强制实施 SAML 单点登录，请为 SSO 授权个人访问令牌。有关更多信息，请参阅“授权个人访问令牌以用于 SAML 单点登录”。

配置迁移的 IP 允许列表

如果您的迁移的源或目标使用 IP 允许列表（GitHub 的 IP 允许列表功能或您的身份提供者 (IdP) 的 IP 允许列表限制，例如 Azure CAP），您需要在 GitHub 上配置 IP 允许列表。

如果您使用 GitHub 的 IP 允许列表功能，您必须将以下 GitHub IP 范围添加到源和/或目标组织的允许列表中。
如果您使用您的 IdP 的 IP 允许列表来限制对 GitHub 上的企业帐户的访问，您应该在迁移完成后在您的企业帐户设置中禁用这些限制。

有关更多信息，请参阅“管理组织的允许 IP 地址”和“使用 IP 允许列表限制对企业的网络流量”。

如果您的迁移的源是 GitHub Enterprise Server，您不需要将任何 GitHub IP 范围添加到您的防火墙配置或 GitHub Enterprise Server 实例上的 IP 允许列表中。但是，根据您的 Blob 存储提供商的设置，您可能需要更新您的 Blob 存储提供商的配置以允许访问以下 GitHub IP 范围。

识别 GitHub 的 IP 范围

您需要将以下 IP 范围添加到您的 IP 允许列表中。

192.30.252.0/22
185.199.108.0/22
140.82.112.0/20
143.55.64.0/20
40.71.233.224/28
2a0a:a440::/29
2606:50c0::/32
20.125.12.8/29 （自 2023 年 11 月 8 日世界标准时间 00:00 起生效）

您可以随时使用 REST API 的“获取 GitHub 元信息”端点获取 GitHub Enterprise Importer 使用的 IP 范围的最新列表。

响应中的 github_enterprise_importer 键包含用于迁移的 IP 范围列表。

有关更多信息，请参阅“REST API 元数据端点”。

进一步阅读

"组织中的角色"

管理 GitHub 产品之间迁移的访问权限

本文内容