Informationen zum erforderlichen Zugriff für GitHub Enterprise Importer
Zum Schutz deiner Daten erzwingt GitHub bestimmte Zugriffsanforderungen für die Verwendung von GitHub Enterprise Importer. Diese Anforderungen variieren je nach Aufgabe, die du auszuführen versuchts. Um Fehler zu vermeiden, solltest du diesen Artikel sorgfältig lesen und überprüfen, ob alle Anforderungen für die geplante Aufgabe erfüllt sind.
Um ein Repository von Azure DevOps zu GitHub zu migrieren, benötigst du ausreichende Zugriffrechte für den Zugriff auf die Quelle (eine Organisation in Azure DevOps) und das Ziel (eine Organisation auf GitHub). Für ausreichende Zugriffsrechte benötigst du alle folgenden Elemente.
- Eine erforderliche Rolle in der Zielorganisation auf GitHub
- Ein personal access token mit Zugriffsrecht für die Zielorganisation auf GitHub
- Das personal access token muss alle erforderlichen Bereiche umfassen, die von deiner Rolle und der Aufgabe abhängen, die du ausführen möchtest.
- Wenn die Zielorganisation einmaliges Anmelden mit SAML für GitHub verwendet, musst personal access token für einmaliges Anmelden autorisiert werden.
- Eine personal access token, die auf die Quellorganisation in Azure DevOps zugreifen kann.
Wenn du darüber hinaus Listen zugelassener IP-Adressen an der Quelle oder am Ziel verwendest, musst du möglicherweise die Positivlisten konfigurieren, um den Zugriff von GitHub Enterprise Importer zuzulassen.
Informationen zur Migrationsrolle
Damit die Migrationsvorgänge nicht unbedingt von Organisationsbesitzer*innen abgeschlossen werden müssen, bietetGitHub eine spezielle Rolle für die Verwendung von GitHub Enterprise Importer.
Durch das Zuweisen der Migrationsrolle kannst du andere Teams oder Personen festlegen, die deine Migrationsvorgänge durchführen sollen.
- Du kannst einer Organisation auf GitHub.com oder GHE.com nur die Migrationsrolle zuweisen.
- Du kannst die Migrationsrolle einzelnen Benutzer*innen oder einem Team zuweisen. Es wird dringend empfohlen, die Migrationsrolle einem Team zuzuweisen. Anschließend kannst du die Personen, die eine Migration ausführen können, genauer bestimmen, indem du die Teammitgliedschaft anpasst. Siehe „Organisationsmitglieder zu einem Team hinzufügen“ oder „Organisationsmitglieder aus einem Team entfernen“.
- Der Migrator muss ein personal access token verwenden, das alle Anforderungen für die Ausführung von Migrationsvorgängen erfüllt.
Warning
Wenn Sie der Migrationsrolle in einer Organisation einem Benutzer oder Team zuweisen, gewähren Sie ihnen die Möglichkeit, Repositorys in dieser Organisation zu importieren oder zu exportieren.
Informationen zur Zuweisung der Migrationsrolle sind unter Zuweisen der Migrationsrolle zu finden.
Erforderliche Rollen für GitHub
Für die Zielorganisation auf GitHub sind unterschiedliche Rollen für unterschiedliche Aufgaben erforderlich.
Aus der folgenden Tabelle geht hervor, welche Aufgaben von welcher Rolle ausgeführt werden können.
Aufgabe | Organisationsbesitzer | Migrator |
---|---|---|
Zuweisen der Migrationsrolle für Repositorymigrationsvorgänge | ||
Ausführen einer Repository-M | ||
Herunterladen eines Migrationsprotokolls | ||
Freigeben von Mannequins |
Erforderliche Bereiche für personal access token
Zum Ausführen einer Migration benötigst du eine personal access token, die auf die Zielorganisation auf GitHub zugreifen kann, und eine weitere personal access token, die auf die Quellorganisation in Azure DevOps zugreifen kann.
Für andere Aufgaben, zum Beispiel das Herunterladen eines Migrationsprotokolls, benötigst du nur eine personal access token, die auf die Zielorganisation auf GitHub zugreifen kann.
Personal access token für GitHub
Welche Bereiche für dein GitHub-personal access token (classic) erforderlich sind, hängt von deiner Rolle und der Aufgabe ab, die du ausführen möchtest.
Hinweis: Du kannst nur ein personal access token (classic) verwenden, kein fine-grained personal access token. Dies bedeutet, dass du GitHub Enterprise Importer nicht verwenden kannst, wenn deine Organisation die Richtlinie „Zugriff auf die Organisation durch personal access tokens (classic) einschränken“ verwendet. Weitere Informationen findest du unter Erzwingen von Richtlinien für persönliche Zugriffstoken in deinem Unternehmen.
Aufgabe | Organisationsbesitzer | Migrator |
---|---|---|
Zuweisen der Migrationsrolle für Repositorymigrationsvorgänge | admin:org | |
Ausführen einer Repositorymigration (Zielorganisation) | repo , admin:org , workflow | repo , read:org , workflow |
Herunterladen eines Migrationsprotokolls | repo , admin:org , workflow | repo , read:org , workflow |
Freigeben von Mannequins | admin:org |
Personal access token für Azure DevOps
Das Azure DevOps personal access token muss die Bereiche work item (read)
, code (read)
und identity (read)
haben.
Wenn Sie bei der Erstellung eines Migrationsskripts die Flag --rewire-pipelines
verwenden möchten, benötigen Sie außerdem Build (Read)
Reservierungsumfang. Um die Flags inventory-report
und --integrate-boards
zu verwenden, müssen Sie Vollzugriff auf Ihre personal access token gewähren.
Wenn du von mehreren Organisationen migrieren möchtest, benötigt das personal access token Zugriff auf alle zugänglichen Organisationen. Weitere Informationen findest du unter Verwenden von personal access token in der Microsoft-Dokumentation.
Gewähren der Migrationsrolle
Um einer anderen Person als einer Organisationsbesitzer das Ausführen einer Migration oder das Herunterladen von Migrationsprotokollen zu ermöglichen, können einem Benutzer oder Team die Migrationsrolle zuweisen. Weitere Informationen finden Sie unter „Informationen zur Migrationsrolle“.
Sie können die Migrationsrolle entweder über ADO2GH extension of the GitHub CLI oder über die GraphQL-API zuweisen.
- „Zuweisen der Migrationsrolle mit der ADO2GH extension“
- „Gewähren der Migrationsrolle mit der GraphQL-API“
Zuweisen der Migrationsrolle mit der ADO2GH extension
Zum Zuweisen der Migrationsrolle über die CLI muss ADO2GH extension of the GitHub CLI installiert sein. Weitere Informationen findest du unter Migrieren von Repositorys von Azure DevOps zu GitHub Enterprise Cloud.
-
Erstellen und erfassen Sie auf GitHub ein personal access token, das alle Anforderungen für die Zuweisung der Migrator-Rolle erfüllt. Weitere Informationen sind unter Erstellen eines personal access token für GitHub zu finden.
-
Lege das personal access token als Umgebungsvariable fest, und ersetze in den folgenden Befehlen TOKEN durch das personal access token, das du oben gespeichert hast.
-
Wenn du ein Terminal verwendest, führe den Befehl
export
aus.Shell export GH_PAT="TOKEN"
export GH_PAT="TOKEN"
-
Wenn du PowerShell verwendest, führe den Befehl
$env
aus.Shell $env:GH_PAT="TOKEN"
$env:GH_PAT="TOKEN"
-
-
Verwende den Befehl
gh ado2gh grant-migrator-role
, und ersetze ORGANIZATION durch die Organisation, der du die Migrationsrolle zuweisen möchtest, ACTOR durch den Benutzer- oder Teamnamen und TYPE durchUSER
oderTEAM
.Shell gh ado2gh grant-migrator-role --github-org ORGANIZATION --actor ACTOR --actor-type TYPE
gh ado2gh grant-migrator-role --github-org ORGANIZATION --actor ACTOR --actor-type TYPE
Note
Wenn du die Migrationsrolle für GHE.com gewährst, musst du auch die Ziel-API-URL für die Unterdomäne deines Unternehmens einschließen. Beispiel:
--target-api-url https://api.octocorp.ghe.com
Gewähren der Migrationsrolle mit der GraphQL-API
Du kannst die GraphQL-Mutation grantMigratorRole
verwenden, um die Migrationsrolle zuzuweisen, und die revokeMigratorRole
-Mutation, um die Migrationsrolle zu widerrufen.
Du musst ein personal access token (PAT) verwenden, das alle Zugriffsanforderungen erfüllt. Weitere Informationen sind unter „Erforderliche Bereiche für personal access token“ zu finden.
grantMigratorRole
-Mutation
Diese GraphQL-Mutation legt die Migrationsrolle fest.
mutation grantMigratorRole (
$organizationId: ID!,
$actor: String!,
$actor_type: ActorType!
) {
grantMigratorRole( input: {
organizationId: $organizationId,
actor: $actor,
actorType: $actor_type
})
{ success }
}
Abfragevariable | Beschreibung |
---|---|
organizationId | Die ownerId (oder Organisations-ID) deiner Organisation aus der GetOrgInfo -Abfrage. |
actor | Der Team- oder Benutzername, dem du die Migrationsrolle zuweisen möchtest. |
actor_type | Gib an, ob es die Migrationsrolle einem USER oder einem TEAM zugewiesen wird. |
revokeMigratorRole
-Mutation
Diese Mutation entfernt die Migrationsrolle.
mutation revokeMigratorRole (
$organizationId: ID!,
$actor: String!,
$actor_type: ActorType!
) {
revokeMigratorRole( input: {
organizationId: $organizationId,
actor: $actor,
actorType: $actor_type
})
{ success }
}
Erstellen eines personal access token für GitHub
- Vergewissere dich, dass du über eine ausreichende Rolle für die Aufgabe verfügen, die du ausführen möchtest. Weitere Informationen findest du unter Erforderliche Rollen.
- Erstelle ein personal access token (classic), und stelle sicher, dass du alle Bereiche zuweist, die für die auszuführende Aufgabe erforderlich sind. Du kannst nur ein personal access token (classic) verwenden, kein fine-grained personal access token. Weitere Informationen findest du unter Verwalten deiner persönlichen Zugriffstoken und Erforderliche Bereiche für personal access token.
- Wenn einmaliges Anmelden mit SAML für die Organisationen erzwungen wird, auf die du zugreifen musst, autorisierst du das personal access token für einmaliges Anmelden. Weitere Informationen findest du unter Ein persönliches Zugriffstoken für die Verwendung mit SAML Single Sign-On autorisieren.
Konfigurieren von Listen zugelassener IP-Adressen für Migrationsvorgänge
Wenn die Quelle oder das Ziel deiner Migration eine Liste zugelassener IP-Adressen verwendet (entweder das Feature für Listen zugelassener IP-Adressen von GitHub oder die Einschränkungen für Listen zugelassener IP-Adressen deines Identitätsanbieters (IdP) (z. B. Azure CAP), musst du die Listen zugelassener IP-Adressen auf GitHub konfigurieren. Siehe „Verwaltung erlaubter IP-Adressen für deine Organisation“ und „Einschränken des Netzwerkdatenverkehrs in deinem Unternehmen mit einer Liste zugelassener IP-Adressen“.
- Wenn du das Feature für Listen zugelassener IP-Adressen von GitHub verwendest, musst du der Positivliste die unten angegebenen GitHub-IP-Bereiche für die Quell- und/oder Zielorganisationen hinzufügen.
- Wenn du die Liste zugelassener IP-Adressen deines Identitätsanbieters verwendest, um den Zugriff auf dein Unternehmen in GitHub einzuschränken, solltest du diese Einschränkungen in den Einstellungen deines Unternehmenskontos deaktivieren, bis die Migration abgeschlossen ist.
Die IP-Bereiche variieren je nachdem, ob das Ziel deiner Migration GitHub.com oder GHE.com ist.
IP-Adressbereiche für GitHub.com
Du musst deiner Liste/deinen Listen zugelassener IP-Adressen die folgenden IP-Bereiche hinzufügen:
- 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 (aktiv seit 00:00 UTC am 8. November 2023)
Mit dem Endpunkt „Get GitHub meta information“ der REST-API können Sie jederzeit eine aktuelle Liste der von GitHub Enterprise Importer verwendeten IP-Bereiche abrufen.
Der github_enterprise_importer
-Schlüssel in der Antwort enthält eine Liste der IP-Bereiche, die für Migrationsvorgänge verwendet werden.
Weitere Informationen findest du unter REST-API-Endpunkte für Metadaten.
IP-Adressbereiche für GHE.com
Du musst deiner Liste/deinen Listen zugelassener IP-Adressen die folgenden IP-Bereiche hinzufügen:
- 192.30.252.0/22
- 185.199.108.0/22
- 140.82.112.0/20
- 143.55.64.0/20
- 2a0a:a440::/29
- 2606:50c0::/32
- 4.231.155.80/29
- 4.225.9.96/29
- 51.12.144.32/29
- 20.199.1.232/29
- 51.12.152.184/29
- 20.199.6.80/29
- 51.12.152.240/29
- 20.19.101.136/29
- 51.12.252.16/28
- 74.241.131.48/28
- 20.240.211.176/28
- 108.143.221.96/28
- 20.61.46.32/28
- 20.224.62.160/28