Migrer des projets

Ce guide explique comment déplacer un projet entre des organisations ou des emplacements au sein d'une hiérarchie de ressources.

La ressource "Projet" constitue l'entité d'organisation de base dans une organisation Google Cloud. Les projets sont créés dans des organisations et peuvent être placés dans des dossiers ou dans la ressource "Organisation" elle-même, formant la hiérarchie des ressources. Vous devrez peut-être migrer des projets entre organisations en raison d'acquisitions, d'exigences réglementaires et d'une séparation entre les unités commerciales, entre autres.

Vous pouvez utiliser l'API Resource Manager pour déplacer des projets d'une organisation à une autre ou vers un autre emplacement dans la hiérarchie des ressources de son organisation actuelle. L'API Resource Manager vous permet également d'effectuer un rollback de la migration pour replacer le projet à son emplacement d'origine dans la hiérarchie des ressources.

Créer un plan de migration

Le plus important à prendre en compte lors du déplacement d'un projet est l'impact de la migration sur les services exécutés dans le projet. L'API Resource Manager traite la ressource de projet et tous les services exécutés en dessous comme une seule unité, ce qui signifie qu'aucune modification de configuration n'est appliquée dans le projet.

Même si la migration n'apporte pas de modifications de configuration directes au projet, la modification de la hiérarchie des ressources est susceptible d'avoir un impact sur le fonctionnement du projet et de ses services en cours d'exécution. Les stratégies héritées, telles que les stratégies Identity and Access Management ou les règles d'administration, ne sont pas transférées avec le projet pendant la migration. Seules les stratégies et les comptes de service sont directement associés à la ressource. Cela peut entraîner un comportement inattendu une fois la migration terminée.

Avant de déplacer votre projet, vous devez envisager de créer un plan de migration pour déterminer le niveau de préparation de votre organisation et des projets que vous souhaitez déplacer. Dans ce plan de migration, faites l'inventaire de chacun des services exécutés par votre projet et de tous les services susceptibles d'être affectés par le déplacement ou par la hiérarchie des ressources dans la destination de votre projet.

Présentation de l'inventaire

Utilisez l'inventaire des éléments cloud pour créer une vue d'ensemble des ressources utilisées, y compris des stratégies Identity and Access Management. Vous pouvez utiliser cette présentation pour vous aider à élaborer votre plan de migration.

Vous pouvez également utiliser l'inventaire des éléments cloud pour transférer ces données dans BigQuery. Vous pourrez ainsi interroger les données à l'aide de SQL, ce qui est plus facile à lire que l'interprétation des données au format JSON. Pour en savoir plus sur l'exportation de ces données, consultez la page Exporter vers BigQuery.

Validation des stratégies

Lorsque vous migrez votre projet, il n'hérite plus des stratégies de son emplacement actuel dans la hiérarchie des ressources et est soumis à l'évaluation effective des stratégies à sa destination. Nous vous recommandons de vous assurer que les stratégies en vigueur à la destination du projet correspondent autant que possible aux règles du projet dans son emplacement source.

Toutes les règles appliquées directement au projet seront toujours associées une fois la migration terminée. Appliquer des stratégies directement au projet est un bon moyen de vérifier que les stratégies appropriées sont appliquées à partir du moment où le déplacement est terminé.

Les stratégies Identity and Access Management et les règles d'administration sont héritées via la hiérarchie des ressources et peuvent empêcher un service de fonctionner si elles ne sont pas correctement définies. Déterminez la stratégie en vigueur à la destination du projet dans votre hiérarchie de ressources pour vous assurer qu'elle est adaptée à vos objectifs de gouvernance.

Gérer des clés chiffrées

Vous devez vérifier si votre projet dispose d'une clé chiffrée gérée par le client ou d'un autre service Cloud Key Management Service activé. Les clés cryptographiques appartiennent au projet, et un utilisateur disposant de l'accès owner à ce projet pourra donc gérer et effectuer des opérations de chiffrement sur les clés Cloud KMS de ce projet.

Consultez la page Séparation des tâches pour en savoir plus.

Fonctionnalités en mode bêta

