Migra proyectos

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

En esta guía, se explica cómo mover un proyecto entre recursos de la organización o lugares dentro de una jerarquía de recursos.

El recurso del proyecto es la entidad organizadora básica en un recurso de organización de Google Cloud. Los proyectos se crean en los recursos de la organización y se pueden ubicar en carpetas o en el recurso de la organización en sí, lo que forma la jerarquía de recursos. Es posible que debas migrar proyectos entre recursos de la organización debido a adquisiciones, requisitos regulatorios y separación entre las unidades de negocios, entre otras cosas.

Puedes usar la API de Resource Manager para mover proyectos entre los recursos de la organización o en otro lugar de la jerarquía de recursos de su recurso de organización actual. La API de Resource Manager también te permite revertir la migración y volver al proyecto a su ubicación original en la jerarquía de recursos.

Crea un plan de migración

Lo más importante que debes considerar durante el traslado de un proyecto es cómo la migración afectará 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 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 tenga un impacto en la función del proyecto y sus servicios en ejecución. Las políticas heredadas, como las de administración de identidades y accesos o las políticas de la organización, no se moverán con el proyecto durante la migración, solo las políticas y las cuentas de servicio que se adjuntan directamente al recurso. Esto puede causar un comportamiento no deseado después de que se complete la migración.

Mover tu proyecto también puede generar incumplimientos de la política de la organización, según las políticas de la organización de recursos de la organización de destino.

Antes de mover tu proyecto, debes considerar crear un plan de migración para determinar la preparación de tu organización y de los proyectos que deseas trasladar. 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 el traslado o por la jerarquía de recursos en el destino de tu proyecto.

Descripción general de Inventory

Usa Cloud Asset Inventory para crear una descripción general de los recursos en uso, incluidas las políticas de administración de identidades y accesos. Puedes usar esta descripción general para definir 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 en formato JSON. Para obtener información sobre cómo exportar estos datos, consulta Exporta a BigQuery.

Verificación de políticas

Cuando migres tu proyecto, ya no heredará las políticas de su lugar actual en la jerarquía de recursos y estará sujeto a la evaluación de políticas vigente en su destino. Te recomendamos asegurarte de que las políticas vigentes en el destino del proyecto coincidan tanto como sea posible con las políticas que tenía el proyecto en su ubicación de origen.

Cualquier política que se aplique directamente al proyecto se adjuntará una vez 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 el traslado.

Las políticas de administración de identidades y accesos y las políticas de la organización se heredan a través de la jerarquía de recursos y pueden bloquear el funcionamiento de un servicio si no se configura de forma correcta. Determina la política vigente en el destino del proyecto en la jerarquía de recursos para asegurarte de que la política se alinee con los 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 y, por lo tanto, un usuario con acceso owner a ese proyecto podrá administrar y realizar operaciones criptográficas en las claves de Cloud KMS de ese proyecto.

Consulta Separación de obligaciones para obtener más información.

Funciones de vista previa

Puedes habilitar las funciones de vista previa en la organización, la carpeta o los recursos del proyecto. Si habilitaste una función Alfa o Beta en el proyecto, esta debería seguir funcionando después de la migración. Si la función de vista previa es privada y no está incluida en la lista de entidades permitidas del recurso de la organización de destino, no podrás realizar cambios de configuración una vez que se complete el traslado.

Revertir plan

Si descubres que algo no funciona en ninguno de los proyectos que migraste, puedes volver a colocarlos en su ubicación original. Para ello, debes tener los permisos de IAM necesarios y establecer las políticas de la organización necesarias a fin de poder ejecutar la migración del proyecto a la inversa.

Para obtener una lista de los permisos necesarios, consulta Cómo asignar permisos. Si deseas ver las políticas de la organización que debes configurar para permitir una migración de proyecto, consulta Configura las políticas de la organización.

