Cómo controlar casos especiales

Cuando migras proyectos de Google Cloud entre organizaciones, algunos recursos y parámetros de configuración requieren pasos adicionales para mantener la continuidad del servicio y evitar conflictos de configuración. Estos casos especiales incluyen proyectos sin un recurso de organización, recursos de VPC compartida, roles personalizados y cuentas de servicio entre proyectos. Antes de migrar un proyecto, asegúrate de tener los permisos de Identity and Access Management (IAM) necesarios 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 asistencia.

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 la 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 consola de Google Cloud . 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 de los proyectos para los usuarios.

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

gcloud

Ejecuta el comando siguiente:

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 (recurso de carpeta o 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 que tendrán en este proyecto 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 consola de Google Cloud .

    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 cuadro de 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: Es el ID del proyecto que se migrará.
  • ORGANIZATION_ID: Es el ID del recurso de la organización de destino.

API

Con la API de Resource Manager, puedes migrar un proyecto al recurso de organización configurando su campo parent con el ID del recurso de organización del recurso de organización.

Para migrar un proyecto al recurso de 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 organización 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.

En el siguiente fragmento de código, se muestran 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 rol roles/compute.osLoginExternalUser a cualquier principal que tenga acceso a ese proyecto.

VPC compartida

Puedes migrar proyectos de VPC compartida bajo 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 la restricción constraints/resourcemanager.allowEnabledServicesForExport en el elemento superior del proyecto que se exportará. Esta restricción debe incluir SHARED_VPC como un allowed_value.

No es necesario que inhabilites la VPC compartida antes de la migración. Sin embargo, primero debes migrar el proyecto host de VPC compartida y, luego, todos sus proyectos de servicio. Te recomendamos que hagas coincidir las reglas de firewall entre los recursos de la organización de origen y de 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 la organización de origen mientras migras otros.

Si migras el proyecto host, puedes volver a moverlo al recurso de la organización de origen. No hay un plazo exacto para el tiempo que los proyectos host y de servicio pueden estar en organizaciones diferentes. Sin embargo, una vez que comiences a migrar los proyectos de servicio, deberás migrarlos todos antes de poder volver a migrar el proyecto host.

Funciones de IAM personalizadas

Los roles personalizados 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álidos 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 un rol de IAM personalizado a nivel de la organización, la migración fallará. El error explica que el rol no existe en el recurso de organización de destino.

Para enumerar todos los roles personalizados de IAM en el recurso de tu organización, ejecuta el siguiente comando:

gcloud iam roles list --organization ORGANIZATION_ID

Reemplaza ORGANIZATION_ID por el ID del recurso de la organización. Para obtener más información, consulta Obtén el ID de tu recurso de 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:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Reemplaza lo siguiente:

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

Para solucionar este error, crea roles personalizados equivalentes a nivel de proyecto para cada rol personalizado heredado a nivel de organización. Luego, quita las vinculaciones de roles de IAM que hacen referencia a los roles personalizados a nivel de la organización.

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

Para obtener más información, consulta Crea y administra roles personalizados.

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 se protege 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 estableciendo un perímetro de seguridad basado en proyectos alrededor de los servicios de Google Cloud . 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 tardes varias horas o hasta un día en 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 que los usuarios definan políticas de acceso en los recursos de Google Cloud para las cuentas de servicio según 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 quiten todas las políticas de Acceso adaptado al contexto de un proyecto, pueden pasar varias horas antes de que puedas migrarlo.

Interconexión dedicada

Te recomendamos migrar juntos los proyectos con objetos de interconexión dedicada y los proyectos con adjuntos de VLAN. 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 los recursos de la 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 la 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 la interconexión de socio. No se necesitan consideraciones especiales cuando se migran proyectos con la interconexión de socio.

Proyecto de administración

El proyecto de administración es un proyecto de Google Cloud en la carpeta habilitada para apps que actúa como un repositorio central para todos los 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 seguirá funcionando en el recurso de la 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 seguirá 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 limite al dominio del recurso de la organización de origen.

Por ejemplo, supongamos que project-A en organizations/12345678901 tiene serviceAccount-1 adjunto. 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 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 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 podrás 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 la 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 de los recursos de la 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 la 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 los 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 rol roles/compute.osLoginExternalUser a cualquier principal que tenga acceso a ese proyecto. Esto garantiza que estas principales no pierdan el acceso en el 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 de propietario) o cualquier proyecto con el que se comparta (proyecto de consumidor) puede consumir la reserva creando 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 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, 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

En la mayoría de los servicios de Google Cloud , necesitas el permiso iam.serviceAccounts.actAs para conectar una cuenta de servicio a un recurso. Sin embargo, algunos servicios históricamente permitían esto sin permisos de suplantación de identidad explícitos. 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 adjunten estas cuentas de servicio. Para obtener más información sobre los permisos, consulta Roles para la autenticación de cuentas de servicio.

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

  1. En la consola de Google Cloud , 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 el cuadro 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 la organización usan el comportamiento heredado, no se requiere ninguna acción, pero considera aplicar la política para evitar la suplantación de identidad no deseada.

Migra proyectos con BigQuery sharing

Si migras un proyecto que usa BigQuery sharing a otro recurso de organización, es posible que se produzcan 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 es visible en la página de 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 la caché.

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: el identificador único del proyecto
  • LOCATION: Es la ubicación del intercambio de datos.
  • DATA_EXCHANGE_ID: el ID del intercambio de datos
  • UPDATE_DX_FIELD: Es 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 se inhabilita el servicio. 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 los recursos de Google Cloud . 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 en ese proyecto se migran con el proyecto. No se requiere ninguna acción adicional para mantener el acceso a las cargas de trabajo que usan estos grupos.

Etiquetas

Las etiquetas son pares clave-valor que se adjuntan a los recursos. Las etiquetas creadas a nivel de la organización no se migran.

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 con alcance activo en ese proyecto. Se crea un otorgamiento con permiso en un derecho heredado de una carpeta o organización y, luego, se limita a un proyecto secundario.

Cuando migras un proyecto con un otorgamiento con alcance activo, la política de IAM se traslada 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, cualquier operación de revocación o retiro de ese otorgamiento falla, y el solicitante conserva el acceso hasta que venza el otorgamiento.

¿Qué sigue?