Gestion de l’accès pour une migration entre des produits GitHub

Avant d’utiliser GitHub Enterprise Importer, veillez à disposer d’un accès approprié à la source et à la destination de votre migration.

Dans cet article

À propos de l’accès requis pour GitHub Enterprise Importer

Pour protéger vos données, GitHub applique des conditions d’accès spécifiques pour utiliser GitHub Enterprise Importer. Ces exigences varient en fonction de la tâche que vous essayez d'effectuer. Pour éviter les erreurs, vous devriez lire attentivement cet article et vérifier que vous remplissez toutes les conditions requises pour la tâche que vous souhaitez accomplir.

Pour exécuter une migration, vous avez besoin d’un accès suffisant à la source et à la destination de votre migration.

Quelles sont ma source et ma destination ?

La source est l’organisation sur GitHub.com ou GitHub Enterprise Server à partir de laquelle vous souhaitez migrer les données.

La destination peut être l’un des éléments suivants :

  • Un compte d’organisation sur GitHub.com ou GHE.com, si vous migrez des dépôts
  • Un compte d’entreprise sur GitHub.com ou GHE.com, si vous migrez l’intégralité d’une organisation

De quel accès ai-je besoin ?

Afin disposer d’un accès suffisant pour la migration, tant pour la source que pour la destination, vous devez disposer des éléments suivants :

  • Un rôle obligatoire dans le compte de l’organisation ou de l’entreprise
  • Un personal access token qui peut accéder au compte de l’organisation ou de l’entreprise
    • Le personal access token doit avoir toutes les étendues requises, qui dépendent de votre rôle et de la tâche que vous souhaitez effectuer.
    • Si la source ou la destination utilise l’authentification unique SAML pour GitHub.com, vous devez autoriser le personal access token pour l’authentification unique.

De plus, si vous utilisez des listes d’adresses IP autorisées avec la source ou la destination, vous devrez peut-être configurer les listes pour autoriser l’accès par GitHub Enterprise Importer.

Si vous migrez depuis GitHub Enterprise Server 3.8 ou version ultérieure pour la première fois, vous avez également besoin d’une personne ayant accès à la Console de gestion pour configurer le stockage d’objets blob pour votre instance GitHub Enterprise Server.

À propos du rôle de migrateur

Pour éviter aux propriétaires d’organisation de devoir effectuer des migrations, GitHub inclut un rôle distinct pour l’utilisation de GitHub Enterprise Importer.

L’octroi du rôle de migrateur vous permet de désigner d’autres équipes ou individus pour gérer vos migrations.

  • Vous ne pouvez attribuer le rôle de migrateur à une organisation que sur GitHub.com ou GHE.com.
  • Vous pouvez accorder le rôle de migrateur à un utilisateur individuel ou à une équipe. Nous vous recommandons vivement d’attribuer le rôle de migrateur à une équipe. Ensuite, vous pouvez personnaliser plus précisément qui peut exécuter une migration en ajustant l’appartenance à l’équipe. Consultez Ajout de membres d’une organisation à une équipe ou Suppression de membres d’organisation d’une équipe.
  • Le migrateur doit utiliser un personal access token qui répond à toutes les exigences pour l'exécution des migrations.

Avertissement

Lorsque vous accordez le rôle de migrateur dans une organisation à un utilisateur ou une équipe, vous lui accordez la possibilité d’importer ou d’exporter n’importe quel référentiel dans cette organisation.

Pour octroyer le rôle de migrateur, consultez Octroi du rôle de migrateur.

Remarque

  • Si vous migrez un dépôt entre deux organisations, vous pouvez accorder le rôle de migrateur à la même personne ou équipe pour les deux organisations, mais vous devez l’accorder séparément pour chacune.
  • Vous ne pouvez pas accorder le rôle de migrateur pour les comptes d’entreprise. Par conséquent, vous pouvez exécuter une migration d’organisation seulement si vous êtes propriétaire de l’entreprise de destination. Toutefois, vous pouvez accorder le rôle de migrateur à ce propriétaire d’entreprise pour l’organisation source.
  • GitHub CLI ne prend pas en charge l’octroi du rôle de migrateur pour les organisations sur GitHub Enterprise Server, donc vous devez être propriétaire de l’organisation source pour migrer des dépôts depuis GitHub Enterprise Server.