Carpetas de importación y exportación dedicadas

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 de destino. Puedes mitigar este riesgo si creas carpetas específicas que contengan solo proyectos para importar y exportar, y asegúrate de que las carpetas que se encuentran en ambos recursos de organización hereden las mismas políticas. También puedes establecer permisos en estas carpetas que se heredarán en los proyectos dentro de ellas, lo que ayudará a acelerar el proceso de migración del proyecto.

Cuando planifiques una migración, considera configurar primero una carpeta de origen dedicada. Para ello, crea una carpeta para cada recurso de organización al que desees exportar proyectos. Luego, configura una política de la organización en estas carpetas, cada una con la restricción constraints/resourcemanager.allowedExportDestinations establecida en el recurso de la organización único al que deseas exportar proyectos.

Por ejemplo, puedes configurar las carpetas Export to Marketing Org y Export to Sales Org, cada una con las restricciones de política de la organización correspondientes.

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 desees importar proyectos. A fin de hacer esto, crea una carpeta para cada recurso de organización desde el que planeas importar proyectos. Luego, configura una política de la organización en estas carpetas, cada una con la restricción constraints/resourcemanager.allowedImportSources establecida en el recurso de la organización único desde el que deseas importar proyectos.

Por ejemplo, puedes configurar las carpetas Import from Marketing Org y Import from App Development Org, cada una con las restricciones de política de la organización establecidas.

En cada una de las carpetas de importación y exportación, asigna a la persona que moverá los proyectos la función roles/resourcemanager.projectMover. Esta función será heredada por cualquier proyecto que se encuentre dentro de estas carpetas, lo que le da al usuario la capacidad de realizar las operaciones de movimiento en cualquier proyecto que se mueva a esas carpetas.

Después de completar la migración de tu proyecto, debes quitar estas carpetas dedicadas.

Para obtener información sobre la configuración de políticas de la organización, consulta Configura políticas de la organización.

Asignación de permisos

Necesitas los siguientes permisos para mover un proyecto entre los recursos de la organización.

Para obtener estos permisos, pídele al administrador que otorgue la función sugerida en el nivel adecuado de la jerarquía de recursos.

Permisos de transferencia del proyecto

Para mover un proyecto, necesitas las siguientes funciones en el proyecto, su recurso superior y el recurso de destino:

  • Administrador de IAM del proyecto (roles/resourcemanager.projectIamAdmin) en el proyecto que deseas mover
  • Migrador de proyecto (roles/resourcemanager.projectMover) en el recurso superior del proyecto
  • Si el recurso de destino es una carpeta: Migrador de proyecto (roles/resourcemanager.projectMover) en el recurso de destino
  • Si el recurso de destino es una organización: Creador del proyecto (roles/resourcemanager.projectCreator) en el recurso de destino

Estas funciones te otorgan los siguientes permisos obligatorios:

Permisos necesarios

  • resourcemanager.projects.getIamPolicy en el proyecto que deseas mover
  • resourcemanager.projects.update en el proyecto que deseas mover
  • resourcemanager.projects.move en el recurso superior del proyecto
  • Si el recurso de destino es una carpeta: resourcemanager.projects.move en el recurso de destino
  • Si el recurso de destino es una organización: resourcemanager.projects.create en el recurso de destino

También puedes obtener estos permisos con una función personalizada o con otras funciones predefinidas.

Permisos de la política de la organización

En los recursos de la organización de origen y de destino, debes tener la función roles/orgpolicy.policyAdmin, que otorga permiso para crear y administrar políticas de la organización.

Permisos de la cuenta de facturación

Las cuentas de facturación de Cloud se pueden usar en los recursos de la organización. Transferir un proyecto de un recurso de la organización a otro no afectará la facturación, y los cargos se seguirán generando en la cuenta de facturación anterior. Sin embargo, los traslados de recursos de la organización a menudo también incluyen un requisito para pasar a una cuenta de facturación nueva.

