Gérer les cas particuliers

Découvrez comment gérer les cas particuliers lorsque vous migrez des projets. Avant de migrer un projet, assurez-vous de disposer des autorisations Identity and Access Management (IAM) requises sur le projet, sa ressource parente et la ressource de destination.

Migrer des projets qui ne sont pas associés à une ressource d'organisation

Vous pouvez migrer un projet créé sans ressource d'organisation associée dans la hiérarchie d'une ressource d'organisation. Toutefois, vous ne pouvez pas inverser ce processus. Pour rétablir un projet sur Aucune organisation, contactez l'assistance Cloud Customer Care.

Pour migrer un projet qui n'est pas associé à une ressource d'organisation, vous devez disposer du rôle roles/resourcemanager.projectIamAdmin sur le projet. Vous devez également disposer du rôle roles/resourcemanager.projectCreator sur la ressource d'organisation de destination.

Si vous ne disposez pas de l'autorisation resourcemanager.organizations.get sur la ressource d'organisation parente, vos projets peuvent ne pas s'afficher comme prévu sous l'organisation dans la Google Cloud console. Cela peut donner l'impression que le projet n'est pas associé à une ressource d'organisation. Pour en savoir plus, consultez la section Restreindre la visibilité des projets pour les utilisateurs.

Pour déterminer si le projet est associé à une ressource d'organisation, procédez comme suit :

gcloud

Exécutez la commande suivante :

gcloud projects describe PROJECT_ID

Remplacez PROJECT_ID par l'ID du projet que vous souhaitez migrer.

Si la ressource parente ne s'affiche pas dans le résultat, cela confirme que le projet n'est pas associé à une ressource d'organisation.

