Se usó la API de Cloud Translation para traducir esta página.
Switch to English

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 y se pueden colocar en carpetas o en el recurso de la organización y formando la jerarquía de recursos. Es posible que debas migrar proyectos entre organizaciones debido a adquisiciones, requisitos reglamentarios y separación entre unidades de negocios, entre otras.

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 mover el proyecto a su lugar original en la jerarquía de recursos.

Crear un plan de migración

Lo más importante que debes considerar durante una migración del proyecto es la forma en que 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 en él como una sola unidad, lo que significa que no se aplicarán cambios de configuración dentro del proyecto.

Aunque la migración no realizará cambios de configuración directa 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 Identity and Access Management o de la organización, no se moverán con el proyecto durante la migración, solo las políticas y cuentas de servicio vinculadas directamente al recurso. Esto puede causar un comportamiento no deseado cuando se completa la migración.

Antes de transferir tu proyecto, debes considerar crear un plan de migración para determinar la preparación de tu organización y los proyectos que deseas trasladar. En este plan de migración, toma el inventario de cada uno de los servicios que ejecuta tu proyecto y cualquier otro servicio que pueda verse afectado por el traslado, o por la jerarquía de recursos en el destino de tu proyecto las rutas "a GCP".

Descripción general del inventario

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 ayudarte a 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 interpretar los datos con 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á sujeta a la evaluación de políticas vigente en su destino. Recomendamos asegurarte de que las políticas eficaces en el destino del proyecto coincidan con la mayor frecuencia posible con las políticas que el proyecto tenía en su ubicación de origen.

Cualquier política que se aplique directamente al proyecto seguirá adjuntada una vez que se complete la migración. Aplicar políticas directamente al proyecto es una buena manera de verificar que las políticas correctas se aplican desde el momento en que se completa el traslado.

Las políticas de administración de identidades y accesos se heredan a través de la jerarquía de recursos y pueden bloquear el funcionamiento de un servicio si no se establece de forma adecuada. Determina la política vigente en el destino del proyecto en tu jerarquía de recursos para garantizar que la política se alinee con tus 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 en ella. Las claves criptográficas pertenecen al proyecto, y un usuario con acceso owner a ese proyecto podrá administrar y realizar operaciones criptográficas en claves de Cloud KMS en ese proyecto.

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

Vista previa de funciones

Puedes habilitar las funciones de vista previa en organizaciones, carpetas o proyectos. Si habilitaste una función Alfa o Beta en el proyecto que deseas mover, esta característica debe seguir funcionando después de la migración. Si la función de vista previa es privada y no está permitida para la organización de destino, no podrás realizar ningún cambio de configuración después de que se complete la transferencia.

Reversión del 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 de modo que puedas ejecutar la migración del proyecto de forma inversa.

Para obtener una lista de los permisos necesarios, consulta Asigna permisos. Para conocer las políticas de la organización que necesitas configurar a fin de permitir una migración del proyecto, consulta la sección sobre cómo configurar políticas de la organización.

Carpetas de importación y exportación dedicadas

La herencia de políticas puede causar efectos imprevistos cuando migras un proyecto, tanto en la organización de origen como en la de destino. Puedes mitigar este riesgo si creas carpetas específicas a fin de conservar solo los proyectos para importación y exportación, y asegurarte de que las carpetas en ambas organizaciones heredan las mismas políticas. También puedes establecer permisos en estas carpetas que se heredarán en los proyectos que se mueven dentro de ellas, lo que ayuda 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 organización en la que planeas exportar proyectos. Luego, establece una política de la organización en estas carpetas, cada una con la restricción constraints/resourcemanager.allowedExportDestinations configurada en la organización 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 adecuadas establecidas.

Del mismo modo, configura carpetas dedicadas de importación en la organización de destino, una para cada organización desde la que desees importar proyectos. Para hacerlo, crea una carpeta para cada organización desde la que planeas importar proyectos. Luego, establece una política de la organización en estas carpetas, cada una con la restricción constraints/resourcemanager.allowedImportSources establecida en la organización única 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 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. Cualquier función que se encuentre dentro de estas carpetas heredará esta función, lo que le permitirá al usuario realizar las operaciones de movimiento 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 cómo configurar las políticas de la organización, consulta la página sobre cómo configurar las 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 en el nivel adecuado de la jerarquía de recursos.

