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 d'une organisation Google Cloud. Les projets sont créés sous des organisations et peuvent être placés dans des dossiers ou la ressource Organisation proprement dite, formant ainsi la hiérarchie des ressources. Vous devrez peut-être migrer vos projets entre organisations en raison d'acquisitions, de exigences réglementaires et de séparation entre les différentes unités commerciales, entre autres.

L'API Resource Manager vous permet de déplacer des projets entre plusieurs organisations 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 replaceant le projet à son emplacement d'origine dans la hiérarchie des ressources.

Créer un plan de migration

Lors de la migration d'un projet, le plus important est de déterminer 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 sous celle-ci comme une seule unité. Cela 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 sur ses services en cours d'exécution. Les stratégies héritées, telles que les règles de gestion de l'authentification et des accès ou les règles d'administration, ne sont pas transférées avec le projet pendant la migration, mais uniquement avec les stratégies et les comptes de service associés directement à la ressource. Cela peut provoquer un comportement inattendu une fois la migration terminée.

Avant de déplacer votre projet, nous vous recommandons de créer un plan de migration pour déterminer l'état 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 dans votre projet et de tous les autres services susceptibles d'être affectés par le déplacement ou par la hiérarchie des ressources dans la destination de votre projet. s'affiche en haut de l'écran.

Présentation de l'inventaire

Utilisez l'inventaire des éléments cloud pour obtenir un aperçu des ressources utilisées, y compris les stratégies de gestion de l'authentification et des accès. Cette présentation peut vous aider à établir votre plan de migration.

Vous pouvez également utiliser Cloud Asset Inventory pour transférer ces données dans BigQuery. Cela vous permettra d'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 des données vers BigQuery.

Vérification du respect des règles

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

Toute stratégie appliquée directement au projet sera toujours associée une fois la migration terminée. L'application directe des règles au projet est un bon moyen de vérifier que les règles appropriées sont appliquées dès que la migration est terminée.

Les règles de gestion de l'authentification et des accès et les règles d'administration sont héritées par la hiérarchie de ressources et peuvent empêcher le service de fonctionner correctement. Déterminez la stratégie en vigueur dans la destination du projet dans votre hiérarchie de ressources pour vous assurer que cette stratégie 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 Service. Les clés de chiffrement appartiennent au projet, et un utilisateur disposant d'un accès owner à ce projet pourra donc gérer des clés cryptographiques dans ce projet et y effectuer des opérations de chiffrement.

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

Fonctionnalités d'aperçu

Vous pouvez activer les fonctionnalités de prévisualisation sur les organisations, les dossiers ou les projets. Si vous avez activé une fonctionnalité alpha ou bêta sur le projet à déplacer, celle-ci devrait continuer à fonctionner après la migration. Si la fonctionnalité d'aperçu est privée et n'est pas autorisée pour l'organisation de destination, vous ne pourrez plus modifier la configuration une fois le déplacement terminé.

Effectuer un rollback

Si vous constatez qu'un élément ne fonctionne pas sur les projets que vous avez migrés, vous pouvez les replacer dans leur emplacement d'origine. Pour ce faire, vous devez disposer des autorisations IAM nécessaires et définir les stratégies d'administration requises pour pouvoir effectuer cette migration inverse.

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

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

L'héritage des stratégies peut entraîner des effets inattendus lorsque vous migrez un projet, à la fois dans les organisations source et de destination. Vous pouvez atténuer ce risque en créant des dossiers spécifiques qui ne contiennent que des projets d'exportation et d'importation, et vous assurer que les mêmes stratégies sont héritées par les dossiers des deux organisations. Vous pouvez également définir des autorisations pour ces dossiers qui seront hérités des projets déplacés dans le dossier afin d'accélérer le processus de migration.

Lors de la planification d'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 des projets. Ensuite, définissez une règle d'administration pour ces dossiers, chacun avec la contrainte constraints/resourcemanager.allowedExportDestinations définie sur la seule organisation vers laquelle vous souhaitez exporter des projets.

Par exemple, vous pouvez configurer les dossiers Export to Marketing Org et Export to Sales Org, chacun avec des contraintes de règles d'administration adapté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 duquel vous prévoyez d'importer des projets. Ensuite, définissez une règle d'administration pour ces dossiers, chacun avec la contrainte constraints/resourcemanager.allowedImportSources définie sur la seule organisation à 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 adaptées.

