Gérer les cas particuliers

Ce document fournit des informations sur la gestion des cas particuliers lors de la migration de projets. Lorsque vous migrez un projet, assurez-vous de disposer des autorisations IAM requises pour 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 qui n'est pas associé à une ressource Organisation vers une ressource Organisation. Toutefois, vous ne pouvez pas rétablir l'option sur Aucune organisation à l'aide de ce processus. Si votre projet est associé à votre ressource d'organisation et que vous souhaitez rétablir l'option sur Aucune organisation, contactez votre conseiller de l'équipe d'assistance pour obtenir de l'aide.

Vous devez disposer du rôle roles/resourcemanager.projectCreator attribué à la ressource Organisation de destination.

Si vous ne disposez pas de l'autorisation resourcemanager.organizations.get sur la ressource d'organisation parente du projet, il est probable que vos projets ne s'affichent pas comme prévu sous l'organisation réelle dans la consoleGoogle Cloud . Cela peut donner l'impression que le projet n'est associé à aucune 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 projects describe PROJECT_ID

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 Organisation, procédez comme suit :

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

2. Si vous le souhaitez, créez un dossier d'importation dédié dans la ressource de l'organisation de destination.

3. Attribuez des autorisations Identity and Access Management pour le projet et la ressource 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.

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

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

Si OS Login est activé dans votre projet source, vous devez attribuer le rôle roles/compute.osLoginExternalUser à tous les comptes principaux qui ont accès à ce projet.

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 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, 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 ressources d'organisation aux emplacements source et cible. Vous devriez ainsi minimiser les problèmes potentiels et éviter tout temps d'arrêt pour les projets et le réseau pendant la migration. Nous n'offrons aucune garantie sur l'état de fonctionnement de votre réseau si vous laissez indéfiniment certains projets de service dans la ressource de l'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 que le projet hôte et les projets de service puissent appartenir à des organisations différentes. Cependant, une fois que vous commencez à migrer les projets de service, vous devez tous les migrer avant de pouvoir migrer à nouveau le projet hôte.

Rôles personnalisés Identity and Access Management

Vous pouvez créer des rôles Identity and Access Management personnalisés au niveau de la ressource Organisation pour fournir un contrôle précis de l'accès aux ressources. Toutefois, ils ne sont valides que dans la ressource Organisation dans laquelle ils sont créés. Si vous essayez de migrer un projet contenant une liaison de stratégie d'autorisation d'un utilisateur vers un rôle IAM personnalisé au niveau de l'organisation, la migration échoue et renvoie une erreur de condition préalable ayant échoué, qui indique que le rôle en question n'existe pas dans la ressource de l'organisation de destination.

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

gcloud iam roles list --organization ORGANIZATION_ID

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

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

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Où :

• ORGANIZATION_ID est l'ID de ressource 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 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 d'autorisation pour qu'elles utilisent les rôles personnalisés au niveau de l'organisation dans la ressource de l'organisation de destination.

Pour en savoir plus sur les rôles personnalisés, consultez la page Créer et gérer les rôles personnalisés.

Verrou de bucket

Le verrou de bucket Cloud Storage vous permet de configurer une règle de conservation des données sur un bucket Cloud Storage qui régit la durée de conservation des objets du bucket. Le verrou de bucket est protégé par un privilège qui empêche toute suppression accidentelle du projet.

La règle de conservation et le privilège sont conservés avec le projet lors d'une migration. Toutefois, vous devez savoir si vous migrez un projet avec un verrou de bucket appliqué et éviter les déplacements accidentels.

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

VPC Service Controls permet aux utilisateurs de configurer un périmètre de sécurité basé sur un projet autour de leurs servicesGoogle Cloud afin de limiter les risques d'exfiltration de données. Vous ne pouvez pas migrer un projet protégé par un périmètre de sécurité VPC Service Controls.

Pour supprimer un projet d'un périmètre de sécurité, consultez la section Gérer les périmètres de service. Les projets situés dans des périmètres VPC Service Controls ne peuvent pas être bloqués lors de la migration entre les ressources d'organisation. Cette consigne s'applique jusqu'à un jour après la création ou la modification d'un périmètre. Une fois supprimé du périmètre de service, il peut s'écouler plusieurs heures avant que vous ne puissiez migrer un projet.

Dedicated Interconnect

Nous vous recommandons de migrer ensemble les projets comprenant des objets interconnexion dédiée et des rattachements de VLAN. Les projets avec des objets d'interconnexion dédiée ou des rattachements de VLAN connectés à ces objets continueront de fonctionner après la migration entre les ressources de l'organisation. La seule restriction est que vous ne pourrez pas créer de rattachements de VLAN entre les ressources de l'organisation divisée.

Les modifications de configuration apportées à un projet d'une ressource d'organisation qui comporte un objet d'interconnexion dédiée associé ou un rattachement de VLAN à cet objet peuvent ne pas se propager à l'autre ressource d'organisation. Dans la mesure du possible, nous vous recommandons de ne pas laisser de tels projets trop longtemps répartis sur plusieurs ressources d'organisation.

Interconnexion partenaire

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

Comptes de service multiprojets

Dans le contexte de la migration des comptes de service multiprojets, les cas suivants s'appliquent :

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

