Migrer des projets entre des ressources d'organisation

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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

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

Vous pouvez utiliser l'API Resource Manager pour déplacer des projets sur plusieurs ressources de l'organisation 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, en replaçant 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 directes à la configuration du projet, la modification de la hiérarchie des ressources est susceptible d'affecter la fonction du projet et 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.

Le déplacement de votre projet peut également entraîner des cas de non-respect des règles d'administration, selon les règles d'administration de la ressource de l'organisation de destination.

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 d'aperçu sur les ressources "Organisation", "Dossier" ou "Projet". Si vous avez activé le transfert d'une fonctionnalité alpha ou bêta sur le projet, cette fonctionnalité devrait continuer à fonctionner après la migration. Si la fonctionnalité d'aperçu est privée et n'a pas été ajoutée à la liste d'autorisation pour la ressource 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 règles peut avoir des effets inattendus lorsque vous migrez un projet, à la fois dans les ressources d'organisation source et de destination. Vous pouvez atténuer ce risque en créant des dossiers spécifiques pour ne conserver que les projets d'exportation et d'importation, et en vous assurant que les mêmes stratégies sont héritées par les dossiers des deux ressources d'organisation. Vous pouvez également définir des autorisations sur ces dossiers, qui hériteront des projets déplacés dans ces dossiers, afin 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 ressource d'organisation vers laquelle vous souhaitez exporter des projets. Définissez ensuite une règle d'administration sur ces dossiers, chacun avec la contrainte constraints/resourcemanager.allowedExportDestinations définie sur la ressource d'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 la ressource de l'organisation de destination, un pour chaque ressource d'organisation à partir de laquelle vous souhaitez importer des projets. Pour ce faire, créez un dossier pour chaque ressource d'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 la ressource d'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 d'une ressource d'organisation à une autre.

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 dans le projet, sa ressource parente et la ressource de destination :

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

Ces rôles vous donnent les autorisations requises suivantes :

Autorisations requises

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

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

Autorisations des règles d'administration

Pour les ressources d'organisation source et de destination, l'utilisateur qui définit les règles d'administration doit disposer du rôle roles/orgpolicy.policyAdmin, qui permet de créer et de gérer des règles d'administration.

Autorisations du compte de facturation

Les comptes de facturation Cloud peuvent être utilisés dans toutes les ressources de l'organisation. Le transfert d'un projet d'une ressource d'organisation à une autre n'a aucune incidence sur la facturation. Les frais continuent d'être appliqués à l'ancien compte de facturation. Toutefois, les déplacements de ressources d'organisation incluent souvent une exigence de déplacement vers un nouveau compte de facturation.

Pour obtenir les autorisations nécessaires pour modifier le compte de facturation du projet, demandez à votre administrateur de vous accorder les rôles IAM suivants:

  • Utilisateur de compte de facturation (roles/billing.user) sur le compte de facturation de destination
  • Gestionnaire de la facturation du projet (roles/billing.projectManager)

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Ces rôles prédéfinis contiennent les autorisations requises pour modifier le compte de facturation du projet. Pour afficher les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

  • billing.resourceAssociations.create sur le compte de facturation de destination
  • resourcemanager.projects.createBillingAssignment sur le projet
  • resourcemanager.projects.deleteBillingAssignment sur le projet

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Configurer des règles d'administration

Pour déplacer une ressource de projet vers une nouvelle ressource d'organisation, vous devez d'abord appliquer une règle d'administration qui définit les ressources d'organisation 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 ressources d'organisation à partir desquelles les 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 existe sous une ressource Organisation avec l'ID 12345678901, et que vous souhaitez le déplacer vers une nouvelle ressource 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 de facturation Cloud peuvent être utilisés dans toutes les ressources de l'organisation. Le transfert d'un projet d'une ressource d'organisation à une autre n'a aucune incidence sur la facturation. Les frais continuent d'être appliqués à l'ancien compte de facturation. Toutefois, les déplacements de ressources d'organisation incluent souvent une exigence de déplacement vers un nouveau compte de facturation.

