Cómo controlar casos especiales

Aprende a manejar casos especiales cuando migras proyectos. Antes de migrar un proyecto, asegúrate de tener los permisos necesarios de Identity and Access Management (IAM) 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 se creó sin un recurso de organización asociado a la jerarquía de un recurso de organización. Sin embargo, no puedes revertir este proceso. Para revertir un proyecto a Sin organización, comunícate con Atención al cliente de Cloud para obtener ayuda.

Para migrar un proyecto que no está asociado con un recurso de organización, debes tener el rol roles/resourcemanager.projectIamAdmin en el proyecto. También debes tener 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 superior, es posible que tus proyectos no aparezcan como se espera en la organización en la Google Cloud consola. Esto puede hacer que parezca que el proyecto no está asociado con un recurso de 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 organización, haz 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 (carpeta o recurso de organización) se muestra en el resultado, se confirma que el proyecto está asociado con un recurso de organización.

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 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. Crea una carpeta de importación dedicada en el recurso de organización de destino, si es necesario.

  3. Asigna permisos de Identity and Access Management 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 con uno de los siguientes métodos:

Console

  1. Abre la página IAM y administración > Configuración en la Google Cloud consola de.

    Abrir la página Configuración

  2. Selecciona tu proyecto (uno con Sin organización) con el selector de proyectos.

  3. En la parte superior de la página Configuración, haz clic en Migrar.

  4. En el diálogo que aparece, selecciona el recurso de organización al que deseas migrar tu proyecto y, luego, haz clic en Migrar.

gcloud

Para migrar un proyecto a un recurso de organización, ejecuta el siguiente comando:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Reemplaza lo siguiente:

  • PROJECT_ID: el ID del proyecto que se migrará
  • ORGANIZATION_ID: el ID del recurso de organización de destino

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

Para migrar un proyecto al recurso de organización, sigue estos pasos:

  • Obtén el objeto project con el método projects.get().
  • Configura su campo parent con el ID del 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 muestra estos pasos:

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

Si la API de acceso al SO de Cloud está habilitada en tu proyecto de origen, asigna el roles/compute.osLoginExternalUser rol a cualquier principal que tenga acceso a ese proyecto.

VPC compartida

Puedes migrar proyectos de VPC compartida en ciertas condiciones. Primero, un usuario con el rol 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 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 debes migrar el proyecto host de la VPC compartida y, luego, todos sus proyectos de servicio. Te recomendamos que hagas coincidir las reglas de firewall entre los recursos de organización de origen y destino para minimizar los posibles problemas y evitar el tiempo de inactividad. No garantizamos el estado de tu red si dejas proyectos de servicio en el recurso de organización de origen 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 para el tiempo que los proyectos host y de servicio pueden estar en diferentes organizaciones. Sin embargo, una vez que comiences a migrar proyectos de servicio, debes migrarlos todos antes de poder migrar el proyecto host nuevamente.

Funciones de IAM personalizadas

Las funciones personalizadas de Identity and Access Management proporcionan un control detallado del acceso a los recursos a nivel del recurso de organización, pero solo son válidas en el recurso de organización en el que se crean. Si migras un proyecto que contiene una vinculación de política de permisos a una función personalizada de IAM a nivel de la organización, la migración falla. El error explica que la función no existe en el recurso de organización de destino.

Para enumerar todas las funciones personalizadas de IAM en tu recurso de organización, ejecuta el siguiente comando:

gcloud iam roles list --organization ORGANIZATION_ID

Reemplaza ORGANIZATION_ID por el ID del recurso de organización. Para obtener más información, consulta Obtén el ID de tu recurso de organización.

Para obtener información sobre una función personalizada de Identity and Access Management en tu recurso de organización, ejecuta el siguiente comando:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Reemplaza lo siguiente:

  • ORGANIZATION_ID: el ID del recurso de organización
  • ROLE_ID: el nombre del rol que se quiere describir

Para solucionar este error, crea funciones personalizadas equivalentes a nivel del proyecto para cada función personalizada heredada a nivel de la organización. Luego, quita las vinculaciones de roles de IAM que hacen referencia a las funciones personalizadas a nivel de la organización.