Vous pouvez activer les fonctionnalités bêta sur les organisations, les dossiers ou les projets. Si vous avez activé une fonctionnalité alpha ou bêta sur le projet à déplacer, cette fonctionnalité doit continuer à fonctionner après la migration. Si la fonctionnalité bêta est privée et ne figure pas dans la liste d'autorisation pour l'organisation de destination, vous ne pourrez pas modifier la configuration une fois le déplacement terminé.

Rollback du plan

Si vous constatez qu'un élément ne fonctionne sur aucun des projets que vous avez migrés, vous pouvez le replacer dans son emplacement d'origine. Pour ce faire, vous devez disposer des autorisations IAM nécessaires et définir les règles d'administration requises pour pouvoir exécuter la migration de projet en sens inverse.

Pour obtenir la liste des autorisations requises, consultez la section Attribuer des autorisations. Pour connaître les règles d'administration que vous devez configurer pour autoriser une migration de projet, consultez la page Configurer des règles d'administration.

Dossiers d'importation et d'exportation dédiés

L'héritage des stratégies peut avoir des effets inattendus sur la migration d'un projet, à la fois dans les organisations source et de destination. Vous pouvez réduire ce risque en créant des dossiers spécifiques qui ne contiennent que les projets d'exportation et d'importation, et en veillant à ce que les mêmes stratégies soient héritées par les dossiers des deux organisations. Vous pouvez également définir des autorisations sur ces dossiers qui seront héritées par les projets déplacés dans ces dossiers, ce qui permet d'accélérer le processus de migration des projets.

Lorsque vous planifiez une migration, envisagez d'abord de configurer un dossier source dédié. Pour ce faire, créez un dossier pour chaque organisation vers laquelle vous prévoyez d'exporter les projets. Définissez ensuite une règle d'administration sur ces dossiers, chacun avec la contrainte constraints/resourcemanager.allowedExportDestinations définie sur l'organisation unique vers laquelle vous souhaitez exporter les projets.

Par exemple, vous pouvez configurer des dossiers Export to Marketing Org et Export to Sales Org, chacun avec des contraintes de règle d'administration appropriées.

De même, configurez des dossiers d'importation dédiés dans l'organisation de destination, un pour chaque organisation à partir de laquelle vous souhaitez importer des projets. Pour ce faire, créez un dossier pour chaque organisation à partir de laquelle vous prévoyez d'importer des projets. Définissez ensuite une règle d'administration sur ces dossiers, chacun avec la contrainte constraints/resourcemanager.allowedImportSources définie sur l'organisation unique à partir de laquelle vous souhaitez importer des projets.

Par exemple, vous pouvez configurer les dossiers Import from Marketing Org et Import from App Development Org, chacun avec des contraintes de règles d'administration appropriées.

Dans chacun des dossiers d'importation et d'exportation, attribuez le rôle roles/resourcemanager.projectMover à la personne qui déplacera les projets. Ce rôle sera hérité par tous les projets contenus dans ces dossiers, ce qui permet à l'utilisateur d'effectuer les opérations de déplacement sur n'importe quel projet déplacé dans ces dossiers.

Une fois la migration de votre projet terminée, vous devez supprimer ces dossiers dédiés.

Pour en savoir plus sur la définition des règles d'administration, consultez la section Configurer des règles d'administration.

Attribuer des autorisations

Vous devez disposer des autorisations suivantes pour déplacer un projet entre des organisations.

Pour obtenir ces autorisations, demandez à votre administrateur d'attribuer le rôle suggéré au niveau approprié de la hiérarchie des ressources.

Autorisations de déplacer un projet

Pour déplacer un projet, vous devez disposer des rôles suivants sur le projet, sa ressource parente et la ressource de destination:

  • Administrateur de projet IAM (roles/resourcemanager.projectIamAdmin) sur le projet que vous souhaitez déplacer
  • Déplaceur de projets (roles/resourcemanager.projectMover) sur la ressource parente du projet
  • Si la ressource de destination est un dossier:outil de déplacement de projets (roles/resourcemanager.projectMover) sur la ressource de destination
  • Si la ressource de destination est une organisation:créateur de projet (roles/resourcemanager.projectCreator) sur la ressource de destination