Para obtener los permisos que necesitas para cambiar la cuenta de facturación del proyecto, pídele al administrador que te otorgue las siguientes funciones de IAM:

  • Usuario de la cuenta de facturación (roles/billing.user) en la cuenta de facturación de destino
  • Administrador de facturación del proyecto (roles/billing.projectManager) en el proyecto

Para obtener más información sobre cómo otorgar funciones, consulta Administra el acceso.

Estas funciones predefinidas contienen los permisos necesarios para cambiar la cuenta de facturación del proyecto. Para ver los permisos exactos que son necesarios, expande la sección Permisos requeridos:

Permisos necesarios

  • billing. resourceAssociations.create en la cuenta de facturación de destino
  • resourcemanager.projects.createBillingAssignment en el proyecto
  • resourcemanager.projects.deleteBillingAssignment en el proyecto

También puedes obtener estos permisos con roles personalizados o con otros roles predefinidos.

Configura políticas de la organización

Para mover un recurso del proyecto a un recurso de la organización nuevo, primero debes aplicar una política de la organización que defina los recursos de la organización a los que se puede mover el proyecto. También debes establecer una política de la organización en el destino que defina los recursos de la organización desde los que se pueden importar proyectos.

En el recurso superior del proyecto que deseas mover, configura una política de la organización que incluya la restricción constraints/resourcemanager.allowedExportDestinations. Esto definirá el destino de destino como una ubicación válida a la que puedes migrar el proyecto.

En el recurso de destino, establece una política de la organización que incluya la restricción constraints/resourcemanager.allowedImportSources. Esto definirá la fuente como una ubicación válida desde la que puedes migrar tu proyecto.

Por ejemplo, supongamos que tienes un proyecto my-test-project que existe en un recurso de organización con el ID 12345678901 y deseas moverlo a un nuevo recurso de organización para la unidad de negocios secundaria, con el ID 45678901234.

Debes establecer una política de la organización en organizations/12345678901 con la restricción constraints/resourcemanager.allowedExportDestinations aplicada y under:organizations/45678901234 configurado como allowed_value.

Luego, configura una política de la organización en organizations/45678901234 con la restricción constraints/resourcemanager.allowedImportSources aplicada y under:organizations/12345678901 configurada como allowed_value.

Una vez que se apliquen las políticas de la organización, podrás mover my-test-project desde organizations/12345678901 a organizations/45678901234, si tienes los permisos indicados en Asignar permisos.

Cambia la cuenta de facturación para un proyecto

Las cuentas de facturación de Cloud se pueden usar en los recursos de la organización. Transferir un proyecto de un recurso de la organización a otro no afectará la facturación, y los cargos se seguirán generando en la cuenta de facturación anterior. Sin embargo, los traslados de recursos de la organización a menudo también incluyen un requisito para pasar a una cuenta de facturación nueva.

Para cambiar la cuenta de facturación, haz lo siguiente:

  1. Ve a la página Facturación en Google Cloud Console.
    Ir a la página Facturación
  2. Haz clic en el nombre de la cuenta de facturación que deseas cambiar.
  3. En Proyectos vinculados a esta cuenta de facturación, busca el nombre del proyecto que deseas mover y haz clic en el botón de menú que se encuentra a la derecha.
  4. Haz clic en Cambiar facturación y, luego, selecciona la cuenta de facturación nueva.
  5. Haz clic en Establecer la cuenta.

Los cargos que ya se realizaron, pero que todavía no se informaron en el historial de transacciones se facturarán a la cuenta de facturación anterior. Esto puede incluir cargos de hasta dos días antes del momento en que se movió el proyecto.

Transfiere una cuenta de facturación entre los recursos de la organización

