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

Avant d’utiliser GitHub Enterprise Importer, vérifiez que vous disposez d’un accès approprié à la fois à 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 des 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 une organisation entière

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 pouvant accéder au compte d’organisation ou d’entreprise
    • Le personal access token doit disposer de toutes les autorisations 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 via SAML pour GitHub.com, vous devez autoriser personal access token pour l’authentification unique.

En outre, si vous utilisez des listes d’autorisation IP avec la source ou la destination, vous devrez peut-être configurer les listes d’autorisation pour autoriser l’accès par GitHub Enterprise Importer.

Si vous effectuez une migration depuis la version 3.8 ou une version ultérieure de GitHub Enterprise Server pour la première fois, vous avez également besoin d’une personne disposant d’un accès à Console de gestion pour configurer le stockage 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’attribution du rôle de migrateur pour les organisations sur GitHub Enterprise Server. Vous devez donc ê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 personal access tokens

Pour exécuter une migration, vous avez besoin d’un personal access token compte d’entreprise pouvant accéder à l’organisation de destination (pour les migrations de référentiels) ou au compte d’entreprise (pour les migrations d’organisation). 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’en avez besoin qu’une personal access token qui peut accéder à la cible de l’opération.

Les étendues requises pour votre GitHubpersonal access token (classic) rôle 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 « Restreindre personal access tokens (classic) l’accès à 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 mannequinsadmin: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 attribuer le rôle migrator à l’aide de GEI extension of the GitHub CLI ou de l’API GraphQL.

Attribution du rôle de migrateur avec le GEI extension

Pour accorder le rôle de migrateur à l’aide de la CLI, vous devez avoir installé le 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 remplit toutes les conditions requises pour obtenir le rôle de migrateur. Pour plus d’informations, 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 à attribuer toutes les autorisations 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, autoTITLE et étendues requises pour personal access token.
  3. Si l’authentification unique SAML est imposée pour la ou les organisations auxquelles vous devez accéder, autorisez le personal access token pour le SSO. 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 GitHub de plages d’adresses IP à votre configuration de pare-feu ou à la liste d’autorisation IP sur votre instance GitHub Enterprise Server. Toutefois, selon la configuration de votre fournisseur de stockage d’objets blob, vous devrez peut-être mettre à jour la configuration de votre fournisseur de stockage d’objets blob pour autoriser l’accès aux GitHub plages d’adresses IP 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 pourGitHub.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 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.

En outre, si vous migrez depuis GitHub Enterprise Server et utilisez un compte de stockage 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