Migrar 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 del proyecto es la entidad organizativa básica en una organización de Google Cloud. Los proyectos se crean en organizaciones y se pueden ubicar en carpetas o en el recurso de la organización, lo que forma la jerarquía de recursos. Es posible que debas migrar proyectos entre organizaciones debido a adquisiciones, requisitos normativos y separación entre unidades comerciales, entre otros aspectos.

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

Crea un plan de migración

Lo más importante que debes considerar durante un traslado de proyecto es cómo la migración afectará 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 este 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 directos de configuración 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 la 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 cuentas de servicio que estén vinculadas directamente al recurso. Esto puede causar un comportamiento no deseado después de que se complete la migración.

Antes de migrar el proyecto, debes considerar crear un plan de migración para determinar la preparación de la organización y de los proyectos que deseas trasladar. En este plan de migración, realiza un inventario de cada uno de los servicios que se ejecutan en 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 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 con SQL, que es más fácil de leer que interpretar los datos con formato JSON. Para obtener más información sobre la exportación de 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 efectivas en el destino del proyecto coincidan tanto como sea posible con las políticas que el proyecto tenía en su ubicación de origen.

Cualquier política que se aplique de forma directa al proyecto se vinculará después de que se complete la migración. Aplicar políticas directamente al proyecto es una buena forma de verificar que se apliquen las políticas correctas desde el momento en que se completa el traslado.

Las políticas de la 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 un servicio para que no funcione 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 tus objetivos de administración.

Administra claves encriptadas

Debes verificar si el proyecto tiene habilitada una clave encriptada administrada por el cliente o algún otro servicio de Cloud Key Management. Las claves criptográficas son propiedad del proyecto y, por lo tanto, un usuario con acceso de 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 funciones de vista previa en organizaciones, carpetas o proyectos. Si habilitaste una función Alfa o Beta en el proyecto que se moverá, esta característica debería seguir funcionando después de la migración. Si la función de vista previa es privada y no se admite en la lista de anunciantes permitidos para la organización de destino, no podrás realizar cambios de configuración después de que se complete el traslado.

Plan de reversión

Si descubres que algo no funciona en ninguno de los proyectos que migraste, puedes moverlos a su ubicación original. Para ello, debes tener los permisos de IAM necesarios y establecer las políticas de la organización requeridas 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. Para conocer las políticas de la organización que debes configurar a fin de permitir la migración de un proyecto, consulta la sección sobre cómo configurar 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 se migra un proyecto en las organizaciones de origen y de destino. Puedes mitigar este riesgo si creas carpetas específicas a fin de contener solo proyectos para importar y exportar, y te aseguras de que las mismas políticas hereden de las carpetas en ambas organizaciones. También puedes configurar permisos en estas carpetas que se heredarán en los proyectos transferidos dentro de ellas, lo que ayuda a acelerar el proceso de migración del proyecto.

Cuando planifiques una migración, considera configurar una carpeta de origen dedicada. A fin de hacer esto, crea una carpeta para cada organización a la que planees exportar proyectos. Luego, establece una política de la organización en estas carpetas, cada una con la restricción constraints/resourcemanager.allowedExportDestinations establecida en la única organización a la que deseas exportar proyectos.

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

Del mismo modo, configura carpetas de importación dedicadas en la organización de destino, una para cada organización desde la que desees importar proyectos. A fin de hacer esto, crea una carpeta para cada organización desde la que planees importar proyectos. A continuación, 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 carpetas Import from Marketing Org y Import from App Development Org, cada una con las restricciones de políticas de la organización adecuadas.

En cada una de las carpetas de importación y exportación, asigna a la persona que moverá los proyectos la función roles/resourcemanager.projectMover. Esta función será heredada por 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.

Después de completar la migración del 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 organizaciones.

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

Permisos de traslado de proyectos

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 del 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 trasladar
  • resourcemanager.projects.update en el proyecto que deseas trasladar
  • 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 bien otras funciones predefinidas.

Permisos de 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.

Configura las 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 mover 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 los proyectos.

En el recurso superior del proyecto que deseas trasladar, establece una política de la organización que incluya la restricción constraints/resourcemanager.allowedExportDestinations. Esto definirá el destino objetivo 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á la fuente como 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.

Debes establecer 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, establece 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 en 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 en 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, haz 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 recurso de destino, con el siguiente comando:

gcloud beta projects move PROJECT_ID \
    --folder FOLDER_ID

Aquí:

  • 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().
  • Establece su campo parent en el ID de la organización de la organización o en el ID de la carpeta a la que la 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 trasladaste un proyecto por error, puedes revertir la operación si realizas el traslado de nuevo, con la fuente antigua 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 que se trate de una migración completamente nueva.

Maneja casos especiales

Migra proyectos no asociados a una organización

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

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

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

  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 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

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

  1. Abre la página IAM y administración > Configuración en 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 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 superior del proyecto que se exportará. En esta restricción, se debe mostrar SHARED_VPC como un allowed_value.

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

Funciones personalizadas de la administración de identidades y accesos

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 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 la organización, el traslado fallará y se mostrará un error de condición previa con errores, lo que explica 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 tu organización, ejecuta el siguiente comando de la herramienta de línea de comandos de gcloud:

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 administración de identidades y accesos en tu organización, ejecuta el siguiente comando de la herramienta de línea de comandos de gcloud:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Aquí:

  • 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 solucionar el error de condición previa con errores, debes crear funciones personalizadas equivalentes 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 que se migró el proyecto, 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 de bucket s 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 está protegido mediante una retención para evitar que se borre 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 para 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 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 en todas las organizaciones hasta un día después de la creación o actualización de un perímetro. Es posible que el proyecto tarde 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 dedicadas. Si bien los proyectos con objetos de interconexión dedicados o adjuntos de VLAN conectados a ellos se pueden migrar y funcionarán entre organizaciones, no podrás crear nuevos adjuntos de VLAN en toda la división de la organización.

Los cambios de configuración realizados a un proyecto en una organización que tiene un objeto de interconexión dedicada adjunto o un adjunto de VLAN al objeto de interconexión dedicada no pueden propagarse a la otra, por lo que recomendamos que no dejes estos proyectos divididos organizaciones durante mucho tiempo si es posible.

Interconexión de socio

No hay 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 conectada 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 conectada 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 restricción de dominio a project-C, que solo permite que acceda 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 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 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 interno y lo migras a otra organización, solo los miembros de la organización de destino pueden 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 garantizar que los miembros de tu organización de origen no pierdan el acceso durante la migración. Considera crear usuarios nuevos en tu 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 marcadas como internas y que usan datos sensibles no necesitan solicitar la verificación de apps. Si la app usa datos sensibles, cuando se actualice la pantalla de consentimiento a externa, los usuarios de la organización de origen verán una pantalla de app sin verificar antes del pantalla de autorización. Si quieres evitar esto, solicita la verificación de apps para usar 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 conectar esa cuenta de servicio 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 conectar cuentas de servicio sin la concesión normal de la función) y la organización de destino no, otorga roles/iam.serviceAccountUser a los usuarios que conectan estas cuentas de servicio a recursos. Para obtener información sobre cómo actuar en nombre de cuentas de servicio, consulta Robo de identidad de 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 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, 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 políticas de la organización, la organización usa el comportamiento heredado.

Si la organización de origen tiene el comportamiento heredado y el destino no, otorga 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.