Ces rôles vous donnent les autorisations requises suivantes:

Autorisations requises

  • resourcemanager.projects.getIamPolicy sur le projet que vous souhaitez déplacer
  • resourcemanager.projects.update sur le projet que vous souhaitez déplacer
  • resourcemanager.projects.move sur la ressource parente du projet
  • Si la ressource de destination est un dossier:resourcemanager.projects.move sur la ressource de destination
  • Si la ressource de destination est une organisation:resourcemanager.projects.create sur la ressource de destination

Vous pouvez également obtenir ces autorisations à l'aide d'un rôle personnalisé ou d'autres rôles prédéfinis.

Autorisations des règles d'administration

Au niveau des organisations source et de destination, vous devez disposer du rôle roles/orgpolicy.policyAdmin qui autorise l'autorisation la création et la gestion des règles d'administration.

Configurer des règles d'administration

Pour déplacer une ressource de projet vers une nouvelle organisation, vous devez d'abord appliquer une règle d'administration qui définit les organisations vers lesquelles le projet peut être déplacé. Vous devez également définir une règle d'administration dans la destination qui définit les organisations depuis lesquelles des projets peuvent être importés.

Sur la ressource parente du projet que vous souhaitez déplacer, définissez une règle d'administration qui comprend la contrainte constraints/resourcemanager.allowedExportDestinations. La destination cible sera définie comme un emplacement valide vers lequel vous pourrez migrer le projet.

Sur la ressource de destination, définissez une règle d'administration qui comprend la contrainte constraints/resourcemanager.allowedImportSources. La source sera définie comme un emplacement valide à partir duquel vous pouvez migrer votre projet.

Par exemple, supposons que vous disposiez d'un projet my-test-project qui existait sous une organisation avec l'ID 12345678901 et que vous souhaitiez le déplacer vers une nouvelle organisation pour votre unité commerciale secondaire, avec l'ID 45678901234.

Vous devez définir une règle d'administration sur organizations/12345678901 avec la contrainte constraints/resourcemanager.allowedExportDestinations appliquée et under:organizations/45678901234 défini en tant que allowed_value.

Ensuite, définissez une règle d'administration sur organizations/45678901234 avec la contrainte constraints/resourcemanager.allowedImportSources appliquée et under:organizations/12345678901 défini en tant que allowed_value.

Une fois ces règles d'administration appliquées, vous pourrez déplacer my-test-project de organizations/12345678901 au organizations/45678901234 en supposant que vous disposez des autorisations indiquées dans Attribuer des autorisations.

Modifier le compte de facturation d'un projet

Les comptes Cloud Billing peuvent être utilisés dans toutes les organisations. Le déplacement d'un projet d'une organisation à une autre n'aura pas d'incidence sur la facturation, et les frais continueront à être imputés à l'ancien compte de facturation. Toutefois, les changements d'organisation incluent souvent également l'obligation de passer à un nouveau compte de facturation.

Pour modifier le compte de facturation d'un projet existant, vous devez disposer du rôle roles/owner sur le projet et du rôle roles/billing.admin sur le compte de facturation de destination. Pour modifier le compte de facturation, procédez comme suit :

  1. Accédez à la page Facturation dans Cloud Console.
    Accéder à la page "Facturation"
  2. Cliquez sur le nom du compte de facturation que vous souhaitez modifier.
  3. Dans la section Projets associés à ce compte de facturation, recherchez le nom du projet à déplacer, puis cliquez sur le bouton de menu situé sur la droite.
  4. Cliquez sur Modifier la facturation, puis sélectionnez le nouveau compte de facturation.
  5. Cliquez sur Définir le compte.

Les frais dont vous êtes déjà redevable et qui ne sont pas encore inclus dans l'historique des transactions seront facturés sur l'ancien compte de facturation. Ces frais peuvent correspondre à des opérations effectuées dans les deux jours qui précèdent le transfert du projet.

Déplacer un compte de facturation entre des organisations