Después de migrar el proyecto, puedes actualizar las políticas de permisos para usar las funciones personalizadas a nivel de la organización en el recurso de organización de destino.

Para obtener más información, 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. Esta política rige durante cuánto tiempo se deben conservar los objetos. El bloqueo del bucket está protegido con una retención para evitar la eliminación accidental del proyecto.

La política de retención y la retención se conservan con el proyecto durante la migración. La retención no impide que migres el proyecto.

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

Los Controles del servicio de VPC mitigan los riesgos de robo de datos mediante la configuración de un perímetro de seguridad basado en proyectos alrededor de los Google Cloud servicios. 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 debas esperar varias horas o hasta un día para migrar un proyecto después de quitarlo de un perímetro de servicio.

Políticas de Acceso adaptado al contexto para cuentas de servicio

El Acceso adaptado al contexto permite a los usuarios definir políticas de acceso en Google Cloud recursos para cuentas de servicio en función de atributos de contexto como la red, la ubicación y la hora. No puedes migrar un proyecto que tenga al menos una política de Acceso adaptado al contexto para cuentas de servicio.

Para borrar una política de Acceso adaptado al contexto para cuentas de servicio, consulta Administra vinculaciones de acceso.

Ten en cuenta las siguientes consideraciones de tiempo cuando crees o borres políticas:

  • Creación de políticas: Es posible que una política de Acceso adaptado al contexto recién creada no bloquee las migraciones de inmediato. Esta demora de propagación puede durar hasta 24 horas después de que se crea la política.
  • Borrado de políticas: Después de que se quitan todas las políticas de Acceso adaptado al contexto de un proyecto, pueden pasar varias horas antes de que puedas migrar el proyecto.

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 estos objetos siguen funcionando después de la migración entre recursos de organización. Sin embargo, no puedes crear adjuntos de VLAN nuevos entre recursos de organización mientras estén divididos.

Es posible que los cambios de configuración realizados en un proyecto dividido no se propaguen en los recursos de organización. Te recomendamos que no dejes los proyectos divididos por mucho tiempo.

Interconexión de socio

No hay consideraciones especiales para migrar proyectos con Interconexión de socio. No se necesitan consideraciones especiales cuando se migran proyectos con Interconexión de socio.

Proyecto de administración

El proyecto de administración es un Google Cloud 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

Cuando migras una cuenta de servicio entre proyectos, se aplican los siguientes casos:

  • Si migras un proyecto con una cuenta de servicio entre proyectos adjunta, la cuenta de servicio sigue funcionando en el recurso de organización de destino. Esto se aplica incluso si una política de la organización restringe el dominio.
  • Si migras un proyecto que posee una cuenta de servicio entre proyectos que usa otro proyecto, la cuenta de servicio sigue funcionando. Sin embargo, no puedes usarla en recursos que tengan 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 project-A en organizations/12345678901 tiene adjunto serviceAccount-1. project-B y project-C en la misma organización también usan serviceAccount-1.

project-C tiene una política de la organización que solo permite el dominio organizations/12345678901.

Si agregas serviceAccount-1 a la vinculación de IAM para project-C antes de migrar project-A a organizations/45678901234, la cuenta de servicio funciona.

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 falla porque infringe la restricción de dominio.

Casos de asistencia

Si migras un proyecto con un caso de asistencia abierto, notifica a Atención al cliente de Cloud después de la migración. No puedes ver esos casos de asistencia hasta que Atención al cliente de Cloud actualice los metadatos al nuevo recurso de organización.

Si tu proyecto usa una pantalla de consentimiento de OAuth interna, solo los miembros del recurso de organización de destino pueden autorizar solicitudes después de la migración. Este cambio puede tardar hasta 24 horas en aplicarse. Hasta entonces, los miembros del recurso de organización de origen aún pueden autorizar solicitudes.

Para asegurarte de que los miembros de origen no pierdan el acceso, considera crear usuarios nuevos en el recurso de organización de destino o actualizar la configuración de la pantalla de consentimiento de OAuth:

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

  2. Si la app usa datos sensibles, solicita la verificación de app para permisos sensibles o restringidos. De lo contrario, los usuarios verán una pantalla de app no verificada.

