Gestion de l’accès pour une migration à partir de Bitbucket Server

À 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 migrer un référentiel de Bitbucket Server vers GitHub, vous avez besoin d’un accès suffisant à la source (votre instance Bitbucket Server) et à la destination (une organisation sur GitHub). Pour disposer d'un niveau d'accès suffisant, vous aurez besoin de toutes les choses suivantes.

Rôle requis dans l'organisation de destination sur GitHub
Un personal access token qui peut accéder à l'organisation de destination sur GitHub
- 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 l'organisation de destination utilise l'authentification unique SAML pour GitHub, vous devez autoriser personal access token pour SSO.
Sur Bitbucket Server, autorisations obligatoires, et accès SFTP ou SMB

En outre, si vous utilisez des listes adresses IP autorisées dans l’organisation de destination, vous devrez peut-être configurer les listes vertes pour accorder l’accès par GitHub Enterprise Importer.

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

Rôles requis pour GitHub

Pour l'organisation de destination sur GitHub, différents rôles sont requis pour différentes tâches.

Le tableau suivant répertorie les tâches pouvant être effectuées par les différents rôles.

Tâche	Propriétaire de l'organisation	Migrateur
Attribution du rôle de migrateur pour les migrations de dépôts
Exécution d'une migration de référentiel
Téléchargement d’un journal de migration
Récupération de mannequins

Étendues requises pour les personal access token

Pour effectuer une migration, vous avez besoin d’un personal access token qui peut accéder à l’organisation de destination sur GitHub

Les étendues requises pour votre personal access token (classic) GitHub 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) pour 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âche	Propriétaire de l'organisation	Migrateur
Attribution du rôle de migrateur pour les migrations de dépôts	`admin: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`

Autorisations requises pour Bitbucket Server

Pour effectuer une migration à partir de Bitbucket Server, vous devez avoir :

Nom d’utilisateur et mot de passe d’un compte Bitbucket Server disposant d’autorisations d’administrateur ou de super administrateur
Si vos instances Bitbucket Server s’exécutent sur Linux, utilisez l’accès SFTP à l’instance Bitbucket Server (consultez Clés SSH). En général, si vous pouvez accéder au serveur via SSH, vous pouvez également utiliser SFTP.
Si votre instance Bitbucket Server s’exécute sur Windows, accès du partage de fichiers (SMB) à l’instance

Clés SSH

Si votre instance Bitbucket Server s’exécute sur Linux, vous devez utiliser une clé SSH qui répond aux conditions suivantes :

N’a pas de phrase secrète
Utilise l’un des chiffrements suivants
- aes256-ctr
- 3des-cbc
- aes128-cbc
- aes192-cbc
- aes256-cbc
- blowfish-cbc
- twofish-cbc
- twofish192-cbc
- twofish128-cbc
- twofish256-cbc
- arcfour
- arcfour128
- arcfour256
- cast128-cbc
- aes128-ctr
- aes192-ctr

Si vous recevez une erreur comme cipher name aes256-ctr for openssh key file is not supported lors de l’exécution d’une migration, votre clé privée SSH utilise un chiffrement non pris en charge. Pour plus d’informations sur la génération d’une clé privée compatible, consultez Résolution des problèmes de votre migration avec GitHub Enterprise Importer.

Octroi du rôle de migrateur

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

Vous pouvez octroyer le rôle de migrateur en utilisant soit BBS2GH extension of the GitHub CLI, soit l’API GraphQL.

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

Octroi du rôle de migrateur avec l’BBS2GH extension

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

Sur GitHub, créez et enregistrez un personal access token qui répond à toutes les conditions d’octroi du rôle de migrateur. Pour plus d’information, consultez Création d’un personal access token pour GitHub Enterprise Importer.
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"
```
```
export GH_PAT="TOKEN"
```
- Si vous utilisez PowerShell, utilisez la commande $env.
  Shell
```
$env:GH_PAT="TOKEN"
```
```
$env:GH_PAT="TOKEN"
```
Utilisez la commande gh bbs2gh 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 bbs2gh grant-migrator-role --github-org ORGANIZATION --actor ACTOR --actor-type TYPE
```
```
gh bbs2gh 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ête	Description
`organizationId`	`ownerId` (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_type`	Spé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

Veillez à disposer d’un rôle suffisant pour la tâche que vous souhaitez effectuer. Pour plus d’informations, consultez Rôles requis.
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.
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 destination de votre migration utilise une liste d’adresses IP autorisées (soit la fonction de liste d’adresses IP autorisées de GitHub, soit les restrictions de liste d’adresses IP autorisées de votre fournisseur d’identité (IdP), vous devez configurer des listes d’adresses IP autorisées sur GitHub.

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 verte pour les organisations 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.

Pour plus d’informations, 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 ».

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 GitHub les méta informations » 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 du réseau virtuel pour Azure Blob Storage 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 devez autoriser :

Plages nécessaires pour tout le monde
Plages supplémentaires en fonction de la région de résidence des données

Pour les plages à ajouter, consultez Détails réseau pour GHE.com.

En outre, si vous 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

Rôles dans une organisation

Gestion de l’accès pour une migration à partir de Bitbucket Server

Dans cet article