Cómo controlar casos especiales

En este tema, se proporciona información para manejar casos especiales relacionados mientras se migran proyectos.

Migra proyectos sin recursos de la organización

Puedes migrar un proyecto que no esté asociado con un recurso de la organización a un recurso de la organización. Sin embargo, no puedes volver a cambiar a Sin organización con este proceso. Si tienes un proyecto asociado con el recurso de tu organización y deseas revertirlo a Sin organización, comunícate con tu representante de asistencia para obtener ayuda.

Si no tienes el permiso resourcemanager.organizations.get en el recurso de la organización superior del proyecto, es probable que los proyectos no se reflejen como se espera en la organización real. Para obtener más información, consulta Cómo restringir la visibilidad del proyecto para los usuarios.

Nota: Revertir un proyecto a Sin organización requiere una justificación empresarial.

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

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

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 elemento 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.

Console

Para migrar un proyecto a un recurso de organización, haz lo siguiente:

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 la organización, el Selector de organización no aparecerá y puedes 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 al que deseas migrar tu proyecto.

gcloud

Para migrar un proyecto a un recurso de la 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 quieres 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 del recurso 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().
• Establece su campo parent en el ID del recurso de la 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 el proyecto de origen, debes asignar el rol roles/compute.osLoginExternalUser a cualquier principal que tenga acceso a ese proyecto.

VPC compartida

Nota: Los proyectos de servicio de VPC compartida pueden tardar hasta dos minutos en migrarse después de la migración de su proyecto host correspondiente debido al retraso de la propagación. Es posible que ocurra un error dentro de este período cuando migres estos proyectos. Si esto sucede, vuelve a intentar la migración.

Los proyectos de VPC compartida se pueden migrar si se cumplen ciertas condiciones. Primero, un usuario con la función 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 superior del proyecto que se exportará. Esta restricción debe mostrar 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 la VPC compartida y, luego, 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 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 la organización de origen de manera indefinida 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 sobre la duración del proyecto host y de los proyectos de servicio en diferentes organizaciones. Sin embargo, cuando comiences a migrar los proyectos de servicio, deberás migrarlos todos para poder volver a migrar el proyecto host.

Roles personalizados de Identity and Access Management

Las funciones personalizadas de Identity and Access Management accesos se pueden crear a nivel de 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 crean. Si intentas migrar 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 recurso de la organización, la migración fallará y mostrará un error de condición previa, lo que explica que la función en cuestión no existe en el recurso de la organización de destino.

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

gcloud iam roles list --organization ORGANIZATION_ID

ORGANIZATION_ID es el ID del recurso de la organización para el que deseas enumerar las funciones. Para obtener información sobre cómo encontrar el ID de recurso de tu organización, consulta la página sobre cómo crear y administrar recursos de la organización.

Para obtener información sobre una función personalizada 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 superior de la organización de la función.

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

Para 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 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 migró el proyecto, puedes actualizar las políticas de IAM para usar las funciones personalizadas 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 de 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 retienen los objetos. El bloqueo del bucket está protegido 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 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 alrededor de sus servicios de Google Cloud para mitigar los riesgos de robo de datos. No puedes migrar un proyecto protegido por un perímetro de seguridad de Controles del servicio de VPC.

Para quitar un proyecto de un perímetro de seguridad, consulta Administra perímetros de servicio. Es posible que los proyectos en los perímetros de los Controles del servicio de VPC no se bloqueen para que no se puedan migrar 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. Pueden pasar varias horas antes de que puedas migrar un proyecto después de que se haya quitado del perímetro de servicio.

Interconexión dedicada

Te recomendamos migrar proyectos con objetos de interconexión dedicada y proyectos con adjuntos de VLAN. Los proyectos con objetos de interconexión dedicada o adjuntos de VLAN conectados a estos objetos continuarán funcionando después de la migración entre 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.

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

Interconexión de socio

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

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 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 restringa 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á 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 aplicada una política de la organización de restricción de dominio que la restrinja al dominio del recurso de la organización de origen.

Por ejemplo, supongamos que tienes project-A en organizations/12345678901. Este proyecto tiene serviceAccount-1 vinculado, 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 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 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 verlos hasta que la Atención al cliente de Google actualice los metadatos del caso para que apunten al nuevo recurso de la organización.

Pantalla de consentimiento de OAuth

Si tu proyecto está configurado para usar una pantalla de consentimiento de OAuth interno y la migras a otro recurso de la organización, solo los miembros del recurso de la organización de destino pueden 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 siguientes pasos, se explica cómo garantizar que los miembros del recurso de la organización de origen no pierdan acceso durante la migración. Considera crear usuarios nuevos en el recurso de la organización de destino para los miembros del recurso de la organización, de modo que no tengas que cambiar la configuración de la pantalla de consentimiento de OAuth.

A fin de evitar la pérdida de acceso para los miembros del recurso de la organización de origen, haz lo siguiente:

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

2. Las apps que están marcadas 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 app no verificada antes de la pantalla de autorización. Si quieres evitar esto, solicita la verificación de la app para el uso de permisos sensibles o restringidos.

Acceso a SO

Si el Acceso al SO está habilitado en el 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 (proyecto del propietario) o cualquier proyecto con el que se comparta la reserva (proyecto del consumidor) pueden consumir la reserva mediante la creación de instancias de VM. Solo puedes compartir una reserva con proyectos que pertenezcan a la misma organización del proyecto del propietario.

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

• Si migras el proyecto de propietario a una organización diferente, Compute Engine borra cualquier reserva que haya creado ese proyecto. Las instancias de VM en ejecución no se ven afectadas.
• Si migras un proyecto de consumidor a una organización diferente, el proyecto del 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 servicios de Google Cloud, los usuarios necesitan el permiso iam.serviceAccounts.actAs en una cuenta de servicio para conectar esa cuenta a un recurso. Sin embargo, en el pasado, a fin de facilitar la integración de ciertos servicios, los usuarios podían adjuntar cuentas de servicio a los recursos incluso si no tenían permiso para usar la identidad de las cuentas de servicio. Esto se documenta en Cómo solicitar permiso para adjuntar cuentas de servicio a recursos.

Si el recurso de la organización de origen de un cliente tiene el comportamiento heredado (el adjunto de cuentas de servicio es posible sin la asignación de la función normal) y el recurso de la organización de destino no, otorga la función del usuario de la cuenta de servicio (roles/iam.serviceAccountUser) a los usuarios que adjuntan estas cuentas de servicio a los recursos. Si quieres obtener información sobre los permisos que necesitas para adjuntar cuentas de servicio a los recursos, consulta Funciones para la autenticación de cuentas de servicio.

Para ver si el recurso de tu 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 en 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, significa que el recurso de la organización tiene el comportamiento heredado.

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 las políticas de la organización, el recurso de la organización usa el comportamiento heredado.

Si el recurso de la organización de origen tiene el comportamiento heredado y el destino no, otorga las funciones como se mencionó antes. Si los recursos de la organización de origen y de 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 Analytics Hub

Si migras el proyecto que usa Analytics Hub a un recurso de organización diferente, es posible que encuentres un error. Para resolver cualquier error, comunícate con el equipo de asistencia.

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 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 de copia de seguridad y DR después de que se complete la migración al nuevo recurso de la organización.

¿Qué sigue?

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