Cómo controlar casos especiales

En este documento, se proporciona información para controlar casos especiales durante la migración de proyectos. Cuando migres un proyecto, asegúrate de que se hayan otorgado los permisos de IAM necesarios en el proyecto, en el recurso superior y en el recurso de destino.

Migra proyectos que no están asociados con un recurso 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 cambiarlo a Sin organización con este proceso. Si tienes un proyecto asociado con el recurso de tu organización y quieres revertirlo a Sin organización, comunícate con tu representante de Atención al cliente para obtener ayuda.

Debes tener el rol roles/resourcemanager.projectCreator asignado en el recurso de organización de destino.

Si no tienes el permiso resourcemanager.organizations.get en recurso de organización superior del proyecto, es probable que tus proyectos no reflejan lo esperado en la organización real del Consola de Google Cloud Esto puede hacer que parezca que el proyecto no está asociado. con cualquier recurso de la organización. Para obtener más información, consulta Cómo restringir la visibilidad de los proyectos para los usuarios.

Para determinar si el proyecto está asociado con un recurso de la organización, lo siguiente:

gcloud

Ejecuta el siguiente comando:

gcloud projects describe PROJECT_ID

Reemplaza PROJECT_ID por el ID del proyecto que deseas migrar.

Si el recurso superior no se muestra en el resultado, se confirma que el proyecto no está asociado con un recurso de organización.

Si el recurso superior (recurso de organización o carpeta) se muestra en el resultado, se confirma que el proyecto está asociado con un recurso de la organización.

Nota: Para revertir un proyecto a Sin organización, se requiere una justificación comercial.

El proceso de migración de un proyecto no asociado a un recurso de la organización es similar al proceso de migración de un proyecto entre recursos, pero no requiere todos los pasos del plan de migración. Para migrar un proyecto a un recurso de organización, sigue estos pasos:

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

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

3. Asigna permisos de Identity and Access Management para el proyecto y el recurso superior de destino como se detalla en Cómo asignar 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 y administración > Configuración en la consola de Google Cloud.

   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 organización, no aparecerá el Selector de organización y podrás omitir este paso.

4. Selecciona el proyecto que deseas migrar.

   

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 a la que quieres 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

Aquí:

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

API

Con la API de Resource Manager, puedes migrar un proyecto al recurso de la organización si configuras el campo parent con el ID de la 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 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
    }

Si el Acceso al SO está habilitado en tu proyecto de origen, debes asignar el roles/compute.osLoginExternalUser a cualquier principal que tenga acceso a ese proyecto.

VPC compartida

Nota: Pueden pasar hasta dos minutos Los proyectos de servicio de la VPC compartida que se migrarán después se migró su proyecto host correspondiente debido a un retraso en la propagación. Tú puede encontrar un error en este plazo durante la migración de dichos proyectos. Si esto sucede, vuelve a intentar la migración.

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

No es necesario que inhabilites la VPC compartida antes de la migración. Sin embargo, primero se debe migrar el proyecto host de la VPC compartida, seguido de todos sus proyectos de servicio. Te recomendamos que coincidan las reglas del firewall entre los recursos de la organización en las ubicaciones de origen y destino, lo que debería minimizar los posibles problemas y evitar cualquier tiempo de inactividad de 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 el recurso de la organización de origen de forma indefinida mientras migran a otras.

Si migras el proyecto host, puedes volver a moverlo al recurso de la organización de origen. No hay una fecha límite exacta que indique la duración del proyecto host y de los proyectos de servicio en distintas organizaciones. Sin embargo, cuando comiences a migrar los proyectos de servicio, debes migrarlos todos antes puedes volver a migrar el proyecto host.

Roles de Identity and Access Management personalizados

Se pueden crear roles de administración de identidades y accesos personalizados a nivel del recurso de la organización para proporcionar un control detallado del acceso a los recursos, pero solo son válidos en el recurso de la organización en el que se crean. Si intentas migrar un proyecto que contiene una vinculación de política de IAM de un usuario a un rol de IAM personalizado a nivel del recurso de la organización, la migración fallará con un error de precondición fallida que explicará que el rol en cuestión no existe en el recurso de la organización de destino.