Rôles nécessaires

Pour la source et la destination de la migration, différents rôles sont requis pour différentes tâches.

Organisation source

Le tableau suivant répertorie les rôles qui peuvent effectuer certaines tâches :

TâchePropriétaire de l'organisationMigrateur
Exécution d’une migration
Attribution du rôle de migrateur pour les migrations de dépôts

Organisation ou entreprise de destination

Le tableau suivant répertorie les rôles qui peuvent effectuer certaines tâches :

TâchePropriétaire d’entreprisePropriétaire de l'organisationMigrateur
Migration d’organisations vers une entreprise
Attribution du rôle de migrateur pour les migrations de dépôts
Migration de dépôts vers une organisation
Téléchargement d’un journal de migration
Récupération de mannequins

Étendues requises pour les personal access token

Pour exécuter une migration, vous avez besoin d’un personal access token pouvant accéder à l’organisation de destination (pour les migrations de dépôts) ou au compte d’entreprise (pour les migrations d’organisations). Vous avez également besoin d’un autre personal access token qui peut accéder à l’organisation source.

Pour d’autres tâches, telles que le téléchargement d’un journal de migration, vous n’avez besoin que d’un personal access token pouvant accéder à la cible de l’opération.

Les étendues requises pour votre GitHub personal access token (classic) dépendent de votre rôle et de la tâche que vous souhaitez effectuer.

Remarque

Vous pouvez uniquement utiliser un personal access token (classic), pas un fine-grained personal access token. Cela signifie que vous ne pouvez pas utiliser GitHub Enterprise Importer si votre organisation utilise la stratégie « Empêcher personal access tokens (classic) d’accéder à vos organisations ». Pour plus d’informations, consultez « Application de stratégies pour les jetons d’accès personnels dans votre entreprise ».

TâchePropriétaire d’entreprisePropriétaire de l'organisationMigrateur
Attribution du rôle de migrateur pour les migrations de dépôtsadmin:org
Exécution d’une migration de dépôts (organisation de destination)
          `repo`, `admin:org``workflow` | 
          `repo`, `read:org``workflow`

Téléchargement d’un journal de migration | | repo, admin:org``workflow | repo, read:org``workflow Récupération de mannequins | | admin:org | Exécution d’une migration (organisation source) | | admin:org, repo | admin:org, repo | Exécution d’une migration d’organisation (entreprise de destination) | read:enterprise, admin:org``repo, workflow | | |

Octroi du rôle de migrateur

Pour permettre à une personne autre que le propriétaire de l’organisation d’exécuter une migration de dépôt ou de télécharger les journaux de migration, vous pouvez octroyer le rôle de migrateur à un utilisateur ou à une équipe. Pour en savoir plus, consultez À propos du rôle de migrateur.

Vous pouvez octroyer le rôle de migrateur à l’aide de la GEI extension of the GitHub CLI ou de l’API GraphQL.

Octroi du rôle de migrateur avec la GEI extension

Pour octroyer le rôle de migrateur à l’aide de la CLI, vous devez avoir installé la GEI extension of the GitHub CLI. Pour plus d’informations, consultez « Migration de dépôts de GitHub.com vers GitHub Enterprise Cloud ».

  1. Sur GitHub.com, créez et enregistrez un personal access token qui répond à toutes les conditions d’octroi du rôle de migrateur. Pour en savoir plus, consultez Création d’un personal access token pour GitHub Enterprise Importer.

  2. Définissez le personal access token comme variable d’environnement, en remplaçant TOKEN dans les commandes ci-dessous par le personal access token que vous avez enregistré ci-dessus.

    • Si vous utilisez le Terminal, utilisez la commande export.

      Shell
      export GH_PAT="TOKEN"

    • Si vous utilisez PowerShell, utilisez la commande $env.

      Shell
      $env:GH_PAT="TOKEN"

  3. Utilisez la commande gh gei grant-migrator-role en remplaçant ORGANIZATION par l’organisation pour laquelle vous souhaitez accorder le rôle de migrateur, ACTOR par le nom d’utilisateur ou d’équipe et TYPE par USER ou TEAM.

    Shell
    gh gei grant-migrator-role --github-org ORGANIZATION --actor ACTOR --actor-type TYPE

    Remarque

    Si vous accordez le rôle de migrateur à GHE.com, vous devez également inclure l'URL de l'API cible pour le sous-domaine de votre entreprise. Par exemple : --target-api-url https://api.octocorp.ghe.com.

