Verwalten des Zugriffs für eine Migration von Azure DevOps

Bevor du GitHub Enterprise Importer verwendest, musst du sicherstellen, dass du über ausreichenden Zugriff auf die Quelle und das Ziel deiner Migration verfügst.

In diesem Artikel

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.

AufgabeOrganisationsbesitzerMigrator
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.

Note

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.

AufgabeOrganisationsbesitzerMigrator
Zuweisen der Migrationsrolle für Repositorymigrationsvorgängeadmin:org
Ausführen einer Repositorymigration (Zielorganisation)repo, admin:org, workflowrepo, read:org, workflow
Herunterladen eines Migrationsprotokollsrepo, admin:org, workflowrepo, read:org, workflow
Freigeben von Mannequinsadmin: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 findest du 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

Zum Zuweisen der Migrationsrolle über die CLI muss ADO2GH extension of the GitHub CLI installiert sein. Weitere Informationen finden Sie unter Migrieren von Repositorys von Azure DevOps zu GitHub Enterprise Cloud.

  1. Erstellen und erfassen Sie auf GitHub ein personal access token, das alle Anforderungen für die Zuweisung der Migrator-Rolle erfüllt. Weitere Informationen findest du unter Erstellen eines personal access token für GitHub.

  2. 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"

    • Wenn du PowerShell verwendest, führe den Befehl $env aus.

      Shell
      $env:GH_PAT="TOKEN"

  3. 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 durch USER oder TEAM.

    Shell
    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 }
}
AbfragevariableBeschreibung
organizationIdDie ownerId (oder Organisations-ID) deiner Organisation aus der GetOrgInfo-Abfrage.
actorDer Team- oder Benutzername, dem du die Migrationsrolle zuweisen möchtest.
actor_typeGib 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

  1. 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.
  2. 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.
  3. 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

Weiterführende Themen