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 de projet est l'entité d'organisation de base dans une organisation Google Cloud. Les projets sont créés sous des organisations et peuvent être placés sous 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 à un autre emplacement de la hiérarchie des ressources de son organisation actuelle. L'API Resource Manager vous permet également d'effectuer un rollback de la migration, en déplaçant le projet à son emplacement initial dans la hiérarchie des ressources.

Créer un plan de migration

Le plus important à prendre en compte lors du déplacement du 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 au sein du 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 règles Identity and Access Management ou les règles d'administration, ne seront 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 autres services pouvant être affectés par le déplacement, ou par la hiérarchie des ressources dans la destination de votre projet. (Installation de Python groupée).

Présentation de l'inventaire

Utilisez Cloud Asset Inventory pour créer une vue d'ensemble des ressources utilisées, y compris les stratégies de gestion de l'authentification et des accès. Vous pouvez utiliser cette présentation pour vous guider dans la planification de votre 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 de données au format JSON. Pour en savoir plus sur l'exportation de ces données, consultez la page Exporter vers BigQuery.

Vérification du respect des règles

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 appliquées à 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 règles de gestion de l'authentification et des accès et des règles d'administration sont héritées à travers la hiérarchie des ressources et peuvent empêcher un service de fonctionner correctement s'il n'est pas correctement défini. 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 les 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 activé. Les clés cryptographiques appartiennent au projet, et un utilisateur ayant un accès owner à ce projet peut donc gérer et effectuer des opérations de chiffrement sur les clés dans Cloud KMS de ce projet.

Pour en savoir plus, consultez la section Séparation des tâches.

Fonctionnalités de prévisualisation

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

Rollback du plan

Si vous constatez qu'un projet que vous avez migré ne fonctionne pas, 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 exécuter la migration du 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 à configurer pour autoriser la migration d'un projet, consultez la page Configurer les règles d'administration.

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

L'héritage des stratégies peut provoquer des effets inattendus lors de la migration d'un projet, à la fois dans les organisations source et de destination. Vous pouvez limiter ce risque en créant des dossiers spécifiques qui ne contiennent que des 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 aux projets qu'ils contiennent, 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 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 des 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é de tous les projets contenus dans ces dossiers, ce qui permet à l'utilisateur d'effectuer les opérations de déplacement sur tout 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 organisation à une autre.

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

Autorisations de déplacement de projets

Pour la ressource du projet que vous souhaitez déplacer et sa ressource parente, vous devez disposer du rôle Déplaceur de projets (roles/resourcemanager.projectMover) ou d'un autre rôle comprenant les autorisations suivantes pour l'API Resource Manager v1:

  • Autorisation requise pour la ressource que vous déplacez:

    • resourcemanager.projects.update
  • Autorisation requise pour la ressource parente:

    • resourcemanager.projects.move

Sur la ressource de destination, l'autorisation dont vous avez besoin dépend de la ressource vers laquelle vous déplacez le projet.

  • Si la ressource de destination est un dossier, vous devez disposer du rôle Déplaceur de projets (roles/resourcemanager.projectMover) ou d'un autre rôle comprenant l'autorisation resourcemanager.projects.move.

  • Si la ressource de destination est une organisation, vous devez disposer du rôle Créateur de projet (roles/resourcemanager.projectCreator) ou d'un autre rôle comprenant les autorisations resourcemanager.projects.create.

Autorisations des règles d'administration

Pour les organisations source et de destination, vous devez disposer du rôle roles/orgpolicy.policyAdmin, qui accorde l'autorisation de créer et de gérer 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 dans la destination une règle d'administration 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 incluant la contrainte constraints/resourcemanager.allowedExportDestinations. Cela définira la destination cible comme un emplacement valide vers lequel vous pourrez migrer le projet.

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

Par exemple, supposons que vous ayez 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éplacermy-test-project Deorganizations/12345678901 à organizations/45678901234, en supposant que vous disposiez des autorisations décrites dans Attribuer des autorisations (Installation de Python groupée).

Modifier le compte de facturation d'un projet

Les comptes de facturation Cloud peuvent être utilisés dans plusieurs organisations. Le transfert d'un projet d'une organisation à une autre n'a aucune incidence sur la facturation. Les frais continueront d'être appliqués à l'ancien compte de facturation. Cependant, le déplacement d'une organisation inclut souvent 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 pas souvent nécessaire. La plupart des organisations existantes disposeront déjà d'un compte de facturation à utiliser à 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 désormais 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. (Installation de Python groupée).