Un compte de facturation peut être déplacé d'une organisation à une autre, bien que cette étape ne soit souvent pas nécessaire. La plupart des organisations existantes comportent déjà un compte de facturation qui doit être utilisé à la place. Si vous devez migrer un compte de facturation existant, procédez comme suit :

  1. Obtenez le rôle roles/billing.admin sur les organisations source et de destination.
  2. Accédez à la page Facturation dans Cloud Console.
    Accéder à la page "Facturation"
  3. Cliquez sur le nom du compte de facturation que vous souhaitez déplacer.
  4. En haut de la page Gestion dU compte, cliquez sur Modifier l'organisation.
  5. Sélectionnez l'organisation de destination, puis cliquez sur OK.

Le compte de facturation est maintenant associé à l'organisation spécifiée.

Effectuer la migration

Si vous disposez des autorisations IAM appropriées et que les règles d'administration requises sont appliquées, vous pouvez utiliser l'API Resource Manager pour déplacer une ressource de projet.

gcloud

Pour migrer un projet dans une organisation, exécutez la commande suivante :

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Vous pouvez également spécifier un dossier en tant que ressource cible à l'aide de la commande suivante :

gcloud beta projects move PROJECT_ID \
    --folder FOLDER_ID

Où :

  • PROJECT_ID est l'ID ou le numéro du projet que vous souhaitez migrer.
  • ORGANIZATION_ID est l'ID de l'organisation vers laquelle vous souhaitez déplacer le projet. Vous ne pouvez spécifier qu'une seule cible, soit une organisation, soit un dossier.
  • FOLDER_ID est l'ID du dossier vers lequel vous souhaitez déplacer le projet. Vous ne pouvez spécifier qu'une seule cible, soit un dossier, soit une organisation.

API

À l'aide de l'API Resource Manager v1, vous pouvez déplacer un projet en définissant son champ parent sur l'ID de la ressource de destination.

Pour migrer un projet, procédez comme suit :

  • Récupérez l'objet project à l'aide de la méthode projects.get().
  • Définissez son champ parent sur l'ID de l'organisation ou l'ID du dossier vers lequel vous effectuez le déplacement.
  • Mettez à jour l'objet project à l'aide de la méthode projects.update().

L'extrait de code suivant illustre les étapes ci-dessus :

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

    project = crm.projects().update(
    projectId=flags.projectId, body=project).execute()

Effectuer un rollback d'une migration

Si vous avez déplacé par erreur un projet, vous pouvez effectuer un rollback en exécutant à nouveau le déplacement, l'ancienne source étant la nouvelle destination et l'ancienne destination étant la nouvelle source. Vous devez appliquer les autorisations IAM et les règles d'administration nécessaires pour autoriser cette migration, comme s'il s'agissait d'une migration entièrement nouvelle.

Gérer les cas particuliers

Migrer des projets non associés à une organisation

Vous pouvez migrer un projet qui n'est pas associé à une organisation vers une organisation. Toutefois, vous ne pouvez pas rétablir l'option sur Aucune organisation à l'aide de ce processus. Si votre projet est associé à votre organisation et que vous souhaitez rétablir l'option sur Aucune autorisation, contactez votre conseiller de l'équipe d'assistance pour obtenir de l'aide.

Le processus de migration d'un projet non associé à une organisation est semblable au processus de migration d'un projet entre des organisations, mais ne nécessite pas toutes les étapes du plan de migration. Pour migrer un projet vers une organisation, procédez comme suit :

  1. Vérifiez l'impact sur ce projet des règles dont il héritera.

  2. Si vous le souhaitez, créez un dossier d'importation dédié dans l'organisation de destination.

  3. Attribuez des autorisations Identity and Access Management pour le projet et le parent de destination, comme décrit dans la section Attribuer des autorisations.

  4. Déterminez si vous devez modifier le compte de facturation.

Vous pouvez ensuite effectuer la migration.

Console