Una cuenta de facturación se puede mover de un recurso de organización a otro, aunque esto no suele ser un paso necesario. La mayoría de los recursos existentes de la organización ya tendrán una cuenta de facturación que se debe usar en su lugar. Si necesitas migrar una cuenta de facturación existente, sigue estos pasos:

  1. Obtén la función roles/billing.admin en los recursos de la organización de origen y de destino.
  2. Ve a la página Facturación en Google Cloud Console.
    Ir a la página Facturación
  3. Haz clic en el nombre de la cuenta de facturación que deseas mover.
  4. En la parte superior de la página Administración de cuentas, haga clic en Cambiar organización.
  5. Selecciona el recurso de la organización de destino y, luego, haz clic en Aceptar.

La cuenta de facturación ahora está asociada con el recurso de organización especificado.

Realice la migración

Si tienes los permisos de IAM adecuados y se aplican las políticas de la organización necesarias, puedes usar la API de Resource Manager para mover un recurso del proyecto.

gcloud

Para migrar un proyecto a otro recurso de la organización, ejecuta el siguiente comando:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

También puedes especificar una carpeta como recurso de destino con el siguiente comando:

gcloud beta projects move PROJECT_ID \
    --folder FOLDER_ID

Donde:

  • PROJECT_ID es el ID o el número del proyecto que deseas migrar.
  • ORGANIZATION_ID es el ID del recurso de la organización al que deseas mover el proyecto. Solo puedes especificar un destino, ya sea un recurso de organización o una carpeta.
  • FOLDER_ID es el ID de la carpeta a la que deseas mover el proyecto. Solo puedes especificar un destino, ya sea una carpeta o un recurso de organización.

API

Con la API de Resource Manager v1, puedes mover un proyecto si configuras su campo parent con el ID del recurso de destino.

Para migrar un proyecto, sigue estos pasos:

  • Obtén el objeto project con el método projects.get().
  • Establece su campo parent en el ID de recurso de organización del recurso de organización o en el ID de carpeta de la carpeta a la que lo mueves.
  • Actualiza el objeto project con el método projects.update().

El siguiente fragmento de código demuestra los siguientes pasos:

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

    project = crm.projects().update(
    projectId=flags.projectId, body=project).execute()

Revierte una migración

Si moviste un proyecto por error, puedes revertir la operación si vuelves a realizar el traslado, con la fuente anterior como el destino nuevo y el destino anterior como la fuente nueva. Debes tener los permisos de IAM y las políticas de la organización necesarios para permitir esto como si fuera una migración completamente nueva.

Maneja casos especiales

Migra proyectos sin recursos de la organización

Puedes migrar un proyecto que no está asociado con un recurso de organización en un recurso de organización. Sin embargo, con este proceso no puedes cambiarlo a Sin organización. Si tienes un proyecto asociado con el recurso de tu organización y deseas revertirlo a Sin organización, comunícate con tu representante de asistencia para obtener ayuda.

El proceso para migrar un proyecto que no está asociado con un recurso de organización es similar al proceso de migración de un proyecto entre recursos de la organización, pero no requiere todos los pasos involucrados en el plan de migración. Para migrar un proyecto a un recurso de la organización, debes seguir estos pasos:

  1. Verifica el impacto en este proyecto de las políticas que heredará.

  2. Si lo deseas, crea una carpeta de importación dedicada en el recurso de organización de destino.

  3. Asigna permisos de administración de identidades y accesos para el proyecto y el superior de destino como se detalla en Asigna permisos.

  4. Determina si necesitas cambiar la cuenta de facturación.

Luego, puedes realizar la migración.

Console

Para migrar un proyecto a un recurso de la organización, sigue estos pasos:

  1. Abre la página Configuración de IAM en Google Cloud Console.

    Abrir la página Configuración

  2. Selecciona el Selector de proyectos en la parte superior de la página.

  3. En el Selector de organización, selecciona Sin organización. Si no estás asociado a ningún recurso de la organización, el selector de organización no aparecerá y podrás omitir este paso.

  4. Selecciona el proyecto que deseas migrar.

    Captura de pantalla del selector de proyectos

  5. Haz clic en Migrar en la parte superior de la página.

  6. En la lista desplegable Organización, selecciona el recurso de la organización al que deseas migrar tu proyecto.

