Como migrar projetos

Este guia explica como mover um projeto entre organizações ou locais dentro de uma hierarquia de recursos.

O recurso projeto é a entidade organizadora de nível básico em uma organização do Google Cloud. Os projetos são criados em organizações e podem ser colocados em pastas ou no próprio recurso da organização, formando a hierarquia de recursos. Talvez seja necessário migrar projetos entre organizações devido a aquisições, requisitos regulamentares e separação de unidades de negócios, entre outros fatores.

Você pode usar a API Resource Manager para mover projetos entre organizações ou para outro local na hierarquia de recursos da organização atual. A API Resource Manager também permite reverter a migração, movendo o projeto de volta ao seu local original na hierarquia de recursos.

Criar um plano de migração

O mais importante é considerar como a migração afetará os serviços em execução no projeto. A API Resource Manager trata o recurso do projeto e todos os serviços em execução como uma única unidade. Isso significa que nenhuma alteração de configuração será aplicada dentro do projeto.

Embora a migração não faça alterações de configuração diretas no projeto, a alteração na hierarquia de recursos provavelmente terá um impacto na função do projeto e nos serviços em execução. As políticas herdadas, como o gerenciamento de identidade e acesso ou as políticas da organização, não serão movidas com o projeto durante a migração, apenas as políticas e contas de serviço anexadas diretamente ao recurso. Isso pode causar um comportamento não intencional depois que a migração é concluída.

Antes de migrar seu projeto, considere criar um plano de migração para determinar a prontidão de sua organização e dos projetos que você quer mover. Neste plano de migração, use um inventário de cada um dos serviços que seu projeto está executando e outros serviços que possam ser afetados pela migração ou pela hierarquia de recursos no destino do projeto: de dados.

Visão geral do inventário

Use o Inventário de recursos do Cloud para criar uma visão geral dos recursos em uso, incluindo as políticas de gerenciamento de identidade e acesso. Use-a para ajudar a descrever seu plano de migração.

Também é possível usar o Inventário de recursos do Cloud para transferir esses dados para o BigQuery. Isso permitirá que você consulte os dados usando SQL, que é mais fácil de ler em comparação com a interpretação de dados formatados em JSON. Para informações sobre como exportar esses dados, consulte Como exportar para o BigQuery.

Verificação da política

Quando você migrar seu projeto, ele não herdará mais as políticas do local atual na hierarquia de recursos e estará sujeito à avaliação de política vigente no destino. Verifique se as políticas em vigor no destino do projeto correspondem ao máximo possível das políticas que o projeto tinha no local de origem.

Todas as políticas aplicadas diretamente ao projeto ainda serão anexadas depois que a migração for concluída. Aplicar políticas diretamente ao projeto é uma boa maneira de verificar se as políticas corretas foram aplicadas desde a conclusão da migração.

As políticas de gerenciamento de identidade e acesso e as políticas da organização são herdadas pela hierarquia de recursos e podem bloquear o funcionamento de um serviço se não forem definidas corretamente. Determine a política efetiva no destino do projeto na hierarquia de recursos para garantir que a política esteja alinhada aos seus objetivos de governança.

Gerenciar chaves criptografadas

Verifique se o projeto tem uma chave criptografada gerenciada pelo cliente ou outro serviço de gerenciamento de chaves do Cloud ativado. As chaves criptográficas são de propriedade do projeto, e um usuário com acesso owner a esse projeto, portanto, poderá gerenciar e executar operações criptográficas em chaves no Cloud KMS nesse projeto.

Para mais informações, consulte Separação de tarefas.

Prévia dos recursos

Você pode ativar os recursos em organizações, pastas ou projetos. Se você ativou um recurso Alfa ou Beta no projeto, ele continuará funcionando após a migração. Se o recurso for particular e não estiver na lista de permissões da organização de destino, você não poderá fazer alterações de configuração após a conclusão da mudança.

Plano de reversão

Se você descobrir que algo não está funcionando em nenhum dos projetos migrados, mova-os de volta para o local original. Para fazer isso, é preciso ter as permissões de IAM necessárias e definir as políticas da organização necessárias para executar a migração do projeto de maneira inversa.

