Gestionar casos especiales

En este documento se proporciona información sobre cómo gestionar casos especiales al migrar proyectos. Cuando migres un proyecto, asegúrate de que tienes los permisos de gestión de identidades y accesos necesarios en el proyecto, su recurso principal y el recurso de destino.

Migrar proyectos que no están asociados a un recurso de organización

Puedes migrar un proyecto que no esté asociado a un recurso de organización a un recurso de organización. Sin embargo, no puedes volver a cambiarlo a Ninguna organización con este proceso. Si tienes un proyecto asociado a tu recurso de organización y quieres cambiarlo a Ninguna organización, ponte en contacto con tu representante del equipo de Asistencia para que te ayude.

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

Si no tienes el permiso resourcemanager.organizations.get en el recurso de organización principal del proyecto, es probable que tus proyectos no se muestren como esperas en la consolaGoogle Cloud . Esto puede dar la impresión de que el proyecto no está asociado a ningún recurso de la organización. Para obtener más información, consulta Restringir la visibilidad de los proyectos a los usuarios.

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

gcloud projects describe PROJECT_ID

El proceso para migrar un proyecto que no está asociado a un recurso de organización es similar al proceso para migrar un proyecto entre recursos de organización, 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. Verifica el impacto en este proyecto de las políticas que heredará.

2. Si quieres, crea una carpeta de importación específica en el recurso de organización de destino.

3. Asigna permisos de gestión de identidades y accesos al proyecto y al recurso principal de destino, tal como se describe en Asignar permisos.

4. Determina si tienes que cambiar la cuenta de facturación.

Después, 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 Inicio de sesión del SO está habilitado en tu proyecto de origen, debes asignar el rol roles/compute.osLoginExternalUser a los principales que tengan acceso a ese proyecto.

VPC compartida

Los proyectos de VPC compartida se pueden migrar si se cumplen ciertas condiciones. En primer lugar, un usuario con el rol roles/orgpolicy.policyAdmin en el recurso de la organización de origen debe definir una política de la organización que contenga la restricción constraints/resourcemanager.allowEnabledServicesForExport en el elemento superior del proyecto que se va a exportar. Esta restricción debe incluir SHARED_VPC como allowed_value.

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

Si migras el proyecto host, puedes volver a moverlo al recurso de la organización de origen. No hay una fecha límite exacta para que el proyecto del host y los proyectos del servicio estén en organizaciones diferentes. Sin embargo, cuando empieces a migrar los proyectos de servicio, deberás migrarlos todos antes de poder volver a migrar el proyecto host.

Roles de Gestión de Identidades y Accesos personalizados

Se pueden crear roles de gestión de identidades y accesos personalizados a nivel de recurso de organización para proporcionar un control granular del acceso a los recursos, pero solo son válidos en el recurso de organización en el que se crean. Si intentas migrar un proyecto que contiene un enlace de política de permiso de un usuario a un rol de gestión de identidades y accesos personalizado a nivel de organización, la migración fallará y se mostrará un error de condición previa fallida, en el que se explica que el rol en cuestión no existe en el recurso de organización de destino.

Para enumerar todos los roles de gestión de identidades y accesos personalizados a nivel de tu recurso de organización, ejecuta el siguiente comando de la CLI de Google Cloud:

gcloud iam roles list --organization ORGANIZATION_ID

ORGANIZATION_ID es el ID del recurso de organización para el que quieres enumerar los roles. Para obtener información sobre cómo encontrar el ID de tu recurso de organización, consulta el artículo Crea y administra recursos de la organización.

Para obtener información sobre un rol de Gestión de Identidades y Accesos personalizado en el recurso de tu organización, ejecuta el siguiente comando de Google Cloud CLI:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Donde:

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

• ROLE_ID es el nombre del rol que quieres describir.

Para solucionar el error de fallo de la condición previa, debe crear roles personalizados a nivel de proyecto equivalentes a cada uno de los roles personalizados a nivel de organización que hereda el proyecto. A continuación, elimina las vinculaciones de roles de gestión de identidades y accesos que hagan referencia a los roles personalizados a nivel de organización.

Una vez que se haya migrado el proyecto, puede actualizar las políticas de permiso para usar los roles personalizados a nivel de organización en el recurso de organización de destino.