gcloud

Para migrar un proyecto a un recurso de la organización, ejecuta el siguiente comando:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Donde:

  • PROJECT_ID es el ID del proyecto que deseas mover al recurso de la organización.
  • ORGANIZATION_ID es el ID del recurso de la organización al que deseas mover el proyecto.

API

Con la API de Resource Manager, puedes mover un proyecto al recurso de la organización si configuras el campo parent con el ID de recurso de la organización.

Para migrar un proyecto al recurso de la organización:

  • Obtén el objeto project con el método projects.get().
  • Configura su campo parent con el ID de recurso de la organización.
  • Actualiza el objeto project con el método projects.update().

No se puede modificar el campo parent luego de configurarlo.

El siguiente fragmento de código demuestra los siguientes pasos:

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

VPC compartida

Los proyectos de VPC compartida se pueden migrar según ciertas condiciones. Primero, un usuario con la función roles/orgpolicy.policyAdmin en la organización de origen debe establecer una política de la organización que contenga la restricción constraints/resourcemanager.allowEnabledServicesForExport en el elemento superior del proyecto que se exportará. Esta restricción debe enumerar SHARED_VPC como allowed_value.

Primero, se debe migrar el proyecto host de VPC compartida y, luego, todos sus proyectos de servicio. Recomendamos hacer coincidir las reglas de firewall entre las organizaciones en las ubicaciones de origen y destino, lo que debería minimizar los posibles problemas y evitar cualquier tiempo de inactividad para los proyectos y la red durante la migración. No ofrecemos garantías sobre el buen estado de tu red si dejas algunos proyectos de servicio en la organización de origen de forma indefinida mientras migras otros.

Si mueves el proyecto host, puedes volver a moverlo a la organización de origen, pero una vez que comiences a mover los proyectos de servicio, debes moverlos todos antes de poder mover el proyecto host nuevamente.

Funciones de administración de identidades y accesos personalizadas

Las funciones personalizadas de administración de identidades y accesos se pueden crear a nivel de organización para proporcionar un control detallado del acceso a los recursos, pero solo son válidos en el recurso de la organización en el que se crean. Si intentas mover un proyecto que contiene una vinculación de política de IAM de un usuario a una función de IAM personalizada a nivel de la organización, el traslado fallará y mostrará un error de condición previa con errores, lo que explica que la función en cuestión no existe en el recurso de organización de destino.

Para enumerar todas las funciones de IAM personalizadas a nivel del recurso de tu organización, ejecuta el siguiente comando de Google Cloud CLI:

gcloud iam roles list --organization ORGANIZATION_ID

En el que ORGANIZATION_ID es el ID de recurso de la organización para el que deseas enumerar las funciones. Para obtener información sobre cómo encontrar el ID del recurso de la organización, consulta Crea y administra recursos de la organización.

Para obtener información sobre una función personalizada de administración de identidades y accesos en el recurso de tu organización, ejecuta el siguiente comando de Google Cloud CLI:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Donde:

  • ORGANIZATION_ID es el ID de recurso de la organización del recurso de organización superior de la función.

  • ROLE_ID es el nombre de la función que deseas describir.

A fin de solucionar el error de la condición previa con errores, debes crear funciones personalizadas a nivel de proyecto para cada una de las funciones personalizadas a nivel de la organización que hereda el proyecto. Luego, quita las vinculaciones de funciones de IAM que hacen referencia a las funciones personalizadas a nivel de la organización.

Una vez migrado el proyecto, puedes actualizar las políticas de IAM para usar las funciones personalizadas a nivel de la organización en el recurso de organización de destino.

Para obtener información sobre las funciones personalizadas, consulta Crea y administra funciones personalizadas.