Para uma lista de permissões necessárias, consulte Atribuir permissões. Para as políticas da organização que você precisa configurar para permitir uma migração de projeto, consulte Configurar políticas da organização.

Pastas de importação e exportação dedicadas

A herança de políticas pode causar efeitos indesejados durante a migração de um projeto, tanto nas organizações de origem quanto de destino. É possível reduzir esse risco criando pastas específicas para armazenar apenas projetos para exportação e importação, garantindo que as mesmas políticas sejam herdadas pelas pastas em ambas as organizações. Também é possível definir permissões nessas pastas que serão herdadas para os projetos movidos dentro delas, ajudando a acelerar o processo de migração do projeto.

Ao planejar uma migração, primeiro configure uma pasta de origem dedicada. Para fazer isso, crie uma pasta para cada organização que você planeja exportar projetos. Em seguida, defina uma política da organização nessas pastas, cada uma com a restrição constraints/resourcemanager.allowedExportDestinations definida como a única organização para a qual você quer exportar projetos.

Por exemplo, é possível configurar pastas Export to Marketing Org e Export to Sales Org, cada uma com as restrições de política da organização definidas.

Da mesma forma, configure pastas de importação dedicadas na organização de destino, uma para cada organização de onde você quer importar projetos. Para fazer isso, crie uma pasta para cada organização da qual você planeja importar projetos. Em seguida, defina uma política da organização nessas pastas, cada uma com a restrição constraints/resourcemanager.allowedImportSources definida como a única organização de que você quer importar projetos.

Por exemplo, é possível configurar pastas Import from Marketing Org e Import from App Development Org, cada uma com as restrições de política da organização adequadas.

Em cada uma das pastas de importação e exportação, atribua o papel roles/resourcemanager.projectMover à pessoa que moverá os projetos. Esse papel será herdado por todos os projetos contidos nessas pastas, permitindo que o usuário execute as operações de movimentação em qualquer projeto que seja movido para essas pastas.

Depois de concluir a migração do projeto, remova essas pastas dedicadas.

Para mais informações sobre como definir políticas da organização, consulte Configurar políticas da organização.

Atribuir permissões

Você precisa das seguintes permissões para mover um projeto entre organizações.

Para receber essas permissões, peça ao administrador para conceder o papel sugerido no nível apropriado da hierarquia de recursos.

Permissões de migração de projetos

No recurso do projeto que você quer mover e no recurso pai, é necessário o papel Transportador de projetos (roles/resourcemanager.projectMover) ou outro papel que inclua as seguintes permissões para a API Resource Manager v1:

  • Permissão necessária para o recurso que você está movendo:

    • resourcemanager.projects.update
  • Permissão necessária para o recurso pai:

    • resourcemanager.projects.move

No recurso de destino, a permissão necessária depende do recurso para o qual você está movendo o projeto.

  • Se o recurso de destino for uma pasta, você precisará do papel Transportador de projeto (roles/resourcemanager.projectMover) ou de outro papel que inclua a permissão resourcemanager.projects.move.

  • Se o recurso de destino for uma organização, você precisará do papel "Criador do projeto" (roles/resourcemanager.projectCreator) ou de outro papel que inclua as permissões resourcemanager.projects.create.

Permissões de política da organização

Nas organizações de origem e de destino, você precisa ter o papel roles/orgpolicy.policyAdmin, que concede permissão para criar e gerenciar políticas da organização.

Configurar políticas da organização

Para mover um recurso do projeto para uma nova organização, primeiro é necessário aplicar uma política da organização que definirá as organizações para as quais o projeto pode ser movido. Também é necessário definir uma política da organização no destino que defina as organizações de onde os projetos podem ser importados.

No recurso pai do projeto que você quer mover, defina uma política da organização que inclua a restrição constraints/resourcemanager.allowedExportDestinations. Isso definirá o destino como um local válido para onde você poderá migrar o projeto.