Pour effectuer la migration d'un projet vers une organisation, procédez comme suit :

  1. Ouvrez la page IAM et administration > Paramètres dans Cloud Console :

    Ouvrir la page "Paramètres"

  2. Sélectionnez l'outil de sélection de projets en haut de la page.

  3. Dans l'outil de sélection d'organisations, sélectionnez No Organization (Aucune organisation). Si vous n'êtes associé à aucune organisation, l'outil de sélection d'organisations ne s'affiche pas et vous pouvez ignorer cette étape.

  4. Sélectionnez le projet que vous souhaitez migrer.

    Capture d'écran de l'outil de sélection de projets

  5. En haut de la page, cliquez sur Effectuer la migration.

  6. Dans la liste déroulante Organisation, sélectionnez l'organisation vers laquelle vous souhaitez migrer votre projet.

gcloud

Pour migrer un projet dans une organisation, exécutez la commande suivante :

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Où :

  • PROJECT_ID est l'identifiant du projet que vous souhaitez déplacer dans l'organisation.
  • ORGANIZATION_ID est l'identifiant de l'organisation vers laquelle vous souhaitez déplacer le projet.

API

À l'aide de l'API Resource Manager, vous pouvez transférer un projet dans la ressource Organisation en définissant son champ parent sur l'ID de l'organisation.

Pour effectuer la migration d'un projet vers l'organisation, procédez comme suit :

  • Récupérez l'objet project à l'aide de la méthode projects.get().
  • Définissez son champ parent sur l'ID de l'organisation.
  • Mettez à jour l'objet project à l'aide de la méthode projects.update().

Vous ne pouvez pas modifier le champ parent après l'avoir défini.

L'extrait de code suivant illustre les étapes ci-dessus :

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

VPC partagé

Les projets de VPC partagé peuvent être migrés sous certaines conditions. Tout d'abord, un utilisateur disposant du rôle roles/orgpolicy.policyAdmin dans l'organisation source doit définir une règle d'administration contenant la contrainte constraints/resourcemanager.allowEnabledServicesForExport sur le parent du projet à exporter. Cette contrainte doit répertorier SHARED_VPC en tant que allowed_value.

Le projet hôte de VPC partagé doit d'abord être migré, suivi de tous ses projets de service. Nous vous recommandons de faire correspondre les règles de pare-feu entre les organisations aux emplacements source et cible. Vous devriez ainsi minimiser les problèmes potentiels et éviter tout temps d'arrêt pour les projets et le réseau pendant la migration. Nous n'offrons aucune garantie sur l'état de fonctionnement de votre réseau si vous laissez indéfiniment certains projets de service dans l'organisation source lors de la migration d'autres projets.

Si vous déplacez le projet hôte, vous pouvez le replacer dans l'organisation source. Cependant, une fois que vous commencez à déplacer les projets de service, vous devez tous les déplacer avant de pouvoir déplacer à nouveau le projet hôte.

Rôles personnalisés Identity and Access Management

Vous pouvez créer des rôles personnalisés IAM au niveau de l'organisation pour fournir un contrôle précis de l'accès aux ressources. Toutefois ils ne sont valides que dans l'organisation dans laquelle ils sont créés. Si vous essayez de déplacer un projet contenant une liaison de stratégie IAM d'un utilisateur vers un rôle IAM personnalisé au niveau de l'organisation, le déplacement échoue et renvoie une erreur de condition préalable ayant échoué, qui indique que le rôle en question n'existe pas dans l'organisation de destination.

Pour répertorier tous les rôles IAM personnalisés au niveau de votre organisation, exécutez la commande suivante de l'outil de ligne de commande gcloud :

gcloud iam roles list --organization ORGANIZATION_ID

ORGANIZATION_ID correspond à l'ID de l'organisation pour laquelle vous souhaitez répertorier les rôles. Pour savoir comment rechercher votre ID d'organisation, consultez la page Créer et gérer des organisations.

Pour obtenir des informations sur un rôle IAM personnalisé dans votre organisation, exécutez la commande suivante de l'outil de ligne de commande gcloud :

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Où :

  • ORGANIZATION_ID est l'ID de l'organisation parente du rôle.

  • ROLE_ID est le nom du rôle que vous souhaitez décrire.

