Gérer des cas particuliers

Cet article fournit des informations sur la gestion des cas particuliers liés à la migration de projets.

Migrer des projets sans ressource d'organisation

Vous pouvez migrer un projet qui n'est pas associé à une ressource Organisation vers une ressource Organisation. Cependant, vous ne pouvez pas revenir à Aucune organisation en suivant ce processus. Si un projet est associé à votre ressource Organisation et que vous souhaitez rétablir l'option Aucune organisation, contactez votre représentant de l'assistance pour obtenir de l'aide.

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 se reflètent pas comme prévu dans l'organisation réelle. Pour en savoir plus, consultez la section Restreindre la visibilité des projets pour les utilisateurs.

Remarque : La restauration d'un projet sur Aucune organisation nécessite une justification de l'entreprise.

Le processus de migration d'un projet qui n'est pas associé à une ressource Organisation est semblable à celui de la migration d'un projet entre des ressources Organisation, mais il 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 d'organisation de destination.

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

   

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 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 d'organisation.
• ORGANIZATION_ID est l'ID de la ressource 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 ressource d'organisation de la ressource Organisation.

Pour migrer un projet vers la ressource Organisation:

• Récupérez 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.
• 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é

Remarque :La migration des projets de service de VPC partagé peut prendre jusqu'à deux minutes après la migration du projet hôte correspondant en raison du délai de propagation. Vous risquez de rencontrer une erreur au cours de cette période lorsque vous migrez ces projets. Dans ce cas, relancez la migration.

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.

Il n'est pas nécessaire de désactiver le VPC partagé avant la migration. Toutefois, le projet hôte du VPC partagé doit être migré en premier, 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, ce qui devrait minimiser les problèmes potentiels et éviter tout temps d'arrêt pour les projets et le réseau lors de la migration. Nous n'offrons aucune garantie concernant l'intégrité de votre réseau si vous laissez indéfiniment certains 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'existe pas de date limite exacte quant à la durée possible du projet hôte et des projets de service dans des organisations différentes. Toutefois, lorsque 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

Des rôles Identity and Access Management personnalisés peuvent être créés au niveau d'une ressource Organisation afin de fournir un contrôle précis de l'accès aux ressources, mais ils ne sont valides que dans la ressource d'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 des ressources de l'organisation, la migration échoue et renvoie une erreur de condition préalable qui indique que le rôle en question n'existe pas dans la ressource d'organisation de destination.

Pour répertorier tous les rôles IAM personnalisés au niveau de la ressource 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 ressource de votre organisation, consultez Créer et gérer des ressources Organisation.

Pour obtenir des informations sur un rôle Identity and Access Management personnalisé dans votre ressource d'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 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 utiliser les rôles personnalisés au niveau de l'organisation dans la ressource d'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 de la migration, mais vous devez savoir si vous migrez un projet avec un verrouillage 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. Il est possible que la migration des projets situés dans des périmètres VPC Service Controls entre des ressources d'organisation ne soit pas bloquée. Cette consigne s'applique jusqu'à une journée après la création ou la mise à jour d'un périmètre. La migration d'un projet après sa suppression du périmètre de service peut prendre plusieurs heures.

Dedicated Interconnect

Nous vous recommandons de migrer simultanément les projets comportant des objets d'interconnexion dédiée et les projets avec des rattachements de VLAN. Les projets comportant 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 la division des ressources de l'organisation.

Les modifications de configuration apportées à un projet dans une ressource Organisation auquel un objet d'interconnexion dédiée est 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 ces projets répartis entre les ressources de l'organisation trop longtemps.

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 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 d'organisation de destination. Ce projet continuera de fonctionner avec le compte de service associé, même si une règle d'administration restreint 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 les ressources auxquelles une règle d'administration de restriction de domaine qui les limite au domaine de la ressource d'organisation source est appliquée.

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 échouera, 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 l'assistance Google pour l'informer que la migration a eu lieu. Les projets ayant fait l'objet d'une demande d'assistance en cours auprès de Google ne pourront pas les afficher tant que l'assistance Google n'aura pas mis à jour les métadonnées de la demande pour qu'elles pointent vers la nouvelle ressource d'organisation.