No recurso de destino, defina uma política da organização que inclua a restrição constraints/resourcemanager.allowedImportSources. Isso definirá a origem como um local válido do qual é possível migrar seu projeto.

Por exemplo, imagine que você tinha um projeto my-test-project que existia em uma organização com o ID 12345678901 e queria movê-lo para uma nova organização para sua unidade de negócios secundária, com o ID. 45678901234

Você definiria uma política da organização em organizations/12345678901 com a restrição constraints/resourcemanager.allowedExportDestinations aplicada e under:organizations/45678901234 definido como allowed_value.

Em seguida, defina uma política da organização em organizations/45678901234 com a restrição constraints/resourcemanager.allowedImportSources aplicada e under:organizations/12345678901 definido como allowed_value.

Depois que essas políticas da organização forem aplicadas, será possível migrar my-test-project deorganizations/12345678901 aorganizations/45678901234, supondo que você tem as permissões indicadas em Atribuir permissões de dados.

Alterar a conta de faturamento de um projeto

As contas do Cloud Billing podem ser usadas em várias organizações. A migração de um projeto de uma organização para outra não afeta o faturamento, e as cobranças continuarão na conta de faturamento antiga. No entanto, as mudanças de organização geralmente também incluem um requisito para migrar para uma nova conta de faturamento.

Para alterar a conta de faturamento de um projeto atual, é preciso ter o papel roles/owner no projeto e o papel roles/billing.admin na conta de faturamento de destino. Para alterar a conta de faturamento, faça o seguinte:

  1. Acesse a Página de faturamento no Console do Cloud.
    Acessar a página Faturamento
  2. Clique no nome da conta de faturamento que você quer alterar.
  3. Em Projetos vinculados a esta conta de faturamento, localize o nome do projeto que será migrado e clique no botão de menu à direita.
  4. Clique em Alterar faturamento e selecione a nova conta de faturamento.
  5. Clique em Definir conta.

As cobranças já incorridas, mas que ainda não apareceram no histórico de faturamento, serão efetuadas na conta de faturamento anterior. Isso pode incluir cobranças de até dois dias antes da migração do projeto.

Mover uma conta de faturamento entre organizações

Uma conta de faturamento pode ser movida de uma organização para outra, embora essa geralmente não seja uma etapa necessária. A maioria das organizações existentes já terá uma conta de faturamento que precisará ser usada. Se você precisar migrar uma conta de faturamento atual, faça o seguinte:

  1. Consiga o papel roles/billing.admin nas organizações de origem e de destino.
  2. Acesse a Página de faturamento no Console do Cloud.
    Acessar a página Faturamento
  3. Clique no nome da conta de faturamento que você quer migrar.
  4. Na parte superior da página Gerenciamento de contas, clique em Alterar organização.
  5. Selecione a organização de destino e clique em OK.

A conta de faturamento agora está associada à organização especificada.

Faça a migração

Se você tiver as permissões do IAM apropriadas e as políticas da organização necessárias forem aplicadas, use a API Resource Manager para mover um recurso do projeto de dados.

gcloud

Para migrar um projeto em uma organização, execute o seguinte comando:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Também é possível especificar uma pasta como o recurso de destino com o seguinte comando:

gcloud beta projects move PROJECT_ID \
    --folder FOLDER_ID

Em que:

  • PROJECT_ID é o ID ou o número do projeto que você quer migrar.
  • ORGANIZATION_ID é o ID da organização para onde você quer mover o projeto. Só é possível especificar um destino, seja uma organização ou uma pasta.
  • FOLDER_ID é o ID da pasta para onde você quer mover o projeto. Só é possível especificar um destino, seja uma pasta ou uma organização.

API

Usando a API Resource Manager v1, é possível mover um projeto definindo o campo parent como o ID do recurso de destino.

Para migrar um projeto=

  • Receba o objeto project usando o método projects.get().
  • Defina o campo parent como o ID da organização ou o ID da pasta da pasta para onde você está movendo.
  • Atualize o objeto project usando o método projects.update().

O snippet de código a seguir demonstra as etapas acima:

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

    project = crm.projects().update(
    projectId=flags.projectId, body=project).execute()