Pour modifier le compte de facturation, procédez comme suit:

  1. Accédez à la page Facturation dans Google 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 d'une ressource Organisation à une autre

Un compte de facturation peut être déplacé d'une ressource d'organisation à une autre, bien que cette étape ne soit souvent pas nécessaire. La plupart des ressources d'organisation existantes sont déjà associées à un compte de facturation. Si vous devez migrer un compte de facturation existant:

  1. Obtenez le rôle roles/billing.admin sur les ressources de l'organisation source et de destination, et le rôle roles/billing.creator sur la ressource de l'organisation de destination.
  2. Accédez à la page Facturation dans Google 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 la ressource Organisation de destination, puis cliquez sur OK.

Le compte de facturation est désormais associé à la ressource 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 vers une autre ressource d'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 la ressource d'organisation vers laquelle vous souhaitez déplacer le projet. Vous ne pouvez spécifier qu'une seule cible, à savoir une ressource "Organisation" ou 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, à savoir un dossier ou une ressource d'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:

  • Récupérez l'objet project à l'aide de la méthode projects.get().
  • Définissez son champ parent sur l'ID de ressource d'organisation de la ressource d'organisation ou sur l'ID de dossier du dossier vers lequel vous le déplacez.
  • 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 disposer des autorisations IAM et des règles d'administration nécessaires pour pouvoir effectuer cette opération comme s'il s'agissait d'une migration entièrement nouvelle.

Gérer les cas particuliers

Migrer des projets sans ressource d'organisation

Vous pouvez migrer un projet qui n'est pas associé à une ressource Organisation vers une ressource Organisation. Toutefois, vous ne pouvez pas revenir à Aucune organisation à l'aide de ce processus. Si un projet est associé à votre ressource Organisation et que vous souhaitez rétablir l'option Aucune organisation, contactez votre représentant de l'assistance pour obtenir de l'aide.

Le processus de migration d'un projet non associé à une ressource Organisation est semblable à celui permettant de migrer un projet entre des ressources Organisation, mais ne nécessite pas toutes les étapes du plan de migration. Pour migrer un projet vers une ressource d'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 la ressource de 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 migrer un projet vers une ressource Organisation:

  1. Ouvrez la page IAM et administration > Paramètres dans la console Google Cloud.

    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 ressource d'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 la ressource d'organisation vers laquelle vous souhaitez migrer votre projet.

gcloud

Pour migrer un projet vers une ressource Organisation, exécutez la commande suivante:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Où :

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

API

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

Pour migrer un projet vers la ressource Organisation:

  • Récupérez l'objet project à l'aide de la méthode projects.get().
  • Définissez son champ parent sur l'ID de ressource 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

Des rôles de Identity and Access Management personnalisés peuvent être créés au niveau de l'organisation pour fournir un contrôle précis de l'accès aux ressources. Cependant, ils ne sont valides que dans la ressource d'organisation dans laquelle ils sont créés. Si vous essayez de déplacer un projet contenant la liaison de stratégie IAM d'un utilisateur vers un rôle IAM personnalisé au niveau de l'organisation, le déplacement échoue et une erreur de condition préalable échouee, ce qui explique que le rôle en question n'existe pas dans la ressource d'organisation de destination.

Pour répertorier tous les rôles IAM personnalisés au niveau de votre ressource Organisation, exécutez la commande Google Cloud CLI suivante:

gcloud iam roles list --organization ORGANIZATION_ID

Où ORGANIZATION_ID correspond à l'ID de ressource Organisation pour lequel vous souhaitez répertorier les rôles. Pour savoir comment trouver l'ID de ressource de votre organisation, consultez Créer et gérer des ressources Organisation.

Pour obtenir des informations sur un rôle Identity and Access Management personnalisé dans votre ressource d'organisation, exécutez la commande Google Cloud CLI suivante:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Où :

  • ORGANIZATION_ID est l'ID de ressource d'organisation de la ressource d'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 utiliser les rôles personnalisés au niveau de l'organisation dans la ressource de 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. Le déplacement de projets situés dans des périmètres VPC Service Controls ne peut pas être bloqué entre les ressources de l'organisation pendant une journée suivant la création ou la mise à jour d'un périmètre. Une fois le projet supprimé du périmètre de service, plusieurs heures peuvent s'écouler avant que le projet soit 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 ressources de l'organisation, vous ne pouvez pas créer de rattachements de VLAN pour l'ensemble de la répartition des ressources de l'organisation.