Écran d'autorisation OAuth

Si votre projet est configuré pour utiliser un écran de consentement 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. Un délai maximal de 24 heures peut être nécessaire pour que ce comportement soit pris en compte. En attendant, les membres de la ressource Organisation source peuvent autoriser les requêtes.

Les étapes ci-dessous expliquent comment garantir que les membres de la ressource d'organisation source ne perdent pas leur accès pendant la migration. Envisagez de créer des utilisateurs dans votre ressource Organisation de destination pour les membres de la ressource Organisation afin de ne pas avoir à modifier la configuration de l'écran de consentement OAuth.

Pour éviter de perdre l'accès des membres de la ressource d'organisation source:

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

2. Les applications marquées comme internes et qui utilisent des données sensibles n'ont pas besoin de demander la validation des applications. Si l'application utilise des données sensibles, lorsque l'écran de consentement devient externe, les utilisateurs de la ressource d'organisation source voient un écran d'application non validée 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 l'accès à 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 tous les projets avec lesquels la réservation 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 appartenant à la même organisation que le projet propriétaire.

Lorsque vous migrez un projet propriétaire ou client vers une autre organisation, voici ce qui se produit:

• Si vous migrez le projet propriétaire vers une autre organisation, Compute Engine supprime toute réservation créée par le projet propriétaire. L'exécution des instances de VM ne sont pas affectées.
• Si vous migrez un projet consommateur vers une autre organisation, il cesse de consommer des ressources de toute réservation partagée de 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 doivent disposer de l'autorisation iam.serviceAccounts.actAs sur un compte de service pour l'associer à une ressource. Toutefois, auparavant, pour faciliter l'intégration de certains services, les utilisateurs pouvaient associer des comptes de service aux ressources, même s'ils n'étaient pas autorisés à emprunter l'identité de ces comptes. Cette procédure est documentée dans la section Exiger l'autorisation d'associer des comptes de service aux ressources.

Si la ressource d'organisation source d'un client a l'ancien comportement (l'association de comptes de service est possible sans l'attribution normale du rôle) et que la ressource d'organisation de destination n'en a pas, attribuez le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) aux utilisateurs qui associent ces comptes de service à des ressources. Pour en savoir plus sur les autorisations nécessaires pour associer des comptes de service à des ressources, consultez la section Rôles pour l'authentification des comptes de service.

Pour voir si votre ressource d'organisation utilise 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, choisissez la ressource d'organisation pour laquelle vous souhaitez vérifier l'état de l'ancien.

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 figure dans la liste, cela signifie que la ressource d'organisation a l'ancien comportement.

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

Si la ressource Organisation source possède l'ancien comportement, mais pas la destination, accordez les rôles comme indiqué ci-dessus. Si les ressources de l'organisation source et de destination ont l'ancien comportement, aucune action n'est requise. Toutefois, pensez à appliquer la règle pour éviter toute usurpation d'identité involontaire.

Migrer des projets avec Analytics Hub

Si vous migrez le projet qui utilise Analytics Hub vers une autre ressource d'organisation, vous risquez de rencontrer une erreur. Pour résoudre les erreurs, contactez l'assistance.

Migrer des projets avec le service de sauvegarde et de reprise après sinistre

Vous devez désactiver le service de sauvegarde et de reprise après sinistre avant de migrer des projets vers une autre ressource d'organisation. À ce stade, lorsque le service est désactivé, vous devez prendre en compte un risque d'indisponibilité. Vous devez réactiver le service de sauvegarde et de reprise après sinistre une fois la migration vers la nouvelle ressource d'organisation terminée.

Étapes suivantes

Pour en savoir plus sur la migration, consultez Effectuer la migration.