Sur chacun des dossiers d'importation et d'exportation, attribuez à la personne qui va déplacer le projet roles/resourcemanager.projectMover. Ce rôle sera hérité de tous les projets contenus dans ces dossiers, ce qui permettra à l'utilisateur d'effectuer les opérations de déplacement sur tous les projets déplacés 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'attribuer le rôle suggéré au niveau approprié de la hiérarchie des ressources.

Autorisations de déplacement de projet

Sur la ressource de projet que vous souhaitez déplacer et sa ressource parente, vous avez besoin du rôle Déplaceur de projets (roles/resourcemanager.projectMover) ou d'un autre rôle qui inclut 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 incluant l'autorisation resourcemanager.projects.move.

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

Autorisations des règles d'administration

Sur les organisations source et de destination, vous devez disposer du rôle roles/orgpolicy.policyAdmin, qui permet 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éfinira 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 à 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 incluant la contrainte constraints/resourcemanager.allowedExportDestinations. La destination cible est définie comme un emplacement valide vers lequel vous pouvez migrer le projet.

Sur la ressource de destination, définissez une règle d'administration incluant la contrainte constraints/resourcemanager.allowedImportSources. Cela définira la source en tant qu'emplacement valide à partir duquel vous pourrez migrer votre projet.

Par exemple, supposons que vous ayez un projet my-test-project qui existe dans 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 définissez des règles 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 comme allowed_value.

Une fois ces règles d'administration appliquées, vous pourrez déplacermy-test-project à partir deorganizations/12345678901 à organizations/45678901234, en supposant que les autorisations indiquées dans Attribuer des autorisations s'affiche en haut de l'écran.

Modifier le compte de facturation d'un projet

Les comptes de facturation Cloud peuvent être utilisés dans différentes organisations. Le déplacement d'un projet d'une organisation à une autre n'a aucune incidence sur la facturation. Les frais continuent donc à être facturés sur l'ancien compte de facturation. Toutefois, les migrations d'organisations incluent souvent également l'obligation de passer à un nouveau compte de facturation.

Pour modifier le compte de facturation d'un projet existant, vous devez avoir le rôle roles/owner sur le projet et le 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 disposent déjà d'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 les autorisations nécessaires à la migration :
    1. roles/billing.admin sur l'organisation source
    2. roles/billing.creator sur l'organisation 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 Présentation, 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. s'affiche en haut de l'écran.

gcloud

Pour migrer un projet sous 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 : une organisation ou un dossier.
  • FOLDER_ID correspond à l'identifiant du dossier vers 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 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 le champ parent sur l'ID de l'organisation ou l'ID de dossier associé au dossier dans 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 de la migration

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

Traiter 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 redéfinir la sélection sur Aucune organisation en utilisant ce processus. Si vous avez un projet associé à votre organisation et que vous souhaitez revenir à l'état Aucune organisation, contactez votre représentant de l'assistance.

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

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

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

  3. Attribuez des autorisations de gestion de l'authentification et des accès au projet et au parent de destination, comme indiqué 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é, puis tous ses projets de service. Nous vous recommandons d'associer les règles de pare-feu entre les organisations des emplacements source et cible, ce qui devrait minimiser les problèmes potentiels et éviter les temps d'arrêt des projets et du réseau pendant la migration. Nous n'offrons pas de garantie quant à l'état de votre réseau si vous quittez certains projets de service de l'organisation source pendant la migration des autres.

Si vous déplacez le projet hôte, vous pouvez le replacer dans l'organisation source. Une fois que vous avez commencé à déplacer les projets de service, vous devez les déplacer pour pouvoir déplacer à nouveau le projet hôte.

Rôles de gestion de l'authentification et des accès personnalisés

Les rôles de gestion de l'authentification et des accès personnalisés peuvent être créés au niveau de l'organisation pour permettre un contrôle précis sur l'accès aux ressources, mais 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 à un rôle IAM personnalisé au niveau de l'organisation, la migration échouera et renvoie une erreur de condition préalable non remplie, expliquant 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 de l'outil de ligne de commande gcloud suivante:

gcloud iam roles list --organization ORGANIZATION_ID

ORGANIZATION_ID correspond à l'ID d'organisation pour lequel vous souhaitez répertorier les rôles. Pour en savoir plus sur la recherche de l'ID de votre organisation, consultez la section Créer et gérer des organisations.

Pour obtenir des informations sur un rôle personnalisé de gestion de l'authentification et des accès dans votre organisation, exécutez la commande de l'outil de ligne de commande gcloud suivante:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Où :

  • ORGANIZATION_ID correspond à 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 ayant échoué, vous devez créer des rôles personnalisés équivalents au niveau du projet pour chacun des rôles personnalisés définis au niveau de l'organisation que 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 verrouillage du 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 dans le bucket. Le verrou de bucket est protégé à l'aide d'un privilège pour empêcher toute suppression accidentelle du projet.