Pour contourner l'erreur de condition préalable ayant échoué, vous devez créer des rôles personnalisés équivalents au niveau du projet pour chacun des rôles personnalisés au niveau de l'organisation dont le projet hérite. Supprimez ensuite les liaisons de rôles IAM qui font référence aux rôles personnalisés au niveau de l'organisation.

Une fois le projet migré, vous pouvez mettre à jour les stratégies IAM pour qu'elles utilisent les rôles personnalisés au niveau de l'organisation dans l'organisation de destination.

Pour en savoir plus sur les rôles personnalisés, consultez la page Créer et gérer les rôles personnalisés.

Verrou de bucket

Le verrou de bucket Cloud Storage vous permet de configurer une règle de conservation des données sur un bucket Cloud Storage qui régit la durée de conservation des objets du bucket. Le verrou de bucket est protégé par un privilège qui empêche toute suppression accidentelle du projet.

La règles de conservation et le privilège sont conservés avec le projet lors d'une migration. Toutefois, vous devez savoir si vous déplacez un projet avec un verrou de bucket appliqué et éviter les déplacements accidentels.

Périmètres de sécurité de VPC Service Controls

VPC Service Controls permet aux utilisateurs de configurer un périmètre de sécurité basé sur un projet autour de leurs services Google Cloud afin de limiter les risques d'exfiltration de données. Vous ne pouvez pas migrer un projet protégé par un périmètre de sécurité VPC Service Controls.

Pour supprimer un projet d'un périmètre de sécurité, consultez la section Gérer les périmètres de service. Les projets situés dans des périmètres VPC Service Controls ne peuvent pas être déplacés d'une organisation à une autre pendant un délai maximal d'un jour après la création ou la mise à jour d'un périmètre. Une fois supprimé du périmètre de service, il peut s'écouler plusieurs heures avant que le projet ne puisse être déplacé.

Interconnexion dédiée

Nous vous recommandons de migrer les projets comprenant des objets d'interconnexion dédiée et des rattachements de VLAN vers ces objets d'interconnexion dédiée. Bien que les projets avec des objets d'interconnexion dédiée ou des rattachements de VLAN connectés puissent être migrés et fonctionnent entre les organisations, vous ne pouvez pas créer de rattachements de VLAN dans la division de l'organisation.

Les modifications de configuration apportées à un projet d'une organisation qui comporte un objet d'interconnexion dédiée associé ou un rattachement de VLAN à l'objet d'interconnexion dédiée peuvent ne pas se propager à l'autre. Nous vous recommandons donc de ne pas laisser de tels projets trop longtemps répartis sur plusieurs projets dans la mesure du possible.

Interconnexion partenaire

La migration de projets avec l'interconnexion partenaire ne nécessite aucune mesure particulière.

Comptes de service multiprojets

Si vous déplacez un projet auquel un compte de service multiprojet est associé, ce compte de service continuera de fonctionner dans l'organisation de destination. Ce projet continuera à fonctionner avec le compte de service associé, même s'il existe une règle d'administration qui limite le domaine de ce projet.

Si vous déplacez un projet qui possède un compte de service multiprojet associé à un autre projet de l'organisation source, le compte de service continuera de fonctionner dans l'organisation de destination. Toutefois, vous ne pouvez pas utiliser le compte de service sur des ressources auxquelles une règle d'administration de restriction de domaine est appliquée, qui les limitent au domaine de l'organisation source.

Par exemple, supposons que vous disposiez du projet project-A dans les organizations/12345678901. Le serviceAccount-1 est associé à ce projet et configuré en tant que compte de service multiprojet. Les project-B et project-C, également dans organizations/12345678901, utilisent également serviceAccount-1.

Vous avez appliqué une règle d'administration avec la contrainte de restriction de domaine à project-C, ce qui ne lui permet d'accéder qu'au domaine de organizations/12345678901..

Si vous ajoutez serviceAccount-1 à la liaison IAM pour project-C, puis que vous déplacez project-A vers organizations/45678901234, le compte de service fonctionnera.

Si vous déplacez project-A vers organizations/45678901234, puis essayez d'ajouter serviceAccount-1 à la liaison IAM pour project-C, la liaison échoue, car elle enfreint la contrainte de restriction de domaine.