Permisos de transferencia de proyectos

En el recurso del proyecto que deseas mover y su recurso superior, necesitas la función de Migrador de proyecto (roles/resourcemanager.projectMover) o alguna otra que incluya los siguientes permisos para la API de Resource Manager v1:

  • Permiso requerido para el recurso que mueves:

    • resourcemanager.projects.update
  • Se requiere permiso para el recurso superior:

    • resourcemanager.projects.move

En el recurso de destino, el permiso que necesitas depende del recurso al que moverás el proyecto.

  • Si el recurso de destino es una carpeta, necesitas la función migrador del proyecto (roles/resourcemanager.projectMover) o alguna otra función que incluya el permiso resourcemanager.projects.move.

  • Si el recurso de destino es una organización, necesitas la función Creador de proyectos (roles/resourcemanager.projectCreator) o alguna otra función que incluya los permisos resourcemanager.projects.create.

Permisos de las políticas de la organización

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

Configura políticas de la organización

Para mover un recurso del proyecto a una organización nueva, primero debes aplicar una política de la organización que definirá 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 proyectos.

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

En el recurso de destino, establece una política de la organización que incluya la restricción de 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 existía en una organización con el ID 12345678901 y querías trasladarlo a una organización nueva para tu unidad de negocios secundaria, con el ID. 45678901234 por error.

Establece una política de la organización en organizations/12345678901 con la restricción constraints/resourcemanager.allowedExportDestinations aplicada y under:organizations/45678901234 establecido 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 un allowed_value.

Una vez que se apliquen las políticas de la organización, podrás migrarmy-test-project deorganizations/12345678901 paraorganizations/45678901234, si suponemos que tienes los permisos mencionados enAsignar permisos las rutas "a GCP".

Cambia la cuenta de facturación para un proyecto

Las cuentas de Cloud Billing 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 los permisos necesarios para la migración:
    1. roles/billing.admin en la organización de origen.
    2. roles/billing.creator en la organización 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 Descripción general, 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 requeridas, puedes usar la API de Resource Manager para mover un recurso de proyecto. las rutas "a GCP".

gcloud

Para migrar un proyecto a 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 número del proyecto que deseas migrar.
  • ORGANIZATION_ID es el ID de la organización a la que deseas transferir 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 carpeta o una organización.

API

Con la API de Resource Manager v1, puedes transferir un proyecto si configuras el 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 con el ID de organización o el ID de carpeta de la carpeta a la que la 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 trasladaste un proyecto por error, puedes revertir la operación si realizas el traslado otra vez con el origen anterior y el destino anterior como la fuente nueva. Debes aplicar de manera forzosa los permisos de IAM y las políticas de la organización necesarios para permitir esto como si fuera una migración completamente nueva.

Cómo administrar 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 cambiarlo a Sin organización con este proceso. Si tienes un proyecto asociado con tu organización y deseas revertir a Sin organización, comunícate con tu representante de asistencia para obtener ayuda.

El proceso de migración de un proyecto que no está asociado con una organización es similar al de 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, sigue estos pasos:

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

  2. Crea una carpeta de importación dedicada en la organización de destino, si lo deseas.

  3. Asigna permisos de administración de identidades y accesos para el proyecto y el superior, tal 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 la lista desplegable Organización, selecciona la organización a la que deseas 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 de acuerdo con 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 de constraints/resourcemanager.allowEnabledServicesForExport en la parte superior del proyecto que se exportará. Esta restricción debe mostrar 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 de 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 la salud de tu red si dejas algunos proyectos de servicio en la organización de origen de forma indefinida mientras migras otros.

Si trasladas el proyecto host, puedes volver a cambiarlo a la organización de origen, pero una vez que comiences a mover los proyectos de servicio, deberás moverlos todos para poder volver a mover el proyecto host.

Funciones personalizadas de administración de identidades y accesos

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á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 movimiento fallará y se mostrará un error de condición previa con errores, en la que se explicará esa función en cuestión. No existe en la organización de destino.

Para enumerar todas las funciones personalizadas de IAM a nivel de la 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 que 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 la organización, consulta la página sobre cómo crear y administrar 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 organización superior de la función.

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

