Gérer des cas particuliers

Cet article fournit des informations sur la gestion de 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 dans une ressource Organisation. Toutefois, vous ne pourrez pas revenir à Aucune organisation n'utilise ce processus. Si vous avez un projet associée à votre ressource d'organisation et que vous souhaitez la rétablir 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 le ressource d'organisation parente du projet, il est probable que vos projets ne se reflètent pas comme prévu sous l'organisation réelle. Pour en savoir plus, consultez Restreindre la visibilité du projet pour les utilisateurs

Processus de migration d'un projet non associé à une ressource Organisation est semblable au processus de migration d'un projet ressources, mais ne nécessite pas toutes les étapes du plan de migration. Pour migrer un projet vers une ressource Organisation, procédez comme suit : procédez comme suit:

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

  2. Créez un dossier d'importation dédié dans la destination. ressource d'organisation, si vous le souhaitez.

  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 le tableau de bord IAM & admin > Paramètres de 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 utilisez n'est associée à aucune ressource Organisation, L'outil de sélection d'organisations ne s'affiche pas. 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 Organisation. vers lequel vous souhaitez migrer le 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 le ressource d'organisation.
  • ORGANIZATION_ID est l'ID de la ressource d'organisation à laquelle que vous souhaitez migrer.

API

L'API Resource Manager vous permet de migrer un projet vers l'organisation ressource 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 de l'organisation. 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 la connexion au système d'exploitation est activée 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 la ressource d'organisation source doit définir une règle d'administration contenant le la contrainte constraints/resourcemanager.allowEnabledServicesForExport appliquée au 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, vous devez d'abord migrer le projet hôte du VPC partagé, puis tous ses projets de service. Nous vous recommandons de faire correspondre les règles de pare-feu les ressources de l'organisation aux emplacements source et cible, ce qui devrait réduire les problèmes potentiels et d'éviter tout temps d'arrêt pour les projets et le réseau la migration. Nous n'offrons aucune garantie quant à la santé de votre réseau dans les cas suivants : vous laissez indéfiniment certains projets de service dans la ressource d'organisation source migrer d'autres ressources.

Si vous migrez le projet hôte, vous pouvez le replacer dans la ressource d'organisation source. Il n'y a pas de date limite exacte quant à la durée pendant laquelle le projet hôte et les projets de service peuvent se trouver dans différentes organisations. Toutefois, lorsque vous commencez à migrer les projets de service, vous devez tous les migrer avant vous pouvez 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 des ressources de l'organisation pour fournir un contrôle précis de l'accès aux ressources, mais elles ne sont valides que dans la ressource d'organisation dans laquelle elles sont créées. Si vous essayez de migrer un projet contenant une liaison de stratégie IAM d'un utilisateur à un rôle IAM personnalisé au niveau des ressources de l'organisation, la migration échoue avec une erreur de condition préalable d'échec, expliquant que le rôle en question n'existent pas dans la ressource d'organisation de destination.

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

gcloud iam roles list --organization ORGANIZATION_ID

Où ORGANIZATION_ID est la ressource d'organisation. ID pour lequel vous souhaitez répertorier les rôles. Pour savoir comment trouver votre ID de ressource d'organisation, consultez la page 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 du 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 pour utiliser les rôles personnalisés au niveau de l'organisation ressource d'organisation.

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, sachez que si vous migrez un projet avec un verrou de bucket, et d'empêcher tout déplacement accidentel.

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. La migration des projets situés dans les périmètres VPC Service Controls peut être autorisée aux ressources de l'organisation. Cette consigne s'applique jusqu'à un jour après la création d'un périmètre ou mis à jour. La migration d'un projet peut prendre plusieurs heures. du périmètre de service.

Dedicated Interconnect

Nous vous recommandons de migrer des projets avec interconnexion dédiée des objets et des projets avec des rattachements de VLAN. Les projets avec des objets 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 répartition des ressources de l'organisation.