Demandes de support

Si vous déplacez un projet pour lequel une demande d'assistance est en cours, vous devez contacter votre conseiller de l'équipe d'assistance Google pour l'informer de la migration. Les projets pour lesquels une demande d'assistance est en cours auprès de Google ne peuvent pas être consultés tant que l'assistance Google n'a pas mis à jour les métadonnées de la demande afin qu'elles pointent vers la nouvelle organisation.

Si votre projet est configuré pour utiliser un écran d'autorisation OAuth interne et que vous le migrez vers une autre organisation, seuls les membres de l'organisation de destination peuvent autoriser les requêtes. La prise en compte de ce comportement peut prendre jusqu'à 24 heures. En attendant, les membres de l'organisation source peuvent autoriser les requêtes.

Les étapes ci-dessous expliquent comment vous prémunir de la perte d'accès des membres de votre organisation source lors de la migration. Envisagez de créer des utilisateurs dans votre organisation de destination pour les membres de l'organisation afin de ne pas avoir à modifier la configuration de l'écran d'autorisation OAuth.

Pour éviter que les membres de l'organisation source perdent leur accès, procédez comme suit :

  1. Mettez à jour l'écran d'autorisation OAuth pour qu'il soit externe, et non interne.

  2. Les applications marquées comme internes et utilisant des données sensibles n'ont pas besoin de demander la validation de leur application. Si l'application utilise des données sensibles, lors de la mise à jour de l'écran d'autorisation en externe, les utilisateurs de l'organisation source verront un écran d'application non validé avant l'écran d'autorisation. Pour éviter cela, demandez la validation des applications pour l'utilisation de champs d'application sensibles ou restreints.

OS Login

Si le service OS Login est activé dans votre projet source, attribuez le rôle IAM roles/compute.osLoginExternalUser aux comptes principaux qui ont accès au projet source, dans l'organisation de destination, afin d'éviter que ces comptes principaux ne perdent l'accès.

Rattacher des comptes de service à des ressources

Pour la plupart des services Google Cloud, les utilisateurs ont besoin de l'autorisation iam.serviceAccounts.actAs sur un compte de service pour rattacher ce compte de service à une ressource. Auparavant, pour faciliter l'intégration, certains services permettaient aux utilisateurs d'associer des comptes de service aux ressources, même s'ils n'étaient pas autorisés à emprunter l'identité des comptes de service. Cette opération est décrite ici.

Si l'organisation source d'un client applique l'ancien comportement (l'association de comptes de service est possible sans l'attribution de rôle normale) et si l'organisation de destination ne l'autorise pas, attribuez l'autorisation roles/iam.serviceAccountUser aux utilisateurs qui associent ces comptes de service aux ressources. Pour en savoir plus sur l'emprunt d'identité des comptes de service, consultez la section Emprunter l'identité d'un compte de service.

Pour savoir si votre organisation applique l'ancien comportement, procédez comme suit :

  1. Dans Cloud Console, accédez à la page Règles d'administration.

    Accéder à la page "Règles d'administration"

  2. Dans le sélecteur de projet en haut de la page, sélectionnez l'organisation dont vous souhaitez vérifier l'ancien état.

  3. Dans la zone de filtre située en haut de la liste des règles d'administration, saisissez constraints/appengine.enforceServiceAccountActAsCheck.

  4. Si la règle d'administration appengine.enforceServiceAccountActAsCheck apparaît dans la liste, l'organisation applique l'ancien comportement.

  5. Répétez les étapes 3 et 4 pour chacune des contraintes c de règle d'organisation suivantes :

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck
  6. Si l'une de ces contraintes de règle d'administration apparaît, votre organisation utilise l'ancien comportement.

Si l'organisation source utilise l'ancien comportement, mais pas l'organisation de destination, attribuez les rôles comme indiqué ci-dessus. Si les organisations source et de destination utilisent l'ancien comportement, aucune action n'est requise. Vous devez toutefois envisager d'appliquer la règle pour éviter toute tentative d'emprunt d'identité accidentelle.