Bloqueo del bucket

El bloqueo del bucket de Cloud Storage te permite configurar una política de retención de datos en un bucket de Cloud Storage que regula por cuánto tiempo se retienen los objetos en el bucket. El bloqueo del bucket se protege con una retención para evitar borrar el proyecto por accidente.

La política de retención y la retención se conservan con el proyecto durante una migración, pero debes tener en cuenta si mueves un proyecto con un bloqueo de bucket aplicado y evitas los movimientos accidentales.

Perímetros de seguridad de los Controles del servicio de VPC

Los Controles del servicio de VPC permiten a los usuarios configurar un perímetro de seguridad basado en proyectos alrededor de sus servicios de Google Cloud para mitigar los riesgos de robo de datos. No puedes migrar un proyecto que esté protegido por un perímetro de seguridad de los Controles del servicio de VPC.

Para quitar un proyecto de un perímetro de seguridad, consulta Administra perímetros de servicio. Es posible que los proyectos en los perímetros de los Controles del servicio de VPC no se bloqueen para que se muevan entre los recursos de la organización hasta un día después de que se crea o actualiza un perímetro. Es posible que el proyecto tarde varias horas en moverse si ya no está fuera del perímetro de servicio.

Interconexión dedicada

Recomendamos migrar proyectos con objetos de interconexión dedicada y proyectos con adjuntos de VLAN a estos objetos de interconexión dedicada en conjunto. Si bien los proyectos con objetos de interconexión dedicada o adjuntos de VLAN conectados a ellos se pueden migrar y funcionarán entre recursos de la organización, no podrás crear nuevos adjuntos de VLAN en la división de recursos de la organización.

Los cambios de configuración realizados en un proyecto en un recurso de organización que tiene un objeto de interconexión dedicada adjunta o un adjunto de VLAN en el objeto de interconexión dedicada pueden no propagarse al otro, por lo que recomendamos no dejar esos proyectos divididos entre los recursos de la organización por mucho tiempo, si es posible.

Interconexión de socio

No se necesitan consideraciones especiales cuando se migran proyectos con la interconexión de socio.

Cuentas de servicio entre proyectos

Si transfieres un proyecto que tiene una cuenta de servicio entre proyectos adjunta, esa cuenta seguirá funcionando en el recurso de organización de destino. Ese proyecto seguirá funcionando con la cuenta de servicio vinculada, incluso si hay una política de la organización que restringa el dominio de ese proyecto.

Si transfieres un proyecto que posee una cuenta de servicio entre proyectos vinculada a otro proyecto en el recurso de la organización de origen, la cuenta de servicio seguirá funcionando en el recurso de organización de destino. Sin embargo, no podrás usar la cuenta de servicio en ningún recurso que tenga aplicada una política de la organización de restricción de dominio que los restrinja al dominio del recurso de la organización de origen.

Por ejemplo, supongamos que tienes project-A en organizations/12345678901. Este proyecto tiene serviceAccount-1 adjunto, que se configura como una cuenta de servicio entre proyectos. project-B y project-C, también en organizations/12345678901, también usan serviceAccount-1.

Aplicaste una política de la organización con la restricción de dominio a project-C, que solo le permite acceder al dominio de organizations/12345678901.

Si agregas serviceAccount-1 a la vinculación de IAM para project-C y, luego, mueves project-A a organizations/45678901234, la cuenta de servicio funcionará.

Si mueves project-A a organizations/45678901234 y, luego, intentas agregar serviceAccount-1 a la vinculación de IAM para project-C, la vinculación fallará, ya que infringe la restricción de dominio.

Casos de asistencia

Si mueves un proyecto que tiene un caso de asistencia abierto, debes comunicarte con el contacto de Atención al cliente de Google para informarle que la migración se produjo. Cualquier proyecto que tenga un caso de ayuda abierto con Google no podrá verlos hasta que la asistencia de Google actualice los metadatos del caso para apuntar al nuevo recurso de la organización.