Reverter uma migração

Se você moveu um projeto por engano, pode reverter a operação executando a mudança novamente, com a origem antiga como o novo destino e a versão antiga como a nova origem. Você precisa ter as permissões de IAM necessárias e as políticas da organização aplicadas para permitir isso como se fosse uma migração totalmente nova.

Como lidar com casos especiais

Como migrar projetos sem organização

É possível migrar um projeto que não esteja associado a uma organização para uma organização. No entanto, não é possível revertê-la para Sem organização usando esse processo. Se você tiver um projeto associado à sua organização e quiser revertê-lo para Sem organização, entre em contato com o representante de suporte para receber ajuda.

O processo de migração de um projeto não associado a uma organização é semelhante ao de um projeto entre organizações, mas não exige todas as etapas envolvidas no plano de migração. Para migrar um projeto para uma organização, siga estas etapas:

  1. Verifique o impacto neste projeto das políticas que serão herdadas.

  2. Crie uma pasta de importação dedicada na organização de destino, se quiser.

  3. Atribua permissões de gerenciamento de identidade e acesso ao projeto e ao pai de destino, conforme detalhado em Atribuir permissões.

  4. Determine se você precisa alterar a conta de faturamento.

Em seguida, faça a migração.

Console

Se você quiser migrar um projeto para uma organização, faça o seguinte:

  1. Abra a página IAM e administrador > Configurações no Console do Cloud.

    Abrir a página Configurações

  2. Selecione o Seletor de projetos na parte superior da página.

  3. No seletor de organização, selecione Nenhuma organização. Se você não estiver associado a nenhuma organização, o seletor de organização não será exibido, e você poderá ignorar esta etapa.

  4. Selecione o projeto que você quer migrar.

    Captura de tela do seletor de projetos

  5. Na parte superior da página, clique em Migrar.

  6. Na lista suspensa Organização, selecione a organização para onde quer migrar o projeto.

gcloud

Se você quiser migrar um projeto para uma organização, execute o seguinte comando:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Onde:

  • PROJECT_ID é o código do projeto que você quer mover para a organização
  • ORGANIZATION_ID é o código da organização para onde você quer migrar o projeto.

API

Usando a Resource Manager API, você pode mover um projeto para o recurso da organização definindo seu campo parent como o ID da organização.

Se você quiser migrar um projeto para a organização, faça o seguinte:

  • Receba o objeto project usando o método projects.get().
  • Defina o campo parent como o ID da Organização.
  • Atualize o objeto project usando o método projects.update().

Não é possível alterar o campo parent depois de defini-lo.

O snippet de código a seguir demonstra as etapas acima:

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

VPC compartilhada

Os projetos de VPC compartilhada podem ser migrados seguindo determinadas condições. Primeiro, um usuário com o papel roles/orgpolicy.policyAdmin na organização de origem precisa definir uma política da organização que contenha a restrição constraints/resourcemanager.allowEnabledServicesForExport no pai do projeto a ser exportado. Essa restrição precisa listar SHARED_VPC como um allowed_value.

O projeto host da VPC compartilhada precisa ser migrado primeiro, seguido de todos os projetos de serviço. Recomendamos que você corresponda as regras de firewall entre as organizações nos locais de origem e de destino, o que deve minimizar possíveis problemas e evitar inatividade nos projetos e na rede durante a migração. Não oferecemos garantias sobre a integridade da sua rede se você deixar alguns projetos de serviço na organização de origem indefinidamente enquanto migra outros.

Se você mover o projeto host, poderá movê-lo de volta para a organização de origem. No entanto, depois de começar a mover os projetos de serviço, mova todos eles para mover o projeto host novamente.

Papéis personalizados de gerenciamento de identidade e acesso

É possível criar papéis personalizados de gerenciamento de identidade e acesso no nível da organização para fornecer controle granular do acesso aos recursos. No entanto, eles são válidos apenas na organização em que foram criados. Se você tentar mover um projeto que contém uma vinculação de política de IAM de um usuário para um papel do IAM personalizado no nível da organização, a transferência falhará com um erro de condição prévia com falha, explicando que o papel em questão. não existe na organização de destino;