Les règles de conservation et les privilèges sont conservés dans le projet lors d'une migration, mais vous devez savoir si vous déplacez un projet avec un verrou de bucket appliqué et éviter les migrations accidentelles.

Périmètres de sécurité 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 section Gérer les périmètres de service. Il est possible que les projets des périmètres VPC Service Controls ne puissent pas être déplacés vers une organisation pendant une journée, après leur création ou leur mise à jour. Plusieurs heures peuvent être nécessaires pour que le projet soit déplacé après qu'il a été supprimé du périmètre de service.

CDN Interconnect

Nous vous recommandons de migrer les projets avec des objets CDN Interconnect et des projets avec des rattachements de VLAN à ces objets CDN Interconnect. Même si les projets avec des objets CDN Interconnect 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 dans une organisation et auxquelles un objet CDN Interconnect est associé ou un rattachement de VLAN à l'objet CDN Interconnect peuvent ne pas se propager dans l'autre. Nous vous recommandons donc de ne pas répartir ces projets sur l'autre si possible.

Assured Workloads

Vous ne pouvez pas déplacer un projet de charges de travail Assured Workloads entre des organisations. Toute tentative de blocage sera bloquée de façon programmatique.

Comptes de service multiprojets

Si vous déplacez un projet auquel un compte de service inter-projets 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 restreint le domaine de ce projet.

Si vous déplacez un projet propriétaire d'un compte de service inter-projets associé à un autre projet de l'organisation source, le compte de service fonctionnera toujours dans l'organisation de destination. Toutefois, vous ne pourrez pas utiliser le compte de service sur les ressources auxquelles une règle d'administration relative à la 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. Un projet serviceAccount-1 est associé à ce projet, qui est configuré en tant que compte de service inter-projets. project-B et project-C, y compris dans organizations/12345678901, utilisent également serviceAccount-1.

Vous avez appliqué une règle d'administration avec la contrainte de restriction de domaine à project-C, qui ne lui permet d'accéder qu'au domaine 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 fonctionne.

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

Demandes de support

Si vous déplacez un projet ayant une demande d'assistance ouverte, vous devez vous rapprocher de votre contact au sein de l'assistance Google pour l'informer que la migration s'est produite. Les projets ayant fait l'objet d'une demande d'assistance auprès de Google ne peuvent pas les afficher tant que l'assistance Google n'a pas mis à jour les métadonnées de la demande pour pointer 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.

Procédez comme suit pour vous assurer que les membres de votre organisation source ne perdent pas l'accès lors de la migration. Pensez à 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 toute perte d'accès pour les membres de l'organisation source:

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

  2. Les applications marquées en interne et qui utilisent des données sensibles n'ont pas besoin d'être soumises à la validation d'application. Si l'application utilise des données sensibles, alors l'écran d'autorisation devient externe, les utilisateurs de l'organisation source voient un écran d'application non validé avant l'application. Pour éviter cela, demandez une validation de l'application pour l'utilisation de champs d'application sensibles ou restreints.

OS Login

Si OS Login est activé dans votre projet source, attribuez le rôle IAM roles/compute.osLoginExternalUser aux membres du projet source dans l'organisation de destination afin d'éviter ces membres. en perdant l'accès.

Rattacher des comptes de service à des ressources

Pour la plupart des services Google Cloud, les utilisateurs doivent disposer de l'autorisation iam.serviceAccounts.actAs sur un compte de service pour associer ce compte de service à une ressource. Toutefois, auparavant, pour faciliter l'intégration de certains services, les utilisateurs pouvaient associer des comptes de service aux ressources, même si ces derniers n'avaient pas l'autorisation d'emprunter l'identité des comptes de service. Pour en savoir plus, cliquez ici.

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

Pour savoir si votre organisation a le comportement hérité, 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 pour laquelle vous souhaitez vérifier l'é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'ancien comportement est appliqué à l'organisation.

  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, l'organisation utilise l'ancien comportement.

Si l'ancien comportement est défini pour l'organisation source et que la destination n'a pas d'incidence sur les destinations, attribuez les rôles indiqués ci-dessus. Si les organisations source et de destination ont à la fois l'ancien comportement, aucune action de votre part n'est requise, mais pensez à appliquer la stratégie pour éviter l'usurpation d'identité involontaire.