Octroi du rôle de migrateur avec l’API GraphQL

Vous pouvez utiliser la mutation GraphQL grantMigratorRole pour attribuer le rôle de migrateur et la mutation revokeMigratorRole pour révoquer le rôle de migrateur.

Vous devez utiliser un personal access token (PAT) qui répond à tous les besoins d’accès. Pour plus d’informations, consultez les Champs d'application requis pour personal access tokens.

Mutation grantMigratorRole

Cette mutation GraphQL définit le rôle de migrateur.

mutation grantMigratorRole (
  $organizationId: ID!,
  $actor: String!,
  $actor_type: ActorType!
) {
  grantMigratorRole( input: {
    organizationId: $organizationId,
    actor: $actor,
    actorType: $actor_type
  })
   { success }
}
Variable de requêteDescription
organizationIdownerId (ou ID d’organisation) de votre organisation, issu de la requête GetOrgInfo.
actorÉquipe ou nom d’utilisateur auquel vous souhaitez attribuer le rôle de migrateur.
actor_typeSpécifiez si le migrateur est un USER ou une TEAM.

Mutation revokeMigratorRole

Cette mutation supprime le rôle de migrateur.

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

Création d’un personal access token pour GitHub Enterprise Importer

  1. Veillez à disposer d’un rôle suffisant pour la tâche que vous souhaitez effectuer. Pour plus d’informations, consultez Rôles requis.
  2. Créez un personal access token (classic), en veillant à accorder toutes les étendues requises pour la tâche que vous souhaitez effectuer. Vous pouvez uniquement utiliser un personal access token (classic), pas un fine-grained personal access token. Pour plus d’informations, consultez Gestion de vos jetons d’accès personnels et Étendues requises pour personal access token.
  3. Si une authentification unique SAML est appliquée pour la ou les organisations à laquelle vous devez accéder, autorisez le personal access token pour l’authentification unique. Pour plus d’informations, consultez « Autorisation d’un jeton d’accès personnel à utiliser avec l’authentification unique ».

Configuration de listes d’adresses IP autorisées pour les migrations

Si la source ou la destination de votre migration utilise une liste d’adresses IP autorisées (soit la fonctionnalité de la liste d’autorisations IP de GitHub, soit les restrictions de la liste d’adresses IP autorisées de votre fournisseur d’identité (IdP), comme Azure CAP), vous devez configurer des listes d’autorisations IP sur GitHub. Consultez Gestion des adresses IP autorisées pour votre organisation et Restriction du trafic réseau vers votre entreprise avec une liste d’adresses IP autorisées.

  • Si vous utilisez la fonctionnalité de liste d’adresses IP autorisées de GitHub, vous devez ajouter les plages d’adresses IP de GitHub ci-dessous à la liste pour les organisations sources et/ou de destination.
  • Si vous utilisez la liste d’adresses IP autorisées de votre IdP pour restreindre l’accès à votre entreprise sur GitHub, vous devez désactiver ces restrictions dans les paramètres de votre compte d’entreprise jusqu’à ce que la migration soit terminée.

Les plages d'adresses IP varient selon que la destination de votre migration est GitHub.com ou GHE.com.

Si la source de votre migration est GitHub Enterprise Server, vous n’avez pas besoin d’ajouter des plages d’adresses IP GitHub à votre configuration de pare-feu ou à la liste d’adresses IP autorisées sur votre instance GitHub Enterprise Server. Toutefois, en fonction de la configuration de votre fournisseur de stockage de blobs, vous devrez peut-être mettre à jour la configuration de votre fournisseur de stockage de blobs pour autoriser l’accès aux plages d’adresses IP GitHub ci-dessous.