gcloud

Pour migrer un projet d'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 correspond à l'ID ou au numéro du projet que vous souhaitez migrer.
  • ORGANIZATION_ID correspond à l'ID de l'organisation vers laquelle vous souhaitez déplacer le projet. Vous ne pouvez spécifier qu'une seule cible : une organisation ou un dossier.
  • FOLDER_ID correspond à l'ID du dossier dans lequel vous souhaitez déplacer le projet. Vous ne pouvez spécifier qu'une seule cible : un dossier ou une organisation.

API

À l'aide de l'API v1 de Resource Manager, vous pouvez déplacer un projet en définissant son champ parent sur l'ID de 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 sur l'ID 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 migré par erreur un projet, vous pouvez effectuer un rollback de l'opération en relançant l'opération, avec l'ancienne source comme nouvelle destination et l'ancienne destination comme nouvelle source. Vous devez disposer des autorisations IAM et des règles d'administration nécessaires pour autoriser cette opération 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. Cependant, vous ne pouvez pas redéfinir le paramètre sur Aucune organisation en suivant ce processus. Si votre projet est associé à votre 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 organisation est semblable au processus de migration d'un projet entre 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 le sélecteur d'organisation, sélectionnez Aucune organisation. Si vous n'êtes associé à aucune organisation, le sélecteur d'organisation n'apparaît 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, ce qui devrait minimiser les problèmes potentiels et éviter tout temps d'arrêt au niveau des projets et du réseau pendant la migration. Nous n'offrons aucune garantie quant à l'état de votre réseau si vous laissez certains projets de service de l'organisation source indéfiniment pendant la migration d'autres projets.

Si vous déplacez le projet hôte, vous pouvez le replacer dans l'organisation source. Toutefois, 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 de gestion de l'authentification et des accès personnalisés

Les rôles IAM personnalisés peuvent être créés 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 tentez 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 génère une erreur de condition préalable qui indique que le rôle en question est erroné. 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 est l'ID de l'organisation pour lequel vous souhaitez répertorier les rôles. Pour savoir comment trouver votre ID d'organisation, consultez la page Créer et gérer des organisations.

Pour obtenir des informations sur un rôle de gestion de l'authentification et des accès 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 d'organisation 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 qui a é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 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 du bucket est protégé par un privilège qui empêche toute suppression accidentelle du projet.

La règle 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 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 des 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 page Gérer les périmètres de service. Les projets des périmètres VPC Service Controls ne peuvent pas être bloqués d'une organisation à l'autre pendant un jour au maximum après leur création ou leur mise à jour. 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 peuvent ê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 à laquelle un objet d'interconnexion dédiée est 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 répartis sur plusieurs projets aussi longtemps que possible.

Interconnexion partenaire

Aucune considération particulière n'est requise pour la migration de projets avec l'interconnexion partenaire.

Assured Workloads

Vous ne pouvez pas déplacer un projet Assured Workloads entre plusieurs organisations. Toute tentative de désactivation sera bloquée par programmation.

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 si une règle d'administration 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, ce qui les limite au domaine de l'organisation source.

Par exemple, supposons que vous ayez project-A dans organizations/12345678901. serviceAccount-1 est associé à ce projet, qui est configuré en tant que compte de service multiprojet. 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 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 représentant de l'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 modifié 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 garantir 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 de perdre l'accès aux membres de l'organisation source:

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

  2. Les applications marquées comme internes et qui utilisent des données sensibles n'ont pas besoin de demander la validation de l'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 le écran d'autorisation. Pour éviter cela, demandez la validation de l'application 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 membres du projet source au sein de l'organisation de destination pour éviter ces membres. perdre 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. Cependant, pour simplifier l'intégration, certains utilisateurs ont pu associer des comptes de service à des ressources par le passé, même s'ils n'étaient pas autorisés à emprunter l'identité des comptes de service. Cette opération est indiquée ici.

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

Pour vérifier si votre organisation adopte 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, choisissez 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 présente l'ancien comportement.

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

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

Si l'organisation source présente l'ancien comportement, mais que la destination ne l'est pas, attribuez les rôles comme indiqué ci-dessus. Si les organisations 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é accidentelle.