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 tener los permisos de Identity and Access Management (IAM) necesarios otorgados en el proyecto, su recurso superior y 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 tu recurso de organización y deseas revertirlo a Sin organización, comunícate con tu representante de asistencia para obtener ayuda.

Debes tener la función roles/resourcemanager.projectCreator asignada en el recurso de organización de destino.

Si no tienes el resourcemanager.organizations.get permiso en el recurso de organización superior del proyecto, es probable que tus proyectos no se reflejen como se espera en la organización real en la Cloud de Confiance consola. Esto puede hacer que parezca que el proyecto no está asociado con ningún recurso de organización. Para obtener más información, consulta Cómo restringir la visibilidad del proyecto para los usuarios.

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

gcloud projects describe PROJECT_ID

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

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

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

3. Asigna permisos de IAM para el proyecto y el recurso 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.

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

    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 la roles/compute.osLoginExternalUser función a cualquier principal que tenga acceso a ese proyecto.

VPC compartida

Los proyectos deVPC compartida se pueden migrar según ciertas condiciones. Primero, un usuario con la función roles/orgpolicy.policyAdmin en el recurso de 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.

No es necesario inhabilitar la VPC compartida antes de la migración. Sin embargo, primero se debe migrar el proyecto host de VPC compartida, seguido de todos sus proyectos de servicio. Te recomendamos que hagas coincidir las reglas de firewall entre los recursos de organización en 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 el estado de tu red si dejas algunos proyectos de servicio en el recurso de organización de origen de forma indefinida mientras migras otros.

Si migras el proyecto host, puedes volver a moverlo al recurso de organización de origen. No hay una fecha límite exacta de cuánto tiempo pueden estar el proyecto host y los proyectos de servicio en diferentes organizaciones. Sin embargo, cuando comiences a migrar los proyectos de servicio, debes migrarlos todos antes de poder volver a migrar el proyecto host.

Funciones de IAM personalizadas

Las funciones de IAM personalizadas se pueden crear a nivel del recurso de organización para proporcionar un control detallado del acceso a los recursos, pero solo son válidas en el recurso de organización en el que se crean. Si intentas migrar un proyecto que contiene una vinculación de política de permiso de un usuario a una función de IAM personalizada a nivel de la organización, la migración fallará con un error de condición previa fallida, que explica que la función en cuestión no existe en el recurso de organización de destino.

Para enumerar todas las funciones de IAM personalizadas a nivel de tu recurso de organización, ejecuta el siguiente comando de Google Cloud CLI:

gcloud iam roles list --organization ORGANIZATION_ID

Donde ORGANIZATION_ID es el ID del recurso de organización para el que deseas enumerar las funciones. Para obtener información sobre cómo encontrar el ID del recurso de organización, consulta Obtén el ID del recurso de organización.

Para obtener información sobre una función de IAM personalizada en tu recurso de organización, ejecuta el siguiente comando de la gcloud CLI:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Aquí:

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

• ROLE_ID es el nombre del rol que deseas describir.

Para solucionar el error de condición previa fallida, debes crear funciones personalizadas equivalentes a nivel del proyecto para cada una de las funciones personalizadas a nivel de la organización que hereda el proyecto. Luego, quita las vinculaciones de las funciones de IAM que hacen referencia a las funciones personalizadas a nivel de la organización.

Una vez que se haya migrado el proyecto, puedes actualizar las políticas de permiso para usar las funciones personalizadas a nivel de la organización en el recurso de organización de destino.

Para obtener información sobre las funciones personalizadas, consulta Crea y administra funciones personalizadas.

Bloqueo del bucket

El bloqueo del bucket de Cloud Storage te permite configurar una política de retención de datos en un bucket de Cloud Storage que regula por cuánto tiempo se deben retener los objetos. El bloqueo del bucket está protegido con una retención para evitar que se borre el proyecto de forma accidental.

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 Cloud de Confiance by S3NS servicios para 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 no se bloquee la migración de proyectos en perímetros de los Controles del servicio de VPC entre recursos de organización. Esta guía se aplica hasta un día después de que se crea o actualiza un perímetro. Es posible que tardes varias horas en poder migrar un proyecto después de que se quite del perímetro de servicio.

Interconexión dedicada

Te recomendamos que migres los proyectos con objetos de interconexión dedicada y los 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 recursos de organización. La única restricción es que no podrás crear adjuntos de VLAN nuevos entre la división del recurso de organización.

Es posible que los cambios de configuración realizados en un proyecto en un recurso de organización que tiene un objeto de interconexión dedicada adjunto o un adjunto de VLAN a este objeto no se propaguen al otro recurso de organización. Te recomendamos que no dejes esos proyectos divididos entre recursos de organización por mucho tiempo si es posible.

Interconexión de socio

No se necesitan consideraciones especiales cuando se migran proyectos con interconexión de socio.

Proyecto de administración

Un proyecto de administración es un Cloud de Confiance by S3NS proyecto en la carpeta habilitada para apps que actúa como un repositorio central para todos tus metadatos centrados en la aplicación. Cada carpeta habilitada para apps contiene solo un proyecto de administración. El proyecto de administración proporciona la infraestructura para las bibliotecas de aplicaciones y las APIs, incluidas la facturación, las cuotas y el control de acceso. No puedes migrar un proyecto de administración.

Cuentas de servicio entre proyectos

En el contexto de la migración de una 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 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 adjunta a otro proyecto en el recurso de organización de origen, esa cuenta de servicio seguirá funcionando en el recurso de organización de destino. Sin embargo, no podrás usar esa cuenta de servicio en ningún recurso que tenga aplicada una política de la organización de restricción de dominio que los restrinja al dominio del recurso de organización de origen.