Para obtener más información sobre los roles personalizados, consulta el artículo Crear y gestionar roles personalizados.

Bloqueo de segmentos

La función Bloqueo de segmentos de Cloud Storage te permite configurar una política de conservación de datos en un segmento de Cloud Storage que determina durante cuánto tiempo se deben conservar los objetos del segmento. El bloqueo del contenedor está protegido mediante una retención para evitar que se elimine el proyecto por error.

La política de retención y la retención se conservan en el proyecto durante la migración, pero debes tener en cuenta si vas a migrar un proyecto con un bloqueo de segmento aplicado y evitar movimientos accidentales.

Perímetros de seguridad de Controles de Servicio de VPC

Controles de Servicio de VPC permite a los usuarios configurar un perímetro de seguridad basado en proyectos alrededor de sus servicios deGoogle Cloud para mitigar los riesgos de filtración externa de datos. No puedes migrar un proyecto protegido por un perímetro de seguridad de Controles de Servicio de VPC.

Para quitar un proyecto de un perímetro de seguridad, consulta Gestionar perímetros de servicio. No se puede impedir que los proyectos de los perímetros de Controles de Servicio de VPC se migren entre recursos de la organización. Esta directriz se aplica hasta un día después de que se haya creado o actualizado un perímetro. Pueden pasar varias horas hasta que puedas migrar un proyecto después de que se haya quitado del perímetro de servicio.

Interconexión dedicada

Recomendamos migrar los proyectos con objetos de interconexión dedicada y los proyectos con vinculaciones de VLAN juntos. Los proyectos con objetos de interconexión dedicada o vinculaciones de VLAN conectadas 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 vinculaciones de VLAN entre los recursos de la organización dividida.

Es posible que los cambios de configuración realizados en un proyecto de un recurso de organización que tenga un objeto de interconexión dedicada adjunto o una vinculación de VLAN a este objeto no se propaguen al otro recurso de organización. Si es posible, te recomendamos que no dejes este tipo de proyectos divididos entre recursos de la organización durante mucho tiempo.

Partner Interconnect

No es necesario tener en cuenta nada especial al migrar proyectos con Interconexión de partners.

Cuentas de servicio entre proyectos

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

• Si migras un proyecto que tiene una cuenta de servicio entre proyectos asociada, esa cuenta de servicio seguirá funcionando en el recurso de organización de destino. Ese proyecto seguirá funcionando con la cuenta de servicio asociada aunque haya una política de organización que restrinja el dominio de ese proyecto.
• Si migras un proyecto que tiene una cuenta de servicio entre proyectos vinculada a otro proyecto del 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 organización con restricción de dominio que limite el acceso 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 se ha configurado como una cuenta de servicio entre proyectos. project-B y project-C, también en organizations/12345678901, usan serviceAccount-1.

Has aplicado una política de organización con la restricción de dominio a project-C, lo que solo le permite acceder al dominio de organizations/12345678901..

Si añades serviceAccount-1 a la vinculación de gestión de identidades y accesos de project-C y, a continuación, migras project-A a organizations/45678901234, la cuenta de servicio funcionará.

Si migras project-A a organizations/45678901234 y, a continuación, intentas añadir serviceAccount-1 a la vinculación de IAM de project-C, la vinculación fallará porque infringe la restricción de dominio.

Casos de asistencia

Si migras un proyecto que tiene un caso de asistencia abierto, debes ponerte en contacto con tu contacto del equipo de Asistencia de Google para informarle de que se ha producido la migración. Los proyectos que tengan un caso de asistencia abierto con Google no podrán ver esos casos hasta que el equipo de Asistencia de Google actualice los metadatos del caso para que apunten 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 lo migras a otro recurso de organización, solo los miembros del recurso de organización de destino podrán autorizar solicitudes. Este comportamiento puede tardar hasta 24 horas en aplicarse. Hasta entonces, los miembros del recurso de la organización de origen pueden autorizar solicitudes.

En los pasos que se indican a continuación se explica cómo asegurarse de que los miembros de la organización de origen no pierdan el acceso a los recursos durante la migración. Te recomendamos que crees usuarios en el recurso de organización de destino para los miembros del recurso de organización, de forma que no tengas que cambiar la configuración de la pantalla de consentimiento de OAuth.

