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 d'organisation vers une ressource d'organisation. Toutefois, vous ne pouvez pas rétablir l'option sur Aucune organisation à l'aide de ce processus. Si votre projet est associé à la ressource de votre organisation et que vous souhaitez rétablir l'option sur Aucune autorisation, 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 dans l'organisation réelle de la console Google Cloud. Cela peut donner l'impression que le projet n'est associé à aucune ressource de l'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 n'est pas affichée dans la sortie, 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 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.

Console

Pour migrer un projet vers une ressource d'organisation:

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

    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 ressource d'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 la ressource d'organisation vers laquelle vous souhaitez migrer votre projet.

gcloud

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

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Où :

  • PROJECT_ID est l'ID du projet que vous souhaitez migrer vers la ressource de l'organisation.
  • ORGANIZATION_ID est l'ID de la ressource de l'organisation vers laquelle vous souhaitez migrer le projet.

API

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

Pour migrer un projet vers la ressource de l'organisation:

  • Récupérez 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 les étapes ci-dessus :

    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 ayant 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 de l'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 de l'organisation source. Il n'existe pas de délai exact pour que le projet hôte et les projets de service puissent appartenir à différentes organisations. 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 IAM au niveau de la ressource de l'organisation pour fournir un contrôle précis de l'accès aux ressources. Toutefois, ils ne sont valides que dans la ressource de l'organisation dans laquelle ils sont créés. Si vous essayez de migrer un projet contenant une liaison de stratégie IAM d'un utilisateur vers un rôle IAM personnalisé au niveau de la ressource 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 la ressource de votre organisation, exécutez la commande Google Cloud CLI suivante:

gcloud iam roles list --organization ORGANIZATION_ID

Où ORGANIZATION_ID correspond à l'ID de la ressource de l'organisation pour laquelle vous souhaitez lister les rôles. Pour savoir comment rechercher l'ID de votre ressource d'organisation, consultez Créer et gérer les 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 correspond à l'ID de la ressource d'organisation de la ressource d'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 IAM 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 services Google 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 pour être migrés entre les ressources de l'organisation. Cette consigne s'applique jusqu'à une journée après la création ou la mise à jour d'un périmètre. Une fois supprimé du périmètre de service, il peut s'écouler plusieurs heures avant que vous puissiez migrer un projet.

Dedicated Interconnect

Nous vous recommandons de migrer les projets comprenant des objets d'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 nouveaux rattachements de VLAN entre la division des ressources de l'organisation.

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 de l'organisation. Nous vous recommandons de ne pas laisser de tels projets trop longtemps répartis sur plusieurs projets dans la mesure du possible.

Interconnexion partenaire

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

Comptes de service multiprojets

Dans le cadre de la migration d'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 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 de l'organisation source, ce compte de service continuera de fonctionner dans la ressource de l'organisation de destination. Toutefois, vous ne pouvez 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 de support

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 de l'organisation.

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 requêtes.

Les étapes ci-dessous expliquent comment vous prémunir de la perte d'accès des membres de votre ressource d'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 ne perdent leur accès:

  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 ayant accès à ce projet. Cela garantit que ces comptes principaux ne perdent pas leur accès dans la ressource d'organisation de destination.

Réservations partagées d'instances de machine virtuelle (VM)

Dans une réservation partagée, le projet qui a créé la réservation (projet propriétaire) ou les projets avec lesquels la réservation est partagée (projet client) peuvent 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 client vers une autre organisation, les éléments 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 les 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, 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 à usurper 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 du 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 la section Rôles pour l'authentification du compte 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 de 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, 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, votre ressource d'organisation utilise l'ancien comportement.

Si la ressource de l'organisation source utilise l'ancien comportement, mais pas la 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 Analytics Hub

Si vous migrez le projet qui utilise Analytics Hub vers une autre ressource de l'organisation, vous risquez de rencontrer une erreur. 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 d'administration Analytics Hub 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 correspond à la valeur mise à jour 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. À l'heure actuelle, lorsque le service est désactivé, vous devez tenir compte du risque d'interruption. Vous devez réactiver le service Backup and DR une fois la migration vers la nouvelle ressource d'organisation terminée.

Étape suivante

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