Para listar todos os papéis de IAM personalizados no nível da organização, execute o seguinte comando da ferramenta de linha de comando gcloud:

gcloud iam roles list --organization ORGANIZATION_ID

Em que ORGANIZATION_ID é o ID da organização que você quer listar os papéis. Para mais informações sobre como encontrar o ID da organização, consulte Como criar e gerenciar organizações.

Para informações sobre um papel personalizado de gerenciamento de identidade e acesso na sua organização, execute o seguinte comando da ferramenta de linha de comando gcloud:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Em que:

  • ORGANIZATION_ID é o ID da organização mãe do papel.

  • ROLE_ID é o nome do papel que você quer descrever.

Para contornar o erro de pré-condição com falha, crie papéis personalizados equivalentes no nível do projeto para cada um dos papéis personalizados no nível da organização que o projeto herdar. Em seguida, remova as vinculações de papéis do IAM que referenciam os papéis personalizados no nível da organização.

Depois que o projeto for migrado, você poderá atualizar as políticas do IAM para usar os papéis personalizados no nível da organização na organização de destino.

Para mais informações sobre papéis personalizados, consulte Como criar e gerenciar papéis personalizados.

Bloqueio do bucket

Com o Bloqueio de bucket do Cloud Storage, é possível configurar uma política de retenção de dados em um bucket do Cloud Storage que determina quanto tempo os objetos no bucket precisam ser retidos. O bloqueio do bucket é protegido por uma garantia para evitar a exclusão acidental do projeto.

A política e a garantia de retenção são mantidas com o projeto durante uma migração, mas você precisa estar ciente se está movendo um projeto com um bloqueio de bucket aplicado e evite movimentos acidentais.

Perímetros de segurança do VPC Service Controls

O VPC Service Controls permite que os usuários configurem um perímetro de segurança baseado em projetos em torno dos serviços do Google Cloud para reduzir os riscos de exfiltração de dados. Não é possível migrar um projeto protegido por um perímetro de segurança do VPC Service Controls.

Para remover um projeto de um perímetro de segurança, consulte Como gerenciar perímetros de serviço. Os projetos em perímetros do VPC Service Controls não podem ser impedidos de serem movidos entre organizações por até um dia após um perímetro ter sido criado ou atualizado. Pode levar várias horas para que o projeto seja móvel após ser removido do perímetro de serviço.

Interconexão dedicada

Recomendamos migrar projetos com objetos de Interconexão dedicada e projetos com anexos da VLAN para esses objetos de Interconexão dedicada. Embora os projetos com objetos de Interconexão dedicada ou anexos da VLAN conectados a eles possam ser migrados e funcionem entre organizações, não será possível criar novos anexos da VLAN na divisão da organização.

As alterações de configuração feitas em um projeto em uma organização que tenha um objeto de Interconexão dedicada anexado ou um anexo da VLAN para o objeto de Interconexão dedicada podem não ser propagadas para a outra. Portanto, recomendamos não deixar esses projetos divididos. organizações por muito tempo, se possível.

Interconexão por parceiro

Não há considerações especiais necessárias ao migrar projetos com o Partner Interconnect.

Assured Workloads

Não é possível mover um projeto do Assured Workloads entre as organizações. Qualquer tentativa de fazer isso será bloqueada programaticamente.

Contas de serviço de projetos cruzados

Se você mover um projeto que tem uma conta de serviço entre projetos anexada a ela, essa conta ainda funcionará na organização de destino. Esse projeto continuará funcionando com a conta de serviço anexada, mesmo que haja uma política da organização que restrinja o domínio desse projeto.

Se você estiver transferindo um projeto que é proprietário de uma conta de serviço entre projetos anexada a outro projeto na organização de origem, a conta de serviço ainda funcionará na organização de destino. No entanto, você não poderá usar a conta de serviço em nenhum recurso que tenha uma política da organização de restrição de domínio aplicada que os restrinja ao domínio da organização de origem.

