Gérer les cas particuliers

Lorsque vous migrez des projets Google Cloud entre organisations, certaines ressources et configurations nécessitent des étapes supplémentaires pour maintenir la continuité du service et éviter les conflits de configuration. Ces cas particuliers incluent les projets sans ressource d'organisation, les ressources de VPC partagé, les rôles personnalisés et les comptes de service inter-projets. Avant de migrer un projet, assurez-vous de disposer des autorisations IAM (Identity and Access Management) 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 vers la hiérarchie d'une ressource d'organisation. Toutefois, vous ne pouvez pas annuler cette opération. Pour rétablir un projet sur Aucune organisation, contactez Cloud Customer Care pour obtenir de l'aide.

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 risquent de ne pas s'afficher comme prévu sous l'organisation dans la console Google Cloud . Cela peut donner l'impression que le projet n'est pas associé à une ressource d'organisation. Pour en savoir plus, consultez 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 parent n'est pas affichée dans le résultat, cela confirme que le projet n'est pas associé à une ressource d'organisation.

Si la ressource parente (ressource de dossier ou d'organisation) s'affiche dans le résultat, 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 à celui de la 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 IAM (Identity and Access Management) pour le projet et la ressource parente de destination, comme indiqué dans 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 console Google Cloud .

    Ouvrir la page "Paramètres"

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

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

  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 Migrer.

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 Organisation :

  • Obtenez 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.
  • 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 rôle roles/compute.osLoginExternalUser à tous les comptes principaux ayant 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 lister 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 de VPC partagé, puis 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 votre réseau si vous laissez des projets de service dans la ressource d'organisation source pendant la migration d'autres projets.

Si vous migrez le projet hôte, vous pouvez le replacer dans la ressource d'organisation source. Il n'y a 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. Toutefois, une fois que vous avez commencé à 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 IAM (Identity and Access Management) personnalisés permettent de contrôler de manière précise l'accès aux ressources au niveau de la ressource Organisation, mais ils ne sont valides que dans la ressource 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 lister tous les rôles IAM personnalisés de 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é hérité au niveau de l'organisation. Ensuite, supprimez les liaisons de rôles IAM qui font référence aux rôles personnalisés au niveau de l'organisation.

Après avoir migré le projet, vous pouvez mettre à jour les stratégies d'autorisation pour utiliser les rôles personnalisés au niveau de l'organisation dans la ressource d'organisation de destination.

Pour en savoir plus, consultez Créer et gérer des 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 pour éviter toute suppression accidentelle du projet.

La règle de conservation et le privilège sont conservés avec le projet pendant 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 servicesGoogle Cloud . 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 Gérer les périmètres de service. La migration d'un projet peut prendre plusieurs heures, voire une journée, après sa suppression d'un périmètre de service.

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 ressources Google Cloud 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 Gérer les liaisons d'accès.

Tenez compte des points suivants concernant les délais lors de la création ou de la suppression de règles :

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

Dedicated Interconnect

Nous vous recommandons de migrer ensemble les projets contenant des objets interconnexion dédiée et les projets contenant 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 des ressources d'organisation lorsqu'elles sont divisées.

Les modifications de configuration apportées à un projet fractionné peuvent ne pas se propager aux ressources de l'organisation. Nous vous recommandons de ne pas laisser les projets divisés pendant une longue période.

Partner Interconnect

Il n'y a pas de considérations particulières pour la migration de projets avec interconnexion partenaire. Aucune mesure particulière n'est requise lors de la migration de projets avec interconnexion partenaire.

Projet de gestion

Le projet de gestion est un projet Google Cloud dans le dossier compatible avec les applications qui sert de répertoire central pour toutes les métadonnées centrées sur l'application. 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 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 est associé un compte de service multiprojet, le compte de service continue de fonctionner dans la ressource d'organisation de destination. Cela s'applique même si une règle d'administration restreint 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 limite 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 de 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 que vous essayez d'ajouter serviceAccount-1 à la liaison IAM pour project-C, la liaison échoue, car elle ne respecte pas la restriction de domaine.

Demandes d'assistance

Si vous migrez un projet avec une demande d'assistance ouverte, informez Cloud Customer Care après la migration. Vous ne pourrez pas afficher ces demandes d'assistance tant que Cloud Customer Care n'aura pas mis à jour les métadonnées de 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 de l'organisation source peuvent toujours autoriser les requêtes.

Pour vous assurer que les membres de la source ne perdent pas l'accès, envisagez de créer de nouveaux 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 d'autorisation OAuth pour qu'il soit externe, et non interne.

  2. Si l'application utilise des données sensibles, demandez la validation de l'application 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 rôle roles/compute.osLoginExternalUser à tous les comptes principaux ayant accès à ce projet. Cela permet de s'assurer que ces comptes principaux ne perdent pas l'accès à 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 utiliser 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 consommateur, voici ce qui se passe :

  • Si vous migrez le projet propriétaire, Compute Engine supprime toutes les réservations créées 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 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 services Google Cloud , vous devez disposer de l'autorisation iam.serviceAccounts.actAs pour associer un compte de service à une ressource. Cependant, certains services l'autorisaient historiquement sans autorisations d'emprunt d'identité explicites. Pour en savoir plus, consultez Exiger l'autorisation d'associer des comptes de service à des ressources.

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

Pour vérifier si votre ressource d'organisation présente l'ancien comportement :

  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 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 présente 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, mais envisagez d'appliquer la règle pour empêcher l'emprunt d'identité involontaire.

Migrer des projets avec le partage BigQuery

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

Si la ressource d'échange de données de l'organisation précédente n'est pas visible sur la page de l'administrateur de 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 méthode projects.locations.dataExchanges.patch.

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, par exemple 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 ressources Google Cloud . Les pools de fédération d'identité de charge de travail sont des ressources limitées au 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 stratégie, vous devez recréer les clés et les valeurs de tag dans la ressource d'organisation de destination, puis 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 d'accès actives sur ce projet. Une autorisation limitée est créée sur un droit d'accès hérité d'un dossier ou d'une organisation, puis limitée à un projet enfant.

Lorsque vous migrez un projet avec une attribution d'accès limitée active, la stratégie IAM est déplacée vers la nouvelle organisation, mais l'attribution d'accès 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, toute opération de révocation ou de retrait sur cette autorisation échoue, et le demandeur conserve l'accès jusqu'à l'expiration de l'autorisation.

Étapes suivantes