API de acceso al SO de Cloud

Si la API de acceso al SO de Cloud está habilitada en tu proyecto de origen, asigna el roles/compute.osLoginExternalUser rol 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 (proyecto de consumidor) puede consumir la reserva mediante la creación de instancias de VM. Solo puedes compartir una reserva con los proyectos que se encuentren en la misma organización que el proyecto propietario.

Cuando migras un proyecto propietario o de consumidor, sucede lo siguiente:

  • Si migras el proyecto propietario, Compute Engine borra cualquier reserva creada por ese proyecto. Las instancias de VM en ejecución no se ven afectadas.
  • Si migras un 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 Google Cloud servicios, necesitas el iam.serviceAccounts.actAs permiso para conectar una cuenta de servicio a un recurso. Sin embargo, algunos servicios permitieron esto históricamente sin permisos explícitos de suplantación. Esto se documenta en Solicita permiso para conectar cuentas de servicio a los recursos.

Si tu recurso de organización de origen tiene este comportamiento heredado, pero el destino no, otorga el rol roles/iam.serviceAccountUser a los usuarios que conectan estas cuentas de servicio. Para obtener más información sobre los permisos, consulta Roles para la autenticación de la cuenta de servicio.

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

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

  3. En la casilla de filtro, ingresa constraints/appengine.enforceServiceAccountActAsCheck.

  4. Si aparece la política, el recurso de organización tiene el comportamiento heredado.

  5. Repite los pasos 3 y 4 para cada una de las siguientes restricciones:

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

Si aparece alguna de estas restricciones, tu recurso de organización usa el comportamiento heredado. Si ambos recursos de organización usan el comportamiento heredado, no es necesario realizar ninguna acción, pero considera aplicar la política para evitar la suplantación no deseada.

Migra proyectos con uso compartido de BigQuery

Si migras un proyecto que usa BigQuery sharing a otro recurso de organización, es posible que encuentres errores. Para resolverlos, comunícate con Atención al cliente de Cloud.

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 de BigQuery para actualizar un campo (por ejemplo, description) 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: el identificador único del proyecto
  • LOCATION: la ubicación del intercambio de datos
  • DATA_EXCHANGE_ID: el ID del intercambio de datos
  • UPDATE_DX_FIELD: el campo que se actualizará, como description
  • UPDATE_DX_VALUE: el valor actualizado

Servicio Backup and DR

Inhabilita Backup and DR antes de migrar proyectos a un recurso de organización diferente. Ten en cuenta el riesgo de interrupción cuando el servicio está inhabilitado. Vuelve a habilitar Backup and DR después de que se complete la migración.

Federación de identidades para cargas de trabajo

La federación de identidades para cargas de trabajo te permite otorgar a las cargas de trabajo locales o de múltiples nubes acceso a Google Cloud recursos. Los grupos de federación de identidades para cargas de trabajo son recursos con alcance de proyecto.

Cuando migras un proyecto, los grupos de identidades para cargas de trabajo y sus proveedores configurados dentro de ese proyecto se migran con el proyecto. No es necesario realizar ninguna acción adicional para mantener el acceso de las cargas de trabajo que usan estos grupos.

Etiquetas

Las etiquetas son pares clave-valor adjuntos a los recursos. No se migran las etiquetas creadas a nivel de la organización.

Si tu proyecto usa etiquetas a nivel de la organización para vinculaciones o restricciones de políticas, debes volver a crear las claves y los valores de las etiquetas en el recurso de organización de destino y volver a adjuntarlos a los proyectos migrados.

Migra proyectos con otorgamientos heredados de Privileged Access Manager

Antes de migrar un proyecto, te recomendamos que revoques cualquier otorgamiento activo con alcance en ese proyecto. Se crea un otorgamiento con alcance 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, la política de IAM se mueve a la organización nueva, pero el otorgamiento que la administra permanece en la organización anterior. El agente de servicio de Privileged Access Manager pierde el permiso para modificar la política de IAM en la organización nueva. En consecuencia, fallan las operaciones de revocación o retiro en ese otorgamiento, y el solicitante conserva el acceso hasta que vence el otorgamiento.

¿Qué sigue?