En el caso de una migración de proyecto, es necesario evaluar cómo afectará la migración a los servicios que se ejecutan dentro del proyecto. La API de Resource Manager trata el recurso del proyecto y todos los servicios que se ejecutan en él como una sola unidad, lo que significa que no se aplicarán cambios de configuración dentro del proyecto.
Si bien la migración no realizará cambios de configuración directos en el proyecto, es probable que el cambio en la jerarquía de recursos afecte el funcionamiento del proyecto y sus servicios en ejecución. Las políticas de permiso, denegación o de organización que se heredan en lugar de adjuntarse directamente al proyecto no se migrarán con el proyecto durante la migración. Se migrarán las políticas de la organización y las cuentas de servicio que se adjuntan directamente al recurso. Esto puede provocar un comportamiento no deseado después de que se complete la migración.
La migración de tu proyecto también puede generar incumplimientos de políticas de la organización, según las políticas de la organización del recurso de organización de destino.
Antes de migrar tu proyecto entre recursos de organización, debes considerar la posibilidad de crear un plan de migración para determinar la preparación tanto de tu recurso de organización como de los proyectos que deseas migrar. En este plan de migración, haz un inventario de cada uno de los servicios que ejecuta tu proyecto y de cualquier otro servicio que pueda verse afectado por la migración o por la jerarquía de recursos en el destino de tu proyecto.
Descripción general de Inventory
Usa Cloud Asset Inventory para crear un resumen de los recursos en uso, incluidas las políticas de permisos. Puedes usar esta descripción general para ayudarte a delinear tu plan de migración.
También puedes usar Cloud Asset Inventory para transferir estos datos a BigQuery. Esto te permitirá consultar los datos con SQL, que es más fácil de leer en comparación con la interpretación de datos con formato JSON. Para obtener información sobre cómo exportar estos datos, consulta Exporta a BigQuery.
Para obtener una lista de todas las políticas de permiso y denegación que afectan el acceso a un proyecto, consulta Visualiza todas las políticas de permiso y denegación que se aplican a un recurso.
Verificación de políticas
Cuando migres tu proyecto, ya no heredará las políticas de su ubicación actual en la jerarquía de recursos y estará sujeto a la evaluación de políticas vigentes en su destino. Te recomendamos que te asegures de que las políticas vigentes en el destino del proyecto coincidan lo más posible con las políticas que el proyecto tenía en su ubicación de origen.
Las políticas que se apliquen directamente al proyecto seguirán adjuntas después de que se complete la migración. Aplicar políticas directamente al proyecto es una buena manera de verificar que se apliquen las políticas correctas desde el momento en que se completa la migración.
Las políticas de organización, de permiso y de denegación se heredan a través de la jerarquía de recursos y pueden impedir que un servicio funcione si no se configuran correctamente. Determina la política vigente en el destino del proyecto en tu jerarquía de recursos para asegurarte de que la política se alinee con tus objetivos de administración.
Administra claves encriptadas
Debes verificar si tu proyecto tiene una clave encriptada administrada por el cliente o algún otro servicio de Cloud Key Management Service habilitado. Las claves criptográficas son propiedad del proyecto, por lo que un usuario con acceso owner a ese proyecto podrá administrar y realizar operaciones criptográficas en las claves de Cloud KMS en ese proyecto.
Consulta Separación de obligaciones para obtener más información.
Funciones de versión preliminar
Puedes habilitar las funciones en versión preliminar en los recursos, las carpetas o los proyectos de la organización. Si habilitaste una función alfa o beta en el proyecto que se migrará, esta función debería seguir funcionando después de la migración. Si la función de vista previa es privada y no está en la lista de entidades permitidas para el recurso de la organización de destino, no podrás realizar ningún cambio de configuración después de que se complete la migración.
Plan de reversión
Si descubres que algo no funciona en alguno de los proyectos que migraste, puedes restablecerlos a su ubicación original. Para ello, debes tener los permisos de IAM necesarios y establecer las políticas de la organización requeridas para poder ejecutar la migración del proyecto en sentido inverso.
Para obtener una lista de los permisos necesarios, consulta Asigna permisos. Para conocer las políticas de la organización que debes configurar para permitir la migración de un proyecto, consulta Configura políticas de la organización.
Carpetas dedicadas para importar y exportar
La herencia de políticas puede causar efectos no deseados cuando migras un proyecto, tanto en los recursos de la organización de origen como en los de destino. Puedes mitigar este riesgo creando carpetas específicas para contener solo los proyectos de exportación e importación, y asegurándote de que las carpetas de ambos recursos de la organización hereden las mismas políticas. También puedes establecer permisos en estas carpetas que se heredarán en los proyectos que se muevan dentro de ellas, lo que ayudará a acelerar el proceso de migración de proyectos.
Cuando planifiques una migración, considera configurar primero una carpeta de origen dedicada.
Para ello, crea una carpeta para cada recurso de organización de destino al que planeas exportar proyectos. Luego, establece una política de la organización en estas carpetas, cada una con la restricción constraints/resourcemanager.allowedExportDestinations establecida en el único recurso de organización al que deseas exportar proyectos.
Por ejemplo, puedes configurar carpetas Export to Marketing Org y Export to Sales Org, cada una con las restricciones de política de la organización adecuadas.
De manera similar, configura carpetas de importación dedicadas en el recurso de organización de destino, una para cada recurso de organización desde el que deseas importar proyectos. Para ello, crea una carpeta para cada recurso de organización de origen desde el que planeas importar proyectos. Luego, establece una política de la organización en estas carpetas, cada una con la restricción constraints/resourcemanager.allowedImportSources establecida en el único recurso de organización desde el que deseas importar proyectos.
Por ejemplo, puedes configurar carpetas Import from Marketing Org y Import from App Development Org, cada una con las restricciones de políticas de la organización adecuadas.
En cada una de las carpetas de importación y exportación, asigna el rol de roles/resourcemanager.projectMover a la persona que moverá los proyectos. Cualquier proyecto contenido en estas carpetas heredará este rol, lo que le permitirá al usuario realizar operaciones de movimiento en cualquier proyecto que se mueva a esas carpetas.
Después de completar la migración del proyecto, debes quitar estas carpetas dedicadas.
Para obtener información sobre cómo establecer políticas de la organización, consulta Configura políticas de la organización.
¿Qué sigue?
Para asignar roles y permisos de Identity and Access Management para migrar proyectos entre organizaciones, consulta Asigna roles y permisos de Identity and Access Management.