Par exemple, supposons que vous disposiez du projet project-A dans les organizations/12345678901. Le serviceAccount-1 est associé à ce projet et configuré en tant que compte de service multiprojet. Les project-B et project-C, également dans organizations/12345678901, utilisent également serviceAccount-1.

Vous avez appliqué une règle d'administration avec la contrainte de restriction de domaine à project-C, ce qui ne lui permet d'accéder qu'au domaine de organizations/12345678901..

Si vous ajoutez serviceAccount-1 à la liaison IAM pour project-C, puis que vous migrez project-A vers organizations/45678901234, le compte de service fonctionnera.

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 contrainte de restriction de domaine.

Demandes d'assistance

Si vous migrez un projet pour lequel une demande d'assistance est en cours, vous devez contacter votre conseiller de l'équipe d'assistance Google pour l'informer de la migration. Les projets pour lesquels une demande d'assistance est en cours auprès de Google ne peuvent pas être consultés tant que l'assistance Google n'a pas mis à jour les métadonnées de la demande afin qu'elles pointent vers la nouvelle ressource d'organisation.

Écran de consentement OAuth

Si votre projet est configuré pour utiliser un écran d'autorisation OAuth interne et que vous le migrez vers une autre ressource d'organisation, seuls les membres de la ressource d'organisation de destination peuvent autoriser les requêtes. La prise en compte de ce comportement peut prendre jusqu'à 24 heures. En attendant, les membres de la ressource de l'organisation source peuvent autoriser les demandes.

Les étapes ci-dessous expliquent comment vous prémunir de la perte d'accès des membres de votre organisation source lors de la migration. Envisagez de créer des utilisateurs dans votre ressource d'organisation de destination pour les membres de la ressource d'organisation afin de ne pas avoir à modifier la configuration de l'écran d'autorisation OAuth.

Pour éviter que les membres de la ressource de l'organisation source perdent leur accès, procédez comme suit :

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

2. Les applications marquées comme internes et utilisant des données sensibles n'ont pas besoin de demander la validation de leur application. Si l'application utilise des données sensibles, lors de la mise à jour de l'écran d'autorisation en externe, les utilisateurs de la ressource de l'organisation source verront un écran d'application non validé avant l'écran d'autorisation. Pour éviter cela, demandez la validation des applications pour l'utilisation de champs d'application sensibles ou restreints.

OS Login

Si OS Login est activé dans votre projet source, vous devez attribuer le rôle roles/compute.osLoginExternalUser à tous les comptes principaux qui ont accès à ce projet. Cela garantit 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 la réservation 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 vers une autre organisation, les événements suivants se produisent :

• Si vous migrez le projet propriétaire vers une autre organisation, Compute Engine supprime toutes les réservations créées par le projet propriétaire. Les instances de VM en cours d'exécution ne sont pas affectées.
• Si vous migrez un projet client vers une autre organisation, il cesse de consommer des ressources issues 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 , les utilisateurs ont besoin de l'autorisation iam.serviceAccounts.actAs sur un compte de service pour rattacher ce compte de service à une ressource. Auparavant, pour faciliter l'intégration, certains services permettaient aux utilisateurs d'associer des comptes de service aux ressources, même s'ils n'étaient pas autorisés à emprunter l'identité des comptes de service. Pour en savoir plus, consultez Exiger l'autorisation de rattacher des comptes de service aux ressources.

Si la ressource de l'organisation source d'un client applique l'ancien comportement (l'association de comptes de service est possible sans l'attribution de rôle normale) et si la ressource de l'organisation de destination ne l'autorise pas, attribuez le rôle Utilisateur de compte de service (roles/iam.serviceAccountUser) aux utilisateurs qui associent ces comptes de service aux ressources. Pour en savoir plus sur les autorisations dont vous avez besoin pour associer des comptes de service à des ressources, consultez Rôles pour l'authentification des comptes de service.

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

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

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

2. Dans le sélecteur de projet en haut de la page, sélectionnez la ressource d'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, la ressource d'organisation applique l'ancien comportement.

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

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

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

Si la ressource de l'organisation source utilise l'ancien comportement, mais pas l'organisation de destination, attribuez les rôles comme indiqué ci-dessus. Si les ressources des organisations source et de destination 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 le projet qui utilise le partage BigQuery (anciennement Analytics Hub) vers une autre ressource d'organisation, vous risquez de rencontrer des erreurs. Pour résoudre les erreurs, contactez l'assistance.

Si la ressource d'échange de données de l'ancienne organisation n'est pas visible sur la page "Administrateur du partage" de la nouvelle organisation, utilisez l'API Analytics Hub pour mettre à jour l'échange de données dans la nouvelle organisation.

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 est l'identifiant unique du projet.
• LOCATION est l'emplacement de l'échange de données.
• DATA_EXCHANGE_ID est l'ID de l'échange de données.
• UPDATE_DX_FIELD est le champ à mettre à jour.
• UPDATE_DX_VALUE est la nouvelle valeur du champ.

Migrer des projets avec le service Backup and DR

Vous devez désactiver le service Backup and DR avant de migrer des projets vers une autre ressource d'organisation. À ce moment-là, lorsque le service est désactivé, il existe un risque d'indisponibilité dont vous devez tenir compte. Vous devez réactiver le service Backup and DR une fois la migration vers la nouvelle ressource d'organisation terminée.

Étapes suivantes

Pour savoir comment effectuer la migration, consultez Effectuer la migration.