Cómo controlar casos especiales

En este documento, se proporciona información sobre cómo manejar 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 la organización. en un recurso de organización. Sin embargo, no puedes volver a Ninguna organización usa 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 la 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 Restringe la visibilidad del proyecto para los usuarios.

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

gcloud projects describe PROJECT_ID

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: estos pasos:

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

2. Si lo deseas, crea una carpeta de importación dedicada en el recurso de la organización de destino.

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.

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 el roles/compute.osLoginExternalUser rol a cualquier principal que tenga acceso a ese proyecto.

VPC compartida

Los proyectos de VPC compartida se pueden migrar 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 los restricción constraints/resourcemanager.allowEnabledServicesForExport en la superior del proyecto que se exportará. En esta restricción, se debe indicar 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. Recomendamos que hagas coincidir las reglas de firewall entre los recursos de la organización en las ubicaciones de origen y destino, lo que debería minimizar posibles problemas y evitar cualquier tiempo de inactividad en 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 personalizados de Identity and Access Management a nivel de los recursos de la organización para proporcionar un control detallado del acceso a los recursos, pero solo son válidas en el recurso de la organización en el que se crearon. 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 de los recursos de la organización, la migración falla con un error de condición previa fallida, lo que explica que el rol en cuestión no no existe en el recurso de la organización de destino.

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

gcloud iam roles list --organization ORGANIZATION_ID

Donde ORGANIZATION_ID es el recurso de la organización Es el ID para el que deseas enumerar las funciones. Para obtener información sobre cómo encontrar ID de recurso de la organización, consulta Crea y administra recursos de la 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 del recurso de la organización del recurso de la organización superior del rol.

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

Para solucionar el error de condición previa, debes crear una roles personalizados a nivel de proyecto para cada uno de los roles que hereda el proyecto. Luego, quita las vinculaciones de roles de IAM hacer referencia a los roles personalizados a nivel de la organización.

Una vez que se haya migrado el proyecto, puedes actualizar la IAM políticas para usar los roles personalizados a nivel de la organización recurso de la organización.

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

Bloqueo del bucket

El bloqueo de buckets 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 un lien para evitar que el proyecto se borre accidentalmente.

La política de retención y la retención se conservan con el proyecto durante una migración. pero ten en cuenta que si migras un proyecto con bloqueo del bucket de manera forzosa y evitar movimientos accidentales.

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

Controles del servicio de VPC permite a los usuarios configurar un perímetro de seguridad basado en proyectos alrededor de 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 los proyectos en los perímetros de los Controles del servicio de VPC entre los recursos de tu organización. Este lineamiento se aplica hasta un día después de que se crea un perímetro se actualicen. Es posible que tardes varias horas en migrar un proyecto. del perímetro de servicio.

Interconexión dedicada

Recomendamos migrar proyectos con objetos de interconexión dedicada y proyectos con adjuntos de VLAN juntos. 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 adjuntos de VLAN nuevos 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 cuando se migran proyectos con Interconexión de socio.

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 vinculada a ella, la cuenta de servicio seguirá funcionando en el recurso de la organización de destino. Ese proyecto continuará trabajando con el a la cuenta de servicio conectada, incluso si hay una política de la organización restringe su dominio. en un proyecto final.
• 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 esa cuenta de servicio en cualquier recurso que tenga un dominio política de la organización de restricción que se les aplica y que 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 usa serviceAccount-1.

Aplicaste una política de la organización con la restricción de dominio a project-C, lo que solo le permitirá 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, el la vinculación fallará porque infringe la restricción de dominio.

Casos de ayuda

Si migras un proyecto que tiene un caso de asistencia abierto, debes comunicarte con tu contacto de Atención al cliente de Google para informarle que se realizó la migración Cualquiera los proyectos que tengan un caso de asistencia abierto con Google no podrán ver esos casos de asistencia hasta que el equipo de Atención al cliente de Google actualice los metadatos del caso para que el 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 la organización, solo los miembros recurso de la organización de destino puede autorizar solicitudes. Este comportamiento puede tardar hasta 24 horas en aplicarse. Hasta entonces, los miembros de la fuente recurso de la organización puede autorizar 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 el recurso de la organización de destino para los miembros de los recursos de la organización para que no necesitas 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. Apps marcadas como internas y de uso datos sensibles no necesitan solicitar la verificación de aplicaciones. Si la app usa datos sensibles, Luego, cuando la pantalla de consentimiento se actualiza a externa, los usuarios de la fuente recurso de organización verá una pantalla de app no verificada 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 cualquier principal que tenga acceso a ese proyecto. Esto garantiza que estas principales no pierdan 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 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 de el proyecto del propietario.

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

• Si migras el proyecto de propietario a otra organización, Compute Engine borra cualquier reserva creada por el proyecto propietario. La ejecución de instancias de VM no se ve afectada.
• 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

Para la mayoría de los servicios de Google Cloud, los usuarios necesitan iam.serviceAccounts.actAs permiso en una cuenta de servicio para conectarla a un recurso. Sin embargo, en el pasado, para facilitar la integración, ciertos servicios permitían a los usuarios adjuntar cuentas de servicio a los recursos incluso si los usuarios no tenían permiso para actuar en nombre de las cuentas de servicio. Esto se documenta en Cómo requerir permiso para adjuntar 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 de la parte superior de la página, elige la organización. recurso del que quieres 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 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 en las políticas de la organización, recurso usa 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.

Cómo migrar 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 no está 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 la organización. 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 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.