En el caso de la migración de un proyecto, es necesario evaluar cómo afectará la migración a los servicios que se ejecutan en el proyecto. La API Resource Manager trata el recurso de 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 en el proyecto.
Aunque la migración no modificará directamente la configuración del proyecto, es probable que el cambio en la jerarquía de recursos afecte al funcionamiento del proyecto y de sus servicios en ejecución. Las políticas de la organización, las políticas de denegación y las políticas de permiso que se hereden en lugar de estar asociadas 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 estén vinculadas directamente al recurso. Esto puede provocar un comportamiento inesperado una vez que se haya completado la migración.
La migración de tu proyecto también puede provocar infracciones de las políticas de la organización, en función de las políticas de la organización del recurso de organización de destino.
Antes de migrar un proyecto entre recursos de organización, debes crear un plan de migración para determinar si tanto el recurso de organización como los proyectos que quieras migrar están preparados. En este plan de migración, haz un inventario de cada uno de los servicios que se ejecutan en tu proyecto y de cualquier otro servicio que pueda verse afectado por la migración o por la jerarquía de recursos del destino de tu proyecto.
Resumen del inventario
Usa Inventario de Recursos de Cloud para crear un resumen de los recursos en uso, incluidas las políticas de permiso. Puedes usar este resumen para ayudarte a definir tu plan de migración.
También puedes usar Inventario de Recursos de Cloud para transferir estos datos a BigQuery. De esta forma, podrás consultar los datos con SQL, que es más fácil de leer que los datos en formato JSON. Para obtener información sobre cómo exportar estos datos, consulta el artículo Exportar a BigQuery.
Para obtener una lista de todas las políticas de permitir y denegar que afectan al acceso a un proyecto, consulta Ver todas las políticas de permitir y denegar que se aplican a un recurso.
Verificación de políticas
Cuando migres tu proyecto, dejará de 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 efectiva en su destino. Te recomendamos que te asegures de que las políticas vigentes en el destino del proyecto coincidan lo máximo posible con las políticas que tenía el proyecto en su ubicación de origen.
Las políticas que se apliquen directamente al proyecto seguirán asociadas una vez que se complete la migración. Aplicar políticas directamente al proyecto es una buena forma de verificar que se aplican las políticas correctas desde el momento en que se completa la migración.
Las políticas de organización, de permitir y de denegar 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 en vigor en el destino del proyecto en tu jerarquía de recursos para asegurarte de que se ajusta a tus objetivos de gobernanza.
Gestionar claves cifradas
Debes comprobar si tu proyecto tiene una clave de encriptado gestionada por el cliente u otro servicio de Cloud Key Management Service habilitado. Las claves criptográficas son propiedad del proyecto y, por lo tanto, un usuario con acceso owner a ese proyecto podrá gestionar y realizar operaciones criptográficas en las claves de Cloud KMS de ese proyecto.
Para obtener más información, consulta el artículo sobre la separación de funciones.
Funciones de vista previa
Puedes habilitar las funciones de vista previa en recursos, carpetas o proyectos de la organización. Si has habilitado una función alfa o beta en el proyecto que se va a 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 permitidos del recurso de la organización de destino, no podrá hacer ningún cambio en la configuración una vez que se haya completado la migración.
Plan de restauración
Si detectas que algo no funciona en alguno de los proyectos que has migrado, puedes restaurarlos a su ubicación original. Para ello, debes tener los permisos de gestión de identidades y accesos necesarios y definir las políticas de la organización obligatorias para poder ejecutar la migración del proyecto en sentido inverso.
Para ver una lista de los permisos necesarios, consulta Asignar permisos. Para ver las políticas de la organización que debes configurar para permitir la migración de un proyecto, consulta Configurar políticas de la organización.
Carpetas de importación y exportación específicas
La herencia de políticas puede provocar efectos no deseados al migrar un proyecto, tanto en los recursos de la organización de origen como en los de la de destino. Puedes mitigar este riesgo creando carpetas específicas que contengan solo los proyectos que quieras exportar e importar, y asegurándote de que las carpetas de ambos recursos de organización hereden las mismas políticas. También puedes definir permisos en estas carpetas que se heredarán a los proyectos que se muevan a ellas, lo que te ayudará a acelerar el proceso de migración de proyectos.
Cuando planifiques una migración, te recomendamos que configures primero una carpeta de origen específica.
Para ello, cree una carpeta para cada recurso de la organización de destino a la que quiera exportar proyectos. A continuación, define una política de organización en estas carpetas, cada una con la restricción constraints/resourcemanager.allowedExportDestinations definida en el recurso de organización único al que quieras exportar los proyectos.
Por ejemplo, puedes configurar carpetas Export to Marketing Org y Export to Sales Org, cada una con las restricciones de políticas de organización adecuadas.
Del mismo modo, configure carpetas de importación específicas en el recurso de la organización de destino, una por cada recurso de la organización desde el que quiera importar proyectos. Para ello, cree una carpeta para cada recurso de la organización de origen desde la que vaya a importar proyectos. A continuación, define una política de la organización en estas carpetas, cada una con la restricción constraints/resourcemanager.allowedImportSources definida en el recurso de organización único desde el que quieras 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 organización adecuadas.
En cada una de las carpetas de importación y exportación, asigna el rol roles/resourcemanager.projectMover a la persona que vaya a mover los proyectos. Cualquier proyecto que se encuentre en estas carpetas heredará este rol, lo que permitirá al usuario realizar operaciones de movimiento en cualquier proyecto que se mueva a esas carpetas.
Una vez que hayas completado la migración del proyecto, debes eliminar estas carpetas específicas.
Para obtener información sobre cómo definir políticas de la organización, consulta Configurar políticas de la organización.
Siguientes pasos
Para asignar roles y permisos de Gestión de Identidades y Accesos para migrar proyectos entre organizaciones, consulta Asignar roles y permisos de Gestión de Identidades y Accesos.