Migra proyectos

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

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

Puedes usar la API de Resource Manager para mover proyectos de todos los recursos de la organización o a otro lugar en 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 regresar el 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 un traslado del 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 debajo de é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 tenga un impacto en la función del proyecto y en sus servicios en ejecución. Las políticas heredadas, como las de administración de identidades y accesos, o las políticas de organización, no se moverán con el proyecto durante la migración, solo las políticas y cuentas de servicio que están directamente vinculadas al recurso. Esto puede causar un comportamiento no deseado después de que se complete la migración.

El traslado del proyecto también puede provocar incumplimientos de la política de la organización, según las políticas de la organización de recursos de destino.

Antes de trasladar tu proyecto, te recomendamos crear un plan de migración para determinar la preparación de tu organización y de los proyectos que deseas mover. En este plan de migración, toma 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 la jerarquía de recursos del 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 describir tu plan de migración.

También puedes usar Cloud Asset Inventory para transferir estos datos a BigQuery. Esto te permitirá consultar los datos mediante 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 Cómo exportar a BigQuery.

Verificación de políticas

Cuando migres el 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. Recomendamos asegurarte de que las políticas vigentes en el destino del proyecto coincidan tanto como sea posible con las políticas que el proyecto tenía en la ubicación de origen.

Todas las políticas que se apliquen directamente al proyecto se adjuntarán 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 complete 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 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 habilitada una clave encriptada para el cliente o algún otro servicio de Cloud Key Management Service. 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 los recursos de organización, de carpeta o de proyecto. Si habilitaste una función Alfa o Beta en el proyecto, esta debe 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 organización de destino, no podrás realizar cambios en la configuración una vez que se complete el traslado.

Plan de reversión

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

Para obtener una lista de los permisos requeridos, consulta Cómo asignar permisos. Consulta las políticas de la organización que debes configurar para permitir la migración de un proyecto en 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 organización de origen como de destino. A fin de mitigar este riesgo, crea carpetas específicas para contener solo proyectos para importación y exportación, y asegúrate de que las mismas políticas sean heredadas por las carpetas en ambos recursos de organización. También puedes configurar permisos en estas carpetas que se heredarán a los proyectos trasladados 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 fuente dedicada. Si quieres hacerlo, crea una carpeta para cada recurso de organización al que planeas exportar proyectos. Luego, configura una política de la organización en estas carpetas, cada una con la restricción constraints/resourcemanager.allowedExportDestinations configurada en el único recurso de la organización 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. Para ello, crea una carpeta para cada recurso de organización desde el que desees 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 correspondientes.

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

Una vez que hayas completado la migración de tu proyecto, debes quitar estas carpetas dedicadas.

Para obtener información sobre cómo configurar 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 a tu administrador que otorgue la función sugerida en el nivel adecuado de la jerarquía de recursos.