A fin de solucionar 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.

Cuando 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 más información sobre las funciones personalizadas, consulta Crea y administra funciones personalizadas.

Bloqueo del bucket

Cloud Storage Bucket Lock te permite configurar una política de retención de datos en un depósito de Cloud Storage que regula cuánto tiempo se deben retener los objetos en el depósito. El bloqueo del depósito está protegido mediante 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 trasladas un proyecto con un bloqueo de depósito aplicado y evita 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 en torno a sus servicios de Google Cloud a fin de 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. Los proyectos en los perímetros de los Controles del servicio de VPC no pueden impedir que se muevan entre las organizaciones durante 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 que se quite del perímetro de servicio.

CDN Interconnect

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

Es posible que los cambios de configuración realizados a un proyecto en una organización que tenga un objeto de CDN Interconnect adjunto o un adjunto de VLAN al objeto CDN Interconnect no se propaguen a la otra, por lo que te recomendamos que no se dividas esos proyectos en de organizaciones durante mucho tiempo.

Assured Workloads

No puedes mover un proyecto Assure Workloads entre organizaciones. Cualquier intento de hacerlo se bloqueará de manera programática.

Cuentas de servicio entre proyectos

Si trasladas 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 restringe el dominio de ese proyecto.

Si mueves un proyecto que posee una cuenta de servicio entre proyectos adjunta 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 una política de organización de restricción de dominio aplicada, que lo restringe 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 permite que acceda al dominio de organizations/12345678901..

Si agregas serviceAccount-1 a la vinculación de IAM para project-C y, luego, cambias 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 la restricción del dominio.

Casos de ayuda

Si trasladas un proyecto que tiene un caso de ayuda abierto, debes comunicarte con tu contacto de Atención al cliente de Google para informarle que se produjo la migración. Los proyectos que tengan un caso de asistencia abierto con Google no podrán ver esos casos de ayuda hasta que la Atención al cliente de Google actualice los metadatos del caso para que apunten a la nueva organización.

Si tu proyecto está configurado para usar una pantalla de consentimiento de OAuth interno y la migras a otra organización, solo los miembros de la organización de destino pueden autorizar solicitudes. Este comportamiento puede demorar 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 para los miembros de la organización de origen, sigue estos pasos:

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

  2. Las apps que se marcan como internas y usan datos sensibles no necesitan solicitar la verificación de apps. Si la app usa datos sensibles, cuando la pantalla de consentimiento se actualiza a una externa, los usuarios de la organización de origen verán una pantalla no verificada antes de pantalla de autorización. A fin de evitar esto, solicita la verificación de la app para el uso de alcances sensibles o restringidos.

Acceso a SO

Si OS Login está habilitado en tu proyecto de origen, asigna la función de IAM roles/compute.osLoginExternalUser a los miembros del proyecto de origen, en la organización de destino para evitar esos miembros. perder acceso.

Conecta cuentas de servicio a recursos

Para la mayoría de los servicios de Google Cloud, los usuarios necesitan el permiso iam.serviceAccounts.actAs en una cuenta de servicio para adjuntar esa cuenta de servicio a un recurso. Sin embargo, en el pasado, para facilitar la integración de ciertos servicios les permitían a los usuarios adjuntar cuentas de servicio a los recursos, incluso si estos no tenían permiso para actuar como las cuentas de servicio. Esto se documenta aquí.

Si la organización de origen de un cliente tiene el comportamiento heredado (el adjunto de cuentas de servicio es posible sin el otorgamiento de función normal) y la organización de destino no otorga, otorga roles/iam.serviceAccountUser a los usuarios que adjuntan estas cuentas de servicio a recursos de búsqueda. A fin de obtener información sobre la identidad de cuentas de servicio, consulta la página sobre cómo actuar para cuentas de servicio.

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

  1. En 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 en la parte superior de la página, elige la organización de la que deseas verificar el estado heredado.

  3. En el cuadro de filtro de 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 política de la organización:

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck
  6. Si aparece alguna de estas restricciones de la organización, tu 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 mencionan antes. Si tanto las organizaciones de origen como las de destino tienen el comportamiento heredado, no se requiere ninguna acción, pero considera forzar la política para evitar el robo de identidad no deseado.