Migra proyectos

En esta guía, se explica cómo trasladar un proyecto entre organizaciones o lugares dentro de una jerarquía de recursos.

El recurso de proyecto es la entidad organizadora básica en una organización de Google Cloud. Los proyectos se crean en organizaciones, 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 organizaciones 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 entre organizaciones o a otro lugar de la jerarquía de recursos de su 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.

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 organizaciones, carpetas o proyectos. 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 de la 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 las organizaciones de origen como de destino. A fin de mitigar este riesgo, crea carpetas específicas para que solo se exporten y se importen proyectos, y asegúrate de que las mismas organizaciones hereden las mismas políticas. También puedes configurar permisos en estas carpetas que se heredarán a los proyectos movidos, 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 organización a la 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 establecida en la organización única a la 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 la organización de destino, una para cada organización desde la que deseas importar proyectos. Para hacerlo, crea una carpeta para cada organización desde la 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 la única organización desde la 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 las organizaciones.

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 las organizaciones 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.

Configurar políticas de la organización

Para mover un recurso de proyecto a una organización nueva, primero debes aplicar una política de la organización que defina las organizaciones a las que se puede trasladar el proyecto. También debes establecer una política de la organización en el destino que defina las organizaciones desde las 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 tenías un proyecto my-test-project que existía en una organización con el ID 12345678901 y deseas moverlo a una organización nueva para tu unidad de negocio 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 todas las organizaciones. Mover un proyecto de una organización a otra no afectará la facturación, y los cargos se seguirán generando en la cuenta de facturación anterior. Sin embargo, mover la organización a menudo también incluye el requisito de moverse a una cuenta de facturación nueva.

Para cambiar la cuenta de facturación de un proyecto existente, debes tener la función roles/owner en el proyecto y la función roles/billing.admin en la cuenta de facturación de destino. Para cambiar la cuenta de facturación, haz lo siguiente:

  1. Ve a la página Facturación de 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.

Mueve una cuenta de facturación entre las organizaciones

Una cuenta de facturación se puede mover de una organización a otra, aunque esto no suele ser un paso necesario. La mayoría de las organizaciones existentes ya tienen 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 las organizaciones de origen y de destino.
  2. Ve a la página Facturación de 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 la organización de destino y haz clic en Aceptar.

La cuenta de facturación ahora está asociada a la organización especificada.

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 bajo una 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 de la organización a la que deseas mover el proyecto. Solo puedes especificar un destino, ya sea una 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 organización o una carpeta.

API

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

Sigue estos pasos para migrar un proyecto:

  • Obtén el objeto project con el método projects.get().
  • Configura su campo parent con el ID de la organización o el ID de la carpeta a la que quieres moverlo.
  • 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 aplicar 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 no asociados a una organización

Puedes migrar a un proyecto un proyecto que no esté asociado con una organización. Sin embargo, no puedes volver a Sin organización mediante este proceso. Si tienes un proyecto asociado con 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 una organización es similar al proceso para migrar un proyecto entre organizaciones, pero no es necesario que completes todos los pasos del plan de migración. Para migrar un proyecto a una 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 la 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 una organización:

  1. Abre la página IAM & admin > Settings 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 ninguna 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 el menú desplegable Organización, selecciona la entidad a la que quieres migrar tu proyecto.

gcloud

Para migrar un proyecto a una organización, ejecuta el siguiente comando:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Donde:

  • PROJECT_ID es el ID del proyecto que quieres transferir a la organización.
  • ORGANIZATION_ID es el ID de la organización a la que quieres transferir 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 la organización.

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

  • Obtén el objeto project con el método projects.get().
  • Configura su campo parent con el ID 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 personalizadas de administración de identidades y accesos se pueden crear a nivel de la organización para proporcionar un control detallado del acceso a los recursos, pero solo son válidos en la organización en la 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 la organización de destino.

Para enumerar todas las funciones de IAM personalizadas a nivel de la 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 la organización para el que deseas enumerar las funciones. Para obtener información sobre cómo encontrar el ID de tu organización, consulta Crea y administra organizaciones.

Para obtener información sobre una función personalizada de Identity and Access Management en 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 la organización de la función superior.

  • 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 la 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 muevan a través de las organizaciones hasta un día después de que se haya creado o actualizado un perímetro. El proyecto puede tardar varias horas en moverse después de quitarlo 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 se pueden migrar y funcionarán entre organizaciones, no podrás crear nuevos adjuntos de VLAN en la división de organización.

Es posible que los cambios de configuración realizados en un proyecto en una organización que tiene un objeto de interconexión dedicada adjunto o un adjunto de VLAN en el objeto de interconexión dedicada no se propaguen a la otra, por lo que recomendamos no dejar esos proyectos divididos en organizaciones 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 la 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 la organización de origen, la cuenta de servicio seguirá funcionando en la 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 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 asistencia abierto con Google no podrá ver esos casos hasta que la Atención al cliente de Google actualice los metadatos del caso para que se orienten a la organización nueva.

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

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

Para evitar la pérdida de acceso de los miembros 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 su verificación. Si la app usa datos sensibles, cuando la pantalla de consentimiento se actualice a una externa, los usuarios 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 tu proyecto de origen, asigna la función roles/compute.osLoginExternalUser de IAM a los principales que pueden acceder al proyecto de origen en la organización de destino a fin de evitar que 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 la 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 la 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 las cuentas de servicio, consulta Cómo robar la identidad de las cuentas de servicio.

Para ver si 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 la organización para la que deseas verificar 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, 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, esta usa el comportamiento heredado.

Si la organización de origen tiene el comportamiento heredado y el destino no, concede las funciones como se mencionó antes. Si las organizaciones 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 una organización diferente, es posible que se produzca algún error. Para resolver cualquier error, comunícate con el equipo de asistencia.