Les modifications de configuration apportées à un projet dans une ressource d'organisation associée à un objet d'interconnexion dédiée ou à un rattachement de VLAN peuvent ne pas se propager à l'autre. Nous vous recommandons donc de ne pas laisser ces projets divisés entre les ressources de l'organisation aussi longtemps que 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 lui est associé, ce compte de service continuera de fonctionner dans la ressource d'organisation de destination. Ce projet continue de fonctionner avec le compte de service associé même si une règle d'administration restreint le domaine de ce projet.

Si vous déplacez un projet possédant un compte de service multiprojet associé à un autre projet de la ressource d'organisation source, le compte de service continuera de fonctionner dans la ressource d'organisation de destination. Toutefois, vous ne pourrez pas utiliser le compte de service sur des ressources auxquelles une règle d'administration de restriction de domaine est appliquée qui les restreint au domaine de la ressource d'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 seront pas en mesure de les consulter tant que l'assistance Google n'aura pas mis à jour les métadonnées de la demande pour qu'elles pointent vers la nouvelle ressource d'organisation.

Si votre projet est configuré pour utiliser un écran de consentement OAuth interne et que vous le migrez vers une autre ressource d'organisation, seuls les membres de la ressource d'organisation de destination peuvent autoriser les requêtes. Un délai maximal de 24 heures peut être nécessaire pour que ce comportement soit appliqué. En attendant, les membres de la ressource d'organisation source envoient une demande d'autorisation.

Les étapes ci-dessous expliquent comment vous assurer que les membres de la ressource d'organisation source ne perdent pas l'accès pendant la migration. Envisagez de créer des utilisateurs dans la ressource Organisation de destination pour les membres de la ressource Organisation, afin de ne pas avoir à modifier la configuration de l'écran d'autorisation OAuth.

Pour éviter de perdre l'accès des membres de la ressource d'organisation source:

  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, une fois l'écran d'autorisation passé à "externe", les utilisateurs de la ressource d'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 la connexion au système d'exploitation est activée dans votre projet source, attribuez le rôle IAM roles/compute.osLoginExternalUser aux comptes principaux qui peuvent accéder au projet source dans la ressource 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 la ressource d'organisation source d'un client a l'ancien comportement (l'association de comptes de service est possible sans l'attribution de rôle normale) et non la ressource d'organisation de destination, accordez roles/iam.serviceAccountUser aux utilisateurs qui associent ces comptes de service à des ressources. Pour en savoir plus sur l'usurpation d'identité des comptes de service, consultez la section Usurpation d'identité d'un compte de service.

Pour voir si votre ressource Organisation a l'ancien comportement, procédez comme suit:

  1. Dans la console Google Cloud, 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, choisissez la ressource d'organisation pour laquelle 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, cela signifie que la ressource Organisation a l'ancien comportement.

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

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck

  6. Si l'une de ces contraintes de règle d'administration apparaît, votre ressource d'organisation utilise l'ancien comportement.

Si la ressource d'organisation source a l'ancien comportement, mais pas la destination, accordez les rôles indiqués ci-dessus. Si les ressources de l'organisation source et de destination ont l'ancien comportement, aucune action n'est requise, mais envisagez d'appliquer la règle pour éviter toute usurpation d'identité involontaire.

Migrer des projets avec Analytics Hub

Si vous migrez le projet qui utilise Analytics Hub vers une autre ressource d'organisation, vous pouvez rencontrer une erreur. Pour résoudre les erreurs, contactez l'assistance.

Migrer des projets avec le service de sauvegarde et de reprise après sinistre

Les projets qui utilisent le service de sauvegarde et de reprise après sinistre ne doivent pas être migrés vers une autre organisation.