Para obtener una lista de todos los roles de IAM personalizados a nivel de tu organización recurso, ejecuta el siguiente comando de Google Cloud CLI:

gcloud iam roles list --organization ORGANIZATION_ID

En el que ORGANIZATION_ID es el ID del recurso de la organización para el que deseas enumerar los roles. Para obtener información sobre cómo encontrar el ID de tu recurso de organización, consulta Cómo crear y administrar recursos de organización.

Para obtener información sobre un rol personalizado de Identity and Access Management en el recurso de tu organización, ejecuta el siguiente comando de Google Cloud CLI:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Aquí:

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

• ROLE_ID es el nombre del rol que deseas describir.

Para evitar el error de precondición fallida, debes crear roles personalizados equivalentes a nivel del proyecto para cada uno de los roles personalizados a nivel de la organización que hereda el proyecto. Luego, quita las vinculaciones de roles de IAM que hacen referencia a los roles personalizados a nivel de la organización.

Una vez que se haya migrado el proyecto, puedes actualizar las políticas de IAM para usar los roles personalizados a nivel de la organización en el recurso de 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 los objetos en el bucket deben retenerse. El bloqueo del bucket se protege con 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 migras un proyecto con un bloqueo de bucket aplicado y evitas los movimientos accidentales.

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

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

Para quitar un proyecto de un perímetro de seguridad, consulta Administra perímetros de servicio. Es posible que no se bloquee la migración de proyectos en perímetros de los Controles del servicio de VPC entre los recursos de la organización. Este lineamiento se aplica hasta un día después de que se crea o actualiza un perímetro. Es posible que tardes varias horas en migrar un proyecto. del perímetro de servicio.

Interconexión dedicada

Recomendamos migrar proyectos con interconexión dedicada objetos y proyectos con adjuntos de VLAN juntos. Los proyectos con objetos de interconexión dedicada o adjuntos de VLAN conectados a estos objetos seguirán funcionando después de la migración entre los recursos de la organización. La única restricción es que no podrás crear nuevos adjuntos de VLAN entre la división de recursos de la organización.

Cambios de configuración realizados en un proyecto en un recurso de la organización que tiene un un objeto de interconexión dedicada o un adjunto de VLAN al Es posible que este objeto no se propague al otro recurso de la organización. Recomendamos no dejar esos proyectos divididos entre organizaciones. recursos por mucho tiempo si es posible.

Interconexión de socio

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

Cuentas de servicio entre proyectos

En el contexto de la migración de la cuenta de servicio entre proyectos, se aplican los siguientes casos:

• Si migras un proyecto que tiene una cuenta de servicio entre proyectos adjunta, esa cuenta de servicio seguirá funcionando en el recurso de 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 migras un proyecto que posee una cuenta de servicio entre proyectos vinculada a otro proyecto en el recurso de la organización de origen, esa cuenta de servicio seguirán funcionando en el recurso de la organización de destino. Sin embargo, no podrás usar esa cuenta de servicio en ningún recurso que tenga una política de la organización de restricción de dominio que lo restrinja al dominio del recurso de la organización de origen.

Por ejemplo, supongamos que tienes project-A en organizations/12345678901. Esta el proyecto tiene serviceAccount-1 adjunto, que se configura como un 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, migrar project-A a organizations/45678901234, la cuenta de servicio funcionen.

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

Casos de ayuda

Si migras 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 al recurso de la organización nueva.

Pantalla de consentimiento de OAuth

Si tu proyecto está configurado para usar una pantalla de consentimiento de OAuth interna y lo migras a otro recurso de la organización, solo los miembros del recurso de la organización de destino pueden autorizar las solicitudes. Puede tardar hasta 24 horas para que se aplique este comportamiento. Hasta entonces, los miembros del recurso de la organización de origen pueden autorizar las solicitudes.