Por exemplo, suponha que você tenha project-A, em organizations/12345678901. Este projeto tem serviceAccount-1 anexado a ele, que está configurado como uma conta de serviço entre projetos. project-B e project-C, também em organizations/12345678901, também usam serviceAccount-1.

Você aplicou uma política da organização com a restrição de domínio para project-C, que só permite que ela acesse o domínio de organizations/12345678901.

Se você adicionar serviceAccount-1 à vinculação do IAM para project-C e mover project-A para organizations/45678901234, a conta de serviço funcionará.

Se você mover project-A para organizations/45678901234 e tentar adicionar serviceAccount-1 à vinculação do IAM para project-C, a vinculação falhará porque viola a restrição de domínio.

Histórico de consultas

Se você mover um projeto com um caso de suporte aberto, precisará falar com o contato do Suporte do Google para informar que a migração ocorreu. Todos os projetos que tiverem um caso de suporte aberto com o Google não poderão visualizá-los até que o Suporte do Google atualize os metadados do caso para apontar para a nova organização.

Se o projeto estiver configurado para usar uma tela de consentimento do OAuth interno e você migrá-lo para outra organização, somente os membros da organização de destino poderão autorizar solicitações. Pode levar até 24 horas para que esse comportamento entre em vigor. Até lá, os membros da organização de origem podem autorizar solicitações.

As etapas abaixo explicam como garantir que os membros da sua organização de origem não percam o acesso durante a migração. Considere a criação de novos usuários na organização de destino para os membros da organização, de modo que você não precise alterar a configuração da tela de consentimento do OAuth.

Para evitar a perda de acesso dos membros da organização de origem:

  1. Atualize a tela de consentimento do OAuth para ser externa, em vez de interna.

  2. Os apps marcados como internos e que usam dados confidenciais não precisam solicitar a verificação de apps. Se o app usar dados confidenciais, quando a tela de consentimento for atualizada para usuários externos, os usuários da organização de origem verão uma tela do app não verificada antes tela de autorização. Para evitar isso, solicite a verificação do app para o uso de escopos confidenciais ou restritos.

Login do SO

Se o Login do SO estiver ativado no projeto de origem, atribua o papel de IAM roles/compute.osLoginExternalUser aos principais que podem acessar o projeto de origem, na organização de destino, para evitar esses principais perdedores de acesso.

Como anexar contas de serviço a recursos

Para a maioria dos serviços do Google Cloud, os usuários precisam da permissão iam.serviceAccounts.actAs em uma conta de serviço para anexar essa conta a um recurso. No entanto, para facilitar a integração de determinados serviços, no passado os usuários podiam anexar contas de serviço a recursos, mesmo que eles não tivessem permissão para personificar as contas. Isso está documentado aqui.

Se a organização de origem de um cliente tiver o comportamento legado (o anexo de contas de serviço é possível sem a concessão de papel normal) e a organização de destino não, conceda roles/iam.serviceAccountUser aos usuários que anexarem essas contas de serviço recursos. Para informações sobre como representar contas de serviço, consulte Como representar contas de serviço.

Para ver se a organização tem o comportamento legado, faça o seguinte:

  1. No Console do Cloud, acesse a página Políticas da organização.

    Acessar a página "Políticas da organização"

  2. No seletor de projetos na parte superior da página, escolha a organização que você quer verificar o status legado.

  3. Na caixa de filtro na parte superior da lista de políticas da organização, digite constraints/appengine.enforceServiceAccountActAsCheck.

  4. Se a política da organização appengine.enforceServiceAccountActAsCheck aparecer na lista, a organização terá o comportamento legado.

  5. Repita as etapas 3 e 4 para cada uma das seguintes restrições de política da organização:

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck
  6. Se alguma dessas restrições de política da organização aparecer, sua organização usará o comportamento legado.

Se a organização de origem tiver o comportamento legado e o destino não tiver, conceda os papéis conforme mencionado acima. Se as organizações de origem e de destino tiverem o comportamento legado, nenhuma ação será necessária. No entanto, é necessário aplicar a política para evitar a representação não intencional.