Para evitar que los miembros de la organización de origen pierdan el acceso al recurso, haz lo siguiente:

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

2. Las aplicaciones que se marcan como internas y usan datos sensibles no tienen que solicitar la verificación. Si la aplicación 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 aplicación no verificada antes de la pantalla de autorización. Para evitarlo, solicita la verificación de la aplicación para usar permisos sensibles o restringidos.

OS Login

Si Inicio de sesión con SO está habilitado en tu proyecto de origen, debes asignar el rol roles/compute.osLoginExternalUser a cualquier principal que tenga acceso a ese proyecto. De esta forma, estos principales no perderán el acceso al recurso de la organización de destino.

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

En una reserva compartida, el proyecto que la ha creado (proyecto propietario) o cualquier proyecto con el que se haya compartido (proyecto consumidor) puede consumir la reserva creando instancias de VM. Solo puedes compartir una reserva con proyectos de la misma organización que el proyecto propietario.

Cuando migras un proyecto propietario o consumidor a otra organización, ocurre lo siguiente:

• Si migras el proyecto propietario a otra organización, Compute Engine eliminará 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 otra organización, el proyecto de consumidor dejará de consumir recursos de cualquier reserva compartida de la organización anterior.

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

Asociar cuentas de servicio a recursos

En la mayoría de los Google Cloud servicios, los usuarios necesitan el permiso iam.serviceAccounts.actAs en una cuenta de servicio para adjuntar esa cuenta de servicio a un recurso. Sin embargo, antes, para facilitar la incorporación, algunos servicios permitían a los usuarios adjuntar cuentas de servicio a los recursos aunque no tuvieran permiso para suplantar la identidad de las cuentas de servicio. Esto se explica en el artículo Requerir permiso para asignar cuentas de servicio a recursos.

Si el recurso de organización de origen de un cliente tiene el comportamiento antiguo (se pueden adjuntar cuentas de servicio sin la asignación de roles normal) y el recurso de organización de destino no, asigna el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser) a los usuarios que adjunten estas cuentas de servicio a los recursos. Para obtener información sobre los permisos que necesitas para asociar cuentas de servicio a recursos, consulta Roles para la autenticación de cuentas de servicio.

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

1. En la Google Cloud consola, 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 el recurso de organización cuyo estado antiguo quieras comprobar.

3. En el cuadro de filtro situado en la parte superior de la lista de políticas de la organización, introduce constraints/appengine.enforceServiceAccountActAsCheck.

4. Si la política de organización appengine.enforceServiceAccountActAsCheck aparece en la lista, el recurso de organización tiene el comportamiento antiguo.

5. Repite los pasos 3 y 4 para cada una de las siguientes restricciones de la política de la organización:

   • appengine.enforceServiceAccountActAsCheck
   • dataflow.enforceComputeDefaultServiceAccountCheck
   • dataproc.enforceComputeDefaultServiceAccountCheck
   • composer.enforceServiceAccountActAsCheck

6. Si aparece alguna de estas restricciones de la política de la organización, tu recurso de la organización utiliza el comportamiento antiguo.

Si el recurso de organización de origen tiene el comportamiento antiguo y el de destino no, asigna los roles como se ha mencionado anteriormente. Si los recursos de las organizaciones de origen y de destino tienen el comportamiento antiguo, no es necesario que hagas nada, pero te recomendamos que apliques la política para evitar la suplantación de identidad accidental.

Migrar proyectos con uso compartido de BigQuery

Si migras el proyecto que usa la función de compartir de BigQuery (antes Analytics Hub) a otro recurso de organización, es posible que se produzca algún error. Para resolver cualquier error, ponte en contacto con el equipo de Asistencia.

Si el recurso de intercambio de datos de la organización antigua no se muestra en la página Administrador de uso compartido de la nueva organización, utilice la API Analytics Hub para actualizar el intercambio de datos 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 }

Haz los cambios siguientes:

• 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 va a actualizar.
• UPDATE_DX_VALUE es el valor actualizado del campo.

Migrar proyectos con el servicio de copia de seguridad y recuperación tras fallos

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

Siguientes pasos

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