Plages d’adresses IP pour GitHub.com

Vous devez ajouter les plages d'adresses IP suivantes à vos listes d'adresses IP autorisées :

  • 192.30.252.0/22
  • 185.199.108.0/22
  • 140.82.112.0/20
  • 143.55.64.0/20
  • 135.234.59.224/28 (ajouté le 28 juillet 2025)
  • 2a0a:a440::/29
  • 2606:50c0::/32
  • 20.99.172.64/28 (ajouté le 28 juillet 2025)

Vous pouvez obtenir une liste à jour des plages d'adresses IP utilisées par GitHub Enterprise Importer à tout moment avec le point de terminaison « Obtenir les métadonnées de GitHub » de l'API REST.

La clé github_enterprise_importer dans la réponse contient une liste de plages d’adresses IP utilisées pour les migrations.

Pour plus d’informations, consultez « Points de terminaison d’API REST pour les métadonnées ».

Règles de pare-feu de réseau virtuel pour Stockage Blob Azure pour GitHub.com

Les clients ayant configuré Azure Blob Storage pour stocker les données du référentiel pour les migrations doivent ajouter des règles de pare-feu de réseau virtuel à leurs comptes de stockage afin de permettre à GEI d'accéder aux données du référentiel. Cela nécessite l’utilisation du Azure CLI ou de PowerShell, car l’ajout de ces règles de pare-feu de réseau virtuel sur le portail Azure n’est actuellement pas pris en charge. Les ID de sous-réseau de réseau virtuel suivants doivent être ajoutés aux règles de pare-feu de réseau virtuel pour votre compte de stockage :

  • /subscriptions/cdf1c65c-e6f4-43b3-945f-c5280f104f9c/resourceGroups/ghr-network-service-1a72ec6f-45b6-44be-a4bd-f0fe50079c9f-5-westus2/providers/Microsoft.Network/virtualNetworks/1a72ec6f-45b6-44be-a4bd-f0fe50079c9f-5/subnets/1a72ec6f-45b6-44be-a4bd-f0fe50079c9f-5
  • /subscriptions/173ad082-b20d-4d44-8257-7fbf34959bed/resourceGroups/ghr-network-service-1a72ec6f-45b6-44be-a4bd-f0fe50079c9f-5-westus3/providers/Microsoft.Network/virtualNetworks/1a72ec6f-45b6-44be-a4bd-f0fe50079c9f-5/subnets/1a72ec6f-45b6-44be-a4bd-f0fe50079c9f-5

Pour ajouter les règles de pare-feu de réseau virtuel à votre compte de stockage Azure, vous pouvez suivre l’étape 5 de la documentation relative à la création d’une règle de réseau virtuel pour le stockage Azure à l’aide des ID de sous-réseau fournis ci-dessus. Veillez à fournir l’argument --subscription avec l’ID d’abonnement lié au compte de stockage.

Plages d’adresses IP pour GHE.com

Vous pouvez obtenir une liste à jour des plages d’adresses IP utilisées par GitHub Enterprise Importer à tout moment avec le point de terminaison « Obtenir les informations de métadonnées GitHub » de l’API REST.

La clé github_enterprise_importer dans la réponse contient une liste de plages d’adresses IP utilisées pour les migrations.

En outre, si vous migrez depuis GitHub Enterprise Server et que vous utilisez un compte de stockage d’objets blob avec des règles de pare-feu :

  • Vous devez autoriser l'accès aux plages d'adresses IP de sortie pour GHE.com. Consultez Détails réseau pour GHE.com.
  • Si vous utilisez Stockage Blob Azure, vous devrez peut-être effectuer une configuration réseau supplémentaire. Cela peut se produire si votre Stockage Blob Azure se trouve dans la même région que le calcul du service GitHub Enterprise Importer. Veuillez contacter Support GitHub.

Pour aller plus loin