Los pasos que se indican a continuación explican cómo garantizar que los miembros de tu organización de origen recurso no pierdan acceso durante la migración. Considera crear usuarios nuevos en tu recurso de organización de destino para los miembros del recurso de organización de modo 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 del recurso de la organización de origen, haz lo siguiente:

1. Actualiza la pantalla de consentimiento de OAuth para que sea externa en lugar de 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 actualice a externa, los usuarios del recurso de la organización de origen verán una pantalla de la app sin verificar antes de la pantalla de autorización. Para evitarlo, solicita verificación de apps para usar permisos sensibles o restringidos.

Acceso a SO

Si el Acceso al SO está habilitado en tu proyecto de origen, debes asignar el rol roles/compute.osLoginExternalUser a todos los principales que tengan acceso a ese proyecto. Esto garantiza que estas principales no pierdan el acceso en el recurso de la organización de destino.

Reservas compartidas de instancias de máquina virtual (VM)

En una reserva compartida, el proyecto que creó la reserva (propietario project) o cualquier proyecto con el que se comparta la reserva (consumidor proyecto) pueden consumir la reserva mediante la creación de instancias de VM. Solo puedes compartir una reserva con proyectos dentro de la misma organización del proyecto propietario.

Cuando migras un proyecto de propietario o de consumidor a otra organización sucede lo siguiente:

• Si migras el proyecto de propietario a otra organización, Compute Engine borra cualquier reserva creada por el proyecto propietario. Las instancias de VM en ejecución no se ven afectadas.
• Si migras un proyecto de consumidor a una organización diferente, este deja de consumir recursos de cualquier reserva compartida en la organización anterior.

Para obtener más información, consulta Cómo funcionan las reservas compartidas.

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, algunos servicios permitían a los usuarios 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 en Solicita permiso para conectar cuentas de servicio a recursos.

Si el recurso de la organización de origen de un cliente tiene el comportamiento heredado la vinculación de cuentas es posible sin el otorgamiento de rol normal) y la recurso de la organización de destino, otorga el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser) para los usuarios que adjuntan estas cuentas de servicio a de Google Cloud. Si deseas obtener información sobre los permisos que necesitas para adjuntar el servicio, a los recursos, consulta Roles para la cuenta de servicio autenticación.

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

1. En la consola de Google Cloud, 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 el recurso de la organización para el que deseas verificar el estado heredado.

3. En el cuadro de filtro que se encuentra 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 políticas de la organización limitaciones:

   • 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 tu organización usará el comportamiento heredado.

Si el recurso de la organización de origen tiene el comportamiento heredado no otorga los roles como se mencionó antes. Si tanto la fuente como el destino los recursos de la organización 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 organización diferente, es posible que encuentres algún error. Para resolver los errores, comunícate con el equipo de asistencia.

Si el recurso de intercambio de datos de la organización anterior en la página del administrador de Analytics Hub de la nueva organización, usa la API de Analytics Hub para actualizar los datos el intercambio en la nueva organización.

Usa el método projects.locations.dataExchanges.patch.

PATCH https://analyticshub.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/dataExchanges/DATA_EXCHANGE_ID?update_mask=UPDATE_DX_FIELD -d { UPDATE_DX_FIELD:UPDATE_DX_VALUE }

Reemplaza lo siguiente:

• PROJECT_ID es el identificador único del proyecto.
• LOCATION es la ubicación del intercambio de datos.
• DATA_EXCHANGE_ID es el ID del intercambio de datos.
• UPDATE_DX_FIELD es el campo que se actualizará.
• UPDATE_DX_VALUE es el valor actualizado del campo.

Migra proyectos con el servicio de copia de seguridad y DR

Debes inhabilitar el servicio de copia de seguridad y DR antes de migrar proyectos a un recurso de organización diferente. En este momento, cuando el servicio está inhabilitado, hay una interrupción el riesgo que debes tener en cuenta. Debes volver a habilitar el servicio de Copia de seguridad y DR una vez que se complete la migración al nuevo recurso de organización.

¿Qué sigue?

Para obtener información sobre cómo realizar la migración, consulta Cómo realizar la migración.