Por ejemplo, supongamos que tienes project-A en organizations/12345678901. Este proyecto tiene serviceAccount-1 adjunto, que está configurado 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, migras project-A a organizations/45678901234, la cuenta de servicio funcionará.

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á, ya que infringe la restricción de dominio.

Casos de asistencia

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 nuevo recurso de organización.

Pantalla de consentimiento de OAuth

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

En los siguientes pasos, se explica cómo garantizar que los miembros de tu recurso de organización de origen no pierdan el 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 necesites cambiar la configuración de la pantalla de consentimiento de OAuth.

Para evitar la pérdida de acceso de los miembros del recurso de 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 marcadas como internas y que usan datos sensibles no necesitan solicitar la verificación de la app. Si la app usa datos sensibles, cuando la pantalla de consentimiento se actualice a externa, los usuarios del recurso de organización de origen verán una pantalla de app sin verificar antes de la pantalla de autorización. Para evitar esto, solicita la verificación de la app para el uso de permisos sensibles o restringidos.

Acceso al SO

Si el Acceso al SO está habilitado en tu proyecto de origen, debes asignar la función roles/compute.osLoginExternalUser a cualquier principal que tenga acceso a ese proyecto. Esto garantiza que estos principales no pierdan el acceso en el recurso de organización de destino.

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

En una reserva compartida, el proyecto que creó la reserva (proyecto de propietario) o cualquier proyecto con el que se comparte la reserva (proyecto de consumidor) puede 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 propietario o de consumidor a una organización diferente, sucede lo siguiente:

• Si migras el proyecto propietario a una organización diferente, 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, el proyecto de consumidor 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 Cloud de Confiance servicios, los usuarios necesitan el iam.serviceAccounts.actAs permiso en una cuenta de servicio para conectar esa cuenta de servicio a un recurso. Sin embargo, en el pasado, para facilitar la incorporació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 Se requiere permiso para conectar cuentas de servicio a recursos.

Si el recurso de organización de origen de un cliente tiene el comportamiento heredado (la conexión de cuentas de servicio es posible sin el otorgamiento de roles normal) y el recurso de organización de destino no lo tiene, otorga la función de usuario de cuenta de servicio (roles/iam.serviceAccountUser) a los usuarios que conectan estas cuentas de servicio a los recursos. Para obtener información sobre los permisos que necesitas para conectar cuentas de servicio a recursos, consulta Roles para la autenticación de la cuenta de servicio.

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

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

3. En el cuadro de filtro 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 organización tiene el comportamiento heredado.

5. Repite los pasos 3 y 4 para cada una de las siguientes restricciones de políticas 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, tu recurso de organización usa el comportamiento heredado.

Si el recurso de organización de origen tiene el comportamiento heredado y el destino no, otorga las funciones como se mencionó anteriormente. Si los recursos de organización de origen y destino tienen el comportamiento heredado, no se requiere ninguna acción, pero considera aplicar la política para evitar la suplantación no deseada.

Migra proyectos con uso compartido

Si migras el proyecto que usa el uso compartido de BigQuery (antes, uso compartido) a un recurso de organización diferente, es posible que encuentres algún error. Para resolver cualquier error, comunícate con el equipo de asistencia.

Si el recurso de intercambio de datos de la organización anterior no está visible en la página Administrador de uso compartido de la organización nueva, usa la API de uso compartido para actualizar cualquier campo (por ejemplo, el campo description) del intercambio de datos en la organización nueva para activar una actualización de caché.

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

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á. Puede ser cualquier campo del intercambio, como description.
• UPDATE_DX_VALUE es el valor actualizado del campo. Puede ser el mismo valor que el valor original de ese campo.

Migra proyectos con el servicio Backup and DR

Debes inhabilitar el servicio Backup and DR antes de migrar proyectos a un recurso de organización diferente. En este momento, cuando el servicio está inhabilitado, existe un riesgo de interrupción que debes tener en cuenta. Debes volver a habilitar el servicio Backup and DR después de que se complete la migración al nuevo recurso de organización.

Migra proyectos con otorgamientos heredados de Privileged Access Manager

Antes de migrar un proyecto a otra organización, te recomendamos que revoques cualquier otorgamiento activo con alcance en ese proyecto. Un otorgamiento con alcance es un otorgamiento que se crea en un derecho heredado de una carpeta o una organización y, luego, se limita a un proyecto secundario.

Cuando migras un proyecto con un otorgamiento activo con alcance a otra organización, la política de IAM modificada se mueve a la organización nueva, pero el otorgamiento que administra esa política permanece en la organización anterior. Esto significa que el agente de servicio de Privileged Access Manager, que usa el otorgamiento, pierde los permisos para modificar la política de IAM de un recurso en la organización nueva. En consecuencia, fallarán las operaciones de revocación o retiro en ese otorgamiento, y el solicitante conservará el acceso hasta que venza el otorgamiento.

Migra proyectos con taxonomías de etiqueta de política

Si migras un proyecto que contiene taxonomías de etiquetas de política de BigQuery, es posible que esas taxonomías no estén visibles en la Cloud de Confiance consola después de la migración. Esto se debe a que las taxonomías permanecen asociadas con el recurso de organización de origen.

Para resolver este problema, debes migrar las taxonomías de forma manual:

1. Exporta las taxonomías del proyecto de origen con la API de Exportación.

2. Importa las taxonomías al proyecto de destino con la API de Importación.

3. Vuelve a asignar las etiquetas de política a las columnas de la tabla de BigQuery pertinentes.

4. Configura de forma manual las vinculaciones de políticas de permiso para las etiquetas de política nuevas.

¿Qué sigue?

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