Si tu proyecto está configurado para usar una pantalla de consentimiento de OAuth interna y lo migras a otro recurso de organización, solo los miembros del recurso de organización de destino podrán autorizar solicitudes. Este comportamiento puede tardar hasta 24 horas en aplicarse. Hasta ese momento, los miembros del recurso de organización de origen autorizarán las solicitudes.

En los siguientes pasos, se explica cómo garantizar que los miembros del recurso de la organización de origen no pierdan el acceso durante la migración. Considera crear usuarios nuevos en el recurso de organización de destino para los miembros de recursos de la organización a fin de que no tengas que cambiar la configuración de la pantalla de consentimiento de OAuth.

A fin de evitar la pérdida de acceso para los miembros del recurso de la organización de origen, sigue estos pasos:

  1. Actualiza la pantalla de consentimiento de OAuth para que sea externa en lugar de interna.

  2. Las apps que están marcadas como internas y usan datos sensibles no necesitan solicitar la verificación. Si la app usa datos sensibles, cuando la pantalla de consentimiento se actualice a una externa, los usuarios del recurso de la organización de origen verán una pantalla de app no verificada antes de la pantalla de autorización. Para evitar esto, solicita la verificación de la app a fin de usar alcances sensibles o restringidos.

Acceso al SO

Si el Acceso al SO está habilitado en tu proyecto de origen, asigna la función de IAM roles/compute.osLoginExternalUser a las principales que pueden acceder al proyecto de origen, en el recurso de organización de destino, para evitar que las principales pierdan el acceso.

Conecta cuentas de servicio a recursos

En la mayoría de los servicios de Google Cloud, los usuarios necesitan el permiso iam.serviceAccounts.actAs en una cuenta de servicio para conectarla a un recurso. Sin embargo, en el pasado, para facilitar la integración de ciertos servicios, los usuarios podían adjuntar cuentas de servicio a los recursos aunque estos no tuvieran permiso para actuar en nombre de las cuentas de servicio. Esto se documenta aquí.

Si el recurso de la organización de origen de un cliente tiene el comportamiento heredado (el adjunto de cuentas de servicio es posible sin la función normal otorgada), y el recurso de organización de destino no, otorga roles/iam.serviceAccountUser a los usuarios que adjuntan estas cuentas de servicio a los recursos. Para obtener información sobre cómo suplantar cuentas de servicio, consulta Robo de identidad de cuentas de servicio.

Para ver si el recurso de tu organización tiene el comportamiento heredado, haz lo siguiente:

  1. En Google Cloud Console, ve a la página Políticas de la organización.

    Ir a la página Políticas de la organización

  2. En el selector de proyectos de la parte superior de la página, elige el recurso de la organización que deseas verificar para el estado heredado.

  3. En el cuadro de filtro en la parte superior de la lista de políticas de la organización, ingresa constraints/appengine.enforceServiceAccountActAsCheck.

  4. Si la política de la organización appengine.enforceServiceAccountActAsCheck aparece en la lista, el recurso de la organización tiene el comportamiento heredado.

  5. Repite los pasos 3 y 4 para cada una de las siguientes restricciones de la política de la organización:

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck
  6. Si aparece alguna de estas restricciones de la política de la organización, el recurso de la organización usa el comportamiento heredado.

Si el recurso de la organización de origen tiene el comportamiento heredado y el destino no, otorga las funciones como se mencionó antes. Si los recursos de la organización de origen y de destino tienen el comportamiento heredado, no se requiere ninguna acción, pero considera aplicar la política para evitar el robo de identidad no deseado.

Migra proyectos con Analytics Hub

Si migras el proyecto que usa Analytics Hub a un recurso de la organización diferente, es posible que se produzca algún error. Para solucionar cualquier error, comunícate con el equipo de asistencia.