Permisos de traslado del proyecto

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

  • Administrador de IAM de 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: Project Mover (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 le otorgan los siguientes permisos necesarios:

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 y otras funciones predefinidas.

Permisos de las políticas de la organización

En los recursos de 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 todos los recursos de la organización. Si trasladas un proyecto de un recurso de organización a otro, la facturación no se verá afectada, y los cargos se seguirán aplicando a la cuenta de facturación anterior. Sin embargo, los traslados de recursos de la organización a menudo también incluyen un requisito para migrar 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 roles, 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.

Configurar políticas de la organización

Para mover un recurso de proyecto a un recurso de 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, configura una política de la organización que incluya la restricción constraints/resourcemanager.allowedImportSources. Esto definirá que la fuente es 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 trasladarlo a un nuevo recurso de organización para tu unidad de negocios secundaria, con el ID 45678901234.

Configura una política de la organización en organizations/12345678901 con la restricción constraints/resourcemanager.allowedExportDestinations aplicada y under:organizations/45678901234 configurada 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 todos los recursos de la organización. Si trasladas un proyecto de un recurso de organización a otro, la facturación no se verá afectada, y los cargos se seguirán aplicando a la cuenta de facturación anterior. Sin embargo, los traslados de recursos de la organización a menudo también incluyen un requisito para migrar 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 de 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 este no suele ser un paso necesario. La mayoría de los recursos de la organización existentes ya tendrán una cuenta de facturación que se debe usar en su lugar. Si necesitas migrar una cuenta de facturación existente, haz lo siguiente:

  1. Obtén la función roles/billing.admin en los recursos de organización de origen y de destino.
  2. Ve a la página Facturación de 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 organización de destino y, luego, haz clic en Ok.

La cuenta de facturación ahora está asociada al recurso de la 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 organización, ejecuta el siguiente comando:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

También puedes especificar una carpeta como el 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().
  • Configura su campo parent con el ID de recurso de la organización del recurso de organización, o bien el ID de carpeta de la carpeta a la que lo moverás.
  • 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 el proyecto por error, puedes revertir la operación si vuelves a realizar el traslado, con la fuente antigua como destino nuevo y el destino anterior como la fuente nueva. Debes tener implementados los permisos de IAM y las políticas de la organización necesarios para permitir esto como si se tratara de una migración completamente nueva.

Maneja casos especiales

Migra proyectos sin recursos de organización

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

El proceso para migrar un proyecto que no está asociado a un recurso de la organización es similar al proceso para migrar un proyecto entre los recursos de la organización, pero no se requieren 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 de las políticas que heredará en este proyecto.

  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 del destino, como se detalla en Asigna permisos.

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

Luego, puedes realizar la migración.

Console

Sigue estos pasos para migrar un proyecto a un recurso de organización:

  1. Abre la página IAM & amp; Admin en la consola.

    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 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 transferir 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 transferir un proyecto al recurso de la organización si configuras el campo parent con el ID de recurso de la organización del recurso de organización.

Para migrar un proyecto al recurso de la organización, haz lo siguiente:

  • Obtén el objeto project con el método projects.get().
  • Configura su campo parent con el ID de recurso de la organización del recurso de 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 en función de 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 un allowed_value.

Primero, se debe migrar el proyecto host de VPC compartida, seguido de todos sus proyectos de servicio. Te recomendamos hacer coincidir las reglas de firewall entre las organizaciones en las ubicaciones de origen y de 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 cambiarlo a la organización de origen, pero una vez que comiences a trasladar los proyectos de servicio, deberás moverlos todos antes de volver a mover el proyecto host.

Funciones personalizadas de Identity and Access Management

Las funciones de administración de identidades y accesos personalizadas se pueden crear a nivel de la organización para proporcionar un control detallado del acceso a los recursos, pero solo son válidas en el recurso de 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 organización, el traslado fallará y mostrará un error de condición previa fallida, lo que explicará 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 la CLI de Google Cloud:

gcloud iam roles list --organization ORGANIZATION_ID

En el ejemplo anterior, ORGANIZATION_ID es el ID de recursos de la organización para el que deseas enumerar las funciones. Para obtener información sobre cómo encontrar el ID de recursos de tu organización, consulta la sección sobre cómo crear y administrar los recursos de la organización.

Para obtener información sobre una función personalizada de Identity and Access Management en el recurso de tu organización, ejecuta el siguiente comando de la CLI de Google Cloud:

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 evitar el error de condición previa con errores, debes crear funciones personalizadas a nivel de proyecto equivalentes 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 que el proyecto se haya migrado, 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. 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

Con los Controles del servicio de VPC, los usuarios pueden configurar un perímetro de seguridad basado en proyectos en sus servicios de Google Cloud a fin de mitigar los riesgos de robo de datos. No puedes migrar un proyecto 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 de los perímetros de los Controles del servicio de VPC no se bloqueen para que se trasladen entre los recursos de la organización hasta un día después de que se haya creado o actualizado un perímetro. Es posible que el proyecto demore varias horas en moverse después de que se quite 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 juntos. Si bien los proyectos con objetos de interconexión dedicada o adjuntos de VLAN conectados a ellos se pueden migrar y funcionarán entre los recursos de la organización, no podrás crear nuevos adjuntos de VLAN en la división de recursos de la organización.

Es posible que los cambios de configuración realizados en un proyecto en un recurso de organización que tiene un objeto de interconexión dedicada o un adjunto de VLAN en el objeto de interconexión dedicada no se propaguen entre sí, por lo que te recomendamos no dejar esos proyectos divididos entre los recursos de la organización durante mucho tiempo, si es posible.

Interconexión de socio

No se necesitan consideraciones especiales para migrar proyectos con la interconexión de socio.

Cuentas de servicio entre proyectos

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

Si mueves un proyecto que posee una cuenta de servicio entre proyectos vinculada a otro proyecto en el recurso de 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 dominios que los restrinja al dominio de recursos 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 restricción del 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 que apunten al nuevo recurso de 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 entonces, los miembros del recurso de origen de la organización deben autorizar solicitudes.

En los siguientes pasos, se explica cómo asegurarte de que los miembros del recurso de 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 organización a fin de que no tengas que cambiar la configuración de la pantalla de consentimiento de OAuth.

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

  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 su 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 sin verificar antes de la pantalla de autorización. A fin de evitar esto, solicita la verificación de apps para el uso de permisos sensibles o restringidos.

Acceso al SO

Si el Acceso al SO está habilitado en el proyecto de origen, asigna la función de IAM roles/compute.osLoginExternalUser a las principales que puedan 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 conectar cuentas de servicio a los recursos, incluso si estos no tenían permiso para actuar en nombre de las cuentas de servicio. Esto se documenta aquí.

Si el recurso de organización de origen de un cliente tiene el comportamiento heredado (es posible adjuntar un archivo de cuentas de servicio sin la función normal otorgada) y el recurso de organización de destino no lo tiene, otorga roles/iam.serviceAccountUser a los usuarios que adjunten estas cuentas de servicio a los recursos. Para obtener información sobre el robo de identidad de cuentas de servicio, consulta Suplantación de identidad de cuentas de servicio.

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

  1. En 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 filtros 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, concede 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 un error. Para resolver cualquier error, comunícate con el equipo de asistencia.