Si la ressource parente (dossier ou ressource d'organisation) s'affiche dans la sortie, cela confirme que le projet est associé à une ressource d'organisation.

Le processus de migration d'un projet non associé à une ressource d'organisation est semblable au processus de migration d'un projet entre des ressources d'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 nécessaire, créez un dossier d'importation dédié dans la ressource d'organisation de destination.

  3. Attribuez des autorisations Identity and Access Management pour le projet et la ressource parente 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 à l'aide de l'une des méthodes suivantes :

Console

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

    Ouvrir la page "Paramètres"

  2. Sélectionnez votre projet (celui avec Aucune organisation) à l'aide du sélecteur de projet.

  3. En haut de la page Paramètres, cliquez sur Effectuer la migration.

  4. Dans la boîte de dialogue qui s'affiche, sélectionnez la ressource d'organisation vers laquelle vous souhaitez migrer votre projet, puis cliquez sur Effectuer la migration.

gcloud

Pour migrer un projet vers une ressource d'organisation, exécutez la commande suivante :

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Remplacez les éléments suivants :

  • PROJECT_ID : ID du projet à migrer
  • ORGANIZATION_ID : ID de la ressource d'organisation de destination

API

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

Pour migrer un projet vers la ressource d'organisation, procédez comme suit :

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

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

Si l'API Cloud OS Login est activée dans votre projet source, attribuez le roles/compute.osLoginExternalUser rôle à tous les comptes principaux qui ont accès à ce projet.

VPC partagé

Vous pouvez migrer des projets de VPC partagé sous certaines conditions. Tout d'abord, un utilisateur disposant du rôle roles/orgpolicy.policyAdmin dans la ressource d'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.

Vous n'avez pas besoin de désactiver le VPC partagé avant la migration. Toutefois, vous devez d'abord migrer le projet hôte du VPC partagé, suivi de tous ses projets de service. Nous vous recommandons de faire correspondre les règles de pare-feu entre les ressources d'organisation source et cible afin de minimiser les problèmes potentiels et d'éviter les temps d'arrêt. Nous ne garantissons pas l'état de fonctionnement de votre réseau si vous laissez des projets de service dans la ressource d'organisation source lors de la migration d'autres projets.

Si vous migrez le projet hôte, vous pouvez le replacer dans la ressource d'organisation source. Il n'existe pas de délai exact pour la durée pendant laquelle les projets hôtes et de service peuvent se trouver dans des organisations différentes. Cependant, une fois que vous commencez à migrer des projets de service, vous devez tous les migrer avant de pouvoir migrer à nouveau le projet hôte.

Rôles IAM personnalisés

Les rôles Identity and Access Management personnalisés offrent un contrôle précis de l'accès aux ressources au niveau de la ressource d'organisation, mais ils ne sont valides que dans la ressource d'organisation où ils sont créés. Si vous migrez un projet contenant une liaison de stratégie d'autorisation vers un rôle IAM personnalisé au niveau de l'organisation, la migration échoue. L'erreur explique que le rôle n'existe pas dans la ressource d'organisation de destination.

Pour répertorier tous les rôles IAM personnalisés dans votre ressource d'organisation, exécutez la commande suivante :

gcloud iam roles list --organization ORGANIZATION_ID

Remplacez ORGANIZATION_ID par l'ID de la ressource d'organisation. Pour en savoir plus, consultez Obtenir l'ID de ressource de votre organisation.

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

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Remplacez les éléments suivants :

  • ORGANIZATION_ID : ID de la ressource d'organisation
  • ROLE_ID : nom du rôle à décrire

Pour contourner cette erreur, créez des rôles personnalisés équivalents au niveau du projet pour chaque rôle personnalisé au niveau de l'organisation hérité. 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 d'autorisation pour qu'elles utilisent les rôles personnalisés au niveau de l'organisation dans la ressource d'organisation de destination.

Pour en savoir plus, 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. Cette règle détermine la durée de conservation des objets. Le verrou de 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 de la migration. Le privilège ne vous empêche pas de migrer le projet.

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

VPC Service Controls limite les risques d'exfiltration de données en configurant un périmètre de sécurité basé sur un projet autour des Google Cloud services. 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. Une fois que vous avez supprimé un projet d'un périmètre de service, vous devrez peut-être attendre plusieurs heures, voire un jour, avant de pouvoir le migrer.

Règles d'accès contextuel pour les comptes de service

L'accès contextuel permet aux utilisateurs de définir des règles d'accès sur les Google Cloud ressources pour les comptes de service en fonction d'attributs contextuels tels que le réseau, l'emplacement et l'heure. Vous ne pouvez pas migrer un projet qui comporte au moins une règle d'accès contextuel pour les comptes de service.

Pour supprimer une règle d'accès contextuel pour les comptes de service, consultez la section Gérer les liaisons d'accès.

Tenez compte des points suivants concernant le timing lorsque vous créez ou supprimez des règles :

  • Création de règles : une règle d'accès contextuel nouvellement créée peut ne pas bloquer immédiatement les migrations. Ce délai de propagation peut durer jusqu'à 24 heures après la création de la règle.
  • Suppression de règles : une fois que toutes les règles d'accès contextuel ont été supprimées d'un projet, vous devrez peut-être attendre plusieurs heures avant de pouvoir migrer le projet.

Interconnexion dédiée

Nous vous recommandons de migrer les projets comprenant des objets interconnexion dédiée et des rattachements de VLAN. Les projets contenant ces objets continuent de fonctionner après la migration entre les ressources d'organisation. Toutefois, vous ne pouvez pas créer de rattachements de VLAN entre les ressources d'organisation tant qu'elles sont divisées.

Les modifications de configuration apportées à un projet divisé peuvent ne pas se propager entre les ressources d'organisation. Nous vous recommandons de ne pas laisser les projets divisés trop longtemps.

Interconnexion partenaire

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

Projet de gestion

Un projet de gestion est un Google Cloud projet dans le dossier compatible avec les applications qui sert de dépôt central pour toutes vos métadonnées axées sur les applications. Chaque dossier compatible avec les applications ne contient qu'un seul projet de gestion. Le projet de gestion fournit l'infrastructure pour les bibliothèques d'applications et les API, y compris pour la facturation, les quotas et le contrôle des accès. Vous ne pouvez pas migrer un projet de gestion.

Comptes de service multiprojets

Lorsque vous migrez un compte de service multiprojet, les cas suivants s'appliquent :

  • Si vous migrez un projet auquel un compte de service multiprojet est associé, ce compte de service continue de fonctionner dans la ressource d'organisation de destination. Cela s'applique même si une règle d'administration limite le domaine.
  • Si vous migrez un projet qui possède un compte de service multiprojet utilisé par un autre projet, le compte de service continue de fonctionner. Toutefois, vous ne pouvez pas l'utiliser sur des ressources auxquelles une règle d'administration de restriction de domaine est appliquée, qui les limitent au domaine de la ressource d'organisation source.

Par exemple, supposons que project-A dans organizations/12345678901 soit associé à serviceAccount-1. project-B et project-C dans la même organisation utilisent également serviceAccount-1.

project-C dispose d'une règle d'administration qui n'autorise que le domaine organizations/12345678901.

Si vous ajoutez serviceAccount-1 à la liaison IAM pour project-C avant de migrer project-A vers organizations/45678901234, le compte de service fonctionne.

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

Demandes d'assistance

Si vous migrez un projet pour lequel une demande d'assistance est en cours, informez l'assistance Cloud Customer Care après la migration. Vous ne pourrez pas consulter ces demandes d'assistance tant que l'assistance Cloud Customer Care n'aura pas mis à jour les métadonnées vers la nouvelle ressource d'organisation.

Si votre projet utilise un écran de consentement OAuth interne, seuls les membres de la ressource d'organisation de destination peuvent autoriser les requêtes après la migration. Un délai maximum de 24 heures est nécessaire pour la prise en compte de cette modification. En attendant, les membres de la ressource d'organisation source peuvent toujours autoriser les requêtes.

Pour vous assurer que les membres sources ne perdent pas l'accès, envisagez de créer des utilisateurs dans la ressource d'organisation de destination ou de mettre à jour la configuration de l'écran de consentement OAuth :

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

  2. Si l'application utilise des données sensibles, demandez la validation des applications pour les champs d'application sensibles ou restreints. Sinon, les utilisateurs verront un écran d'application non validée.

API Cloud OS Login

Si l'API Cloud OS Login est activée dans votre projet source, attribuez le roles/compute.osLoginExternalUser rôle à tous les comptes principaux qui ont accès à ce projet. Cela permet de s'assurer que ces comptes principaux ne perdent pas l'accès dans la ressource d'organisation de destination.

Réservations partagées d'instances de machines virtuelles (VM)

Dans une réservation partagée, le projet qui a créé la réservation (projet propriétaire ) ou tout projet avec lequel elle est partagée (projet client ) peut consommer la réservation en créant des instances de VM. Vous ne pouvez partager une réservation qu'avec des projets de la même organisation que le projet propriétaire.

Lorsque vous migrez un projet propriétaire ou client, les événements suivants se produisent :

  • Si vous migrez le projet propriétaire, Compute Engine supprime toute réservation créée par ce projet. Les instances de VM en cours d'exécution ne sont pas affectées.
  • Si vous migrez un projet client, il cesse de consommer des ressources à partir de toute réservation partagée dans l'organisation précédente.

Pour en savoir plus, consultez la section Fonctionnement des réservations partagées.

Rattacher des comptes de service à des ressources

Pour la plupart des Google Cloud services, vous avez besoin de l'autorisation iam.serviceAccounts.actAs pour associer un compte de service à une ressource. Toutefois, certains services autorisaient historiquement cette opération sans autorisations d'emprunt d'identité explicites. Cela est décrit dans Exiger l'autorisation de rattacher des comptes de service aux ressources.

Si votre ressource d'organisation source applique cet ancien comportement, mais que la destination ne l'autorise pas, accordez le rôle roles/iam.serviceAccountUser aux utilisateurs qui associent ces comptes de service. Pour en savoir plus sur les autorisations, consultez la section Rôles pour l'authentification des comptes de service.

Pour vérifier si votre ressource d'organisation applique l'ancien comportement, procédez comme suit :

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

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

  2. Dans le sélecteur de ressources, choisissez la ressource d'organisation que vous souhaitez vérifier.

  3. Dans la zone de filtre, saisissez constraints/appengine.enforceServiceAccountActAsCheck.

  4. Si la règle s'affiche, la ressource d'organisation applique l'ancien comportement.

  5. Répétez les étapes 3 et 4 pour chacune des contraintes suivantes :

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

Si l'une de ces contraintes apparaît, votre ressource d'organisation utilise l'ancien comportement. Si les deux ressources d'organisation utilisent l'ancien comportement, aucune action n'est requise. Vous devez toutefois envisager d'appliquer la règle pour éviter toute tentative d'emprunt d'identité accidentelle.

Migrer des projets avec le partage BigQuery

Si vous migrez un projet qui utilise le partage BigQuery vers une autre ressource d'organisation, vous pouvez rencontrer des erreurs. Pour les résoudre, contactez l'assistance Cloud Customer Care.

Si la ressource d'échange de données de l'organisation précédente n'est pas visible sur la page Administrateur du partage de la nouvelle organisation, utilisez l'API BigQuery Sharing pour mettre à jour un champ (par exemple, description) afin de déclencher une actualisation du cache.

Exécutez la projects.locations.dataExchanges.patch méthode.

PATCH https://analyticshub.googleapis.com/v1/projects/ \
    PROJECT_ID/locations/LOCATION/ \
    dataExchanges/DATA_EXCHANGE_ID \
    ?update_mask=UPDATE_DX_FIELD \
    -d { UPDATE_DX_FIELD:UPDATE_DX_VALUE }

Remplacez les éléments suivants :

  • PROJECT_ID : identifiant unique du projet
  • LOCATION : emplacement de l'échange de données
  • DATA_EXCHANGE_ID : ID de l'échange de données
  • UPDATE_DX_FIELD : champ à mettre à jour, tel que description
  • UPDATE_DX_VALUE : valeur mise à jour

Service Backup and DR

Désactivez Backup and DR avant de migrer des projets vers une autre ressource d'organisation. Tenez compte du risque d'interruption lorsque le service est désactivé. Réactivez Backup and DR une fois la migration terminée.

Fédération d'identité de charge de travail

La fédération d'identité de charge de travail vous permet d' accorder aux charges de travail sur site ou multicloud l'accès aux Google Cloud ressources. Les pools de fédération d'identité de charge de travail sont des ressources limitées à un projet.

Lorsque vous migrez un projet, les pools d'identités de charge de travail et leurs fournisseurs configurés dans ce projet sont migrés avec le projet. Aucune action supplémentaire n'est requise pour maintenir l'accès aux charges de travail utilisant ces pools.

Tags

Les tags sont des paires clé/valeur associées à des ressources. Les tags créés au niveau de l'organisation ne sont pas migrés.

Si votre projet utilise des tags au niveau de l'organisation pour les liaisons ou les contraintes de règles, vous devez recréer les clés et les valeurs de tag dans la ressource d'organisation de destination et les rattacher aux projets migrés.

Migrer des projets avec des autorisations Privileged Access Manager héritées

Avant de migrer un projet, nous vous recommandons de révoquer toutes les autorisations limitées actives sur ce projet. Une autorisation limitée est créée sur un droit hérité d'un dossier ou d'une organisation, puis limitée à un projet enfant.

Lorsque vous migrez un projet avec une autorisation limitée active, la stratégie IAM est déplacée vers la nouvelle organisation, mais l'autorisation qui la gère reste dans l'organisation précédente. L'agent de service Privileged Access Manager perd l'autorisation de modifier la stratégie IAM dans la nouvelle organisation. Par conséquent, toutes les opérations de révocation ou de retrait de cette autorisation échouent, et le demandeur conserve l'accès jusqu'à l'expiration de l'autorisation.

Étape suivante