Les modifications de configuration apportées à un projet dans une ressource "Organisation" ayant un d'un objet interconnexion dédiée ou d'un rattachement de VLAN il est possible que cet objet ne se propage pas à l'autre ressource d'organisation. Nous vous recommandons de ne pas laisser ces projets répartis entre les organisations des ressources très longtemps, si 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 associé à un compte de service multiprojet associé, ce compte de service continuera de fonctionner dans la ressource d'organisation de destination. Ce projet continuera de fonctionner avec même s'il existe une règle d'administration restreint le domaine associé projet.
  • Si vous migrez un projet auquel est associé un compte de service multiprojet à un autre projet de la ressource d'organisation source, ce compte de service continuent de fonctionner dans la ressource d'organisation de destination. Cependant, vous n'allez pas pouvoir utiliser ce compte de service sur toutes les ressources associées à un domaine qui leur est appliquée et les limite le domaine de la ressource d'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 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, le la liaison échouera car elle ne respecte pas la contrainte de restriction de domaine.

Demandes de support

Si vous migrez un projet associé à une demande d'assistance en cours, vous devez contacter votre contact de l'assistance Google pour l'informer que la migration a eu lieu. N'importe quelle valeur pour les projets faisant l'objet d'une demande d'assistance en cours auprès de Google, jusqu'à ce que l'assistance Google mette à jour les métadonnées associées la nouvelle ressource Organisation.

Si votre projet est configuré pour utiliser Écran de consentement OAuth interne et que vous le migrez vers une autre ressource Organisation, seuls les membres ressource d'organisation de destination peut autoriser les requêtes. L'opération peut prendre jusqu'à 24 heures pour que ce comportement prenne effet. Jusque-là, les membres de la source ressource Organisation peut autoriser les requêtes.

Les étapes ci-dessous expliquent comment vous assurer que les membres de votre organisation source ressource ne perdent pas son accès lors de la migration. Pensez à créer des utilisateurs dans votre ressource d'organisation de destination pour les membres de la ressource Organisation vous n'avez pas besoin de modifier la configuration de l'écran de consentement OAuth.

Pour éviter toute perte d'accès pour les membres de la ressource d'organisation source:

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

  2. Applications marquées comme internes et pouvant être utilisées données sensibles n'ont pas besoin de demander la validation de l'application. Si l'application utilise des données sensibles, Ensuite, lorsque l'écran de consentement devient "externe", les utilisateurs de la source ressource d'organisation verra écran "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 la connexion au système d'exploitation est activée 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 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 (owner projet) ou les projets avec lesquels la réservation est partagée (utilisateurs projet) peuvent utiliser 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, l'événement suivant 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. Les instances de VM en cours d'exécution ne sont pas affectées.
  • Si vous migrez le projet d'un client vers une autre organisation, le projet cesse de consommer des ressources issues des réservations partagées des organisation.

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 du iam.serviceAccounts.actAs l'autorisation d'associer ce compte de service à une ressource. Toutefois, par le passé, pour faciliter l'intégration de certains services, les utilisateurs associer des comptes de service aux ressources, même si les utilisateurs emprunter l'identité des comptes de service. Cela est documenté dans Demander l'autorisation de associer des comptes de service ressources.

Si la ressource d'organisation source d'un client présente l'ancien comportement (service le rattachement de comptes est possible sans l'attribution du rôle normal) et ressource de l'organisation de destination, accordez le rôle d'utilisateur du compte de service (roles/iam.serviceAccountUser) aux utilisateurs qui associent ce compte de service à ressources. Pour en savoir plus sur les autorisations dont vous avez besoin pour associer le service, des comptes de service aux ressources, consultez la section Rôles authentification.

Pour vérifier si votre ressource Organisation a 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 l'organisation. ressource 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 Organisation a l'ancien comportement.

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

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

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

Si la ressource Organisation source a l'ancien comportement et la destination n'accorde pas ces rôles comme indiqué ci-dessus. Si la source et la destination les ressources de l'organisation présentent l'ancien comportement, aucune action n'est requise, mais envisagez d'appliquer le règlement pour empêcher toute usurpation d'identité involontaire.

Migrer des projets avec Analytics Hub

Si vous migrez le projet qui utilise Analytics Hub vers un ressource d'organisation différente, vous risquez de rencontrer une erreur. À pour résoudre les éventuelles erreurs, contactez l'assistance.

Si la ressource d'échange de données de l'ancienne organisation visible sur la page administrateur Analytics Hub entreprise, utilisez l'API Analytics Hub pour mettre à jour les 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 valeur mise à jour du champ.

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 un autre ressource d'organisation. Lorsque le service est désactivé, une panne est en cours risque que vous devez prendre en compte. Vous devez réactiver le service de sauvegarde et de reprise après sinistre une fois la migration vers la nouvelle ressource Organisation terminée.

Étape suivante

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