Ao migrar projetos do Google Cloud entre organizações, alguns recursos e configurações exigem etapas adicionais para manter a continuidade do serviço e evitar conflitos de configuração. Esses casos especiais incluem projetos sem um recurso de organização, recursos de VPC compartilhada, papéis personalizados e contas de serviço entre projetos. Antes de migrar um projeto, verifique se você tem as permissões necessárias do Identity and Access Management (IAM) no projeto, no recurso pai e no recurso de destino.
Migrar projetos que não estão associados a um recurso de organização
É possível migrar um projeto criado sem um recurso de organização associado para a hierarquia de um recurso de organização. No entanto, não é possível reverter esse processo. Para reverter um projeto para Sem organização, entre em contato com o Cloud Customer Care para receber ajuda.
Para migrar um projeto que não está associado a um recurso de organização, é necessário ter o papel roles/resourcemanager.projectIamAdmin no projeto. Você
também precisa ter o papel roles/resourcemanager.projectCreator no recurso da organização de destino.
Se você não tiver a permissão resourcemanager.organizations.get no recurso da organização mãe, seus projetos podem não aparecer como esperado na organização no console do Google Cloud . Isso pode fazer parecer que o
projeto não está associado a um recurso de organização. Para mais informações,
consulte Como restringir a visibilidade do projeto para os usuários.
Para determinar se o projeto está associado a um recurso da organização, faça o seguinte:
gcloud
Execute este comando:
gcloud projects describe PROJECT_ID
Substitua PROJECT_ID pelo ID do projeto que você quer migrar.
Se o recurso parent não aparecer na saída, isso confirma que o projeto não está associado a um recurso da organização.
Se o recurso pai (recurso de pasta ou organização) for exibido na saída, isso confirmará que o projeto está associado a um recurso da organização.
O processo de migração de um projeto não associado a um recurso da organização é semelhante ao processo de migração de um projeto entre recursos da organização, mas não requer todas as etapas do plano de migração. Para migrar um projeto para um recurso de organização, siga estas etapas:
Verifique o impacto neste projeto das políticas que serão herdadas.
Crie uma pasta de importação dedicada no recurso da organização de destino, se necessário.
Atribua permissões do Identity and Access Management para o projeto e o recurso pai de destino, conforme detalhado em Atribuir permissões.
Determine se você precisa alterar a conta de faturamento.
Em seguida, faça a migração usando um dos seguintes métodos:
Console
Abra a página IAM e administrador > Configurações no console do Google Cloud .
Selecione seu projeto (um com Sem organização) usando o seletor de projetos.
Na parte de cima da página Configurações, clique em Migrar.
Na caixa de diálogo que aparece, selecione o recurso da organização para o qual você quer migrar o projeto e clique em Migrar.
gcloud
Para migrar um projeto para um recurso de organização, execute o seguinte comando:
gcloud beta projects move PROJECT_ID \
--organization ORGANIZATION_ID
Substitua:
- PROJECT_ID: o ID do projeto a ser migrado.
- ORGANIZATION_ID: o ID do recurso da organização de destino.
API
Usando a API Resource Manager, é possível migrar um projeto para o recurso de organização definindo o campo parent como o ID do recurso de organização.
Para migrar um projeto para o recurso da organização:
- Acesse o objeto
projectusando o métodoprojects.get(). - Defina o campo
parentcomo o ID do recurso da organização. - Atualize o objeto
projectusando o métodoprojects.update().
Não é possível alterar o campo parent depois de defini-lo.
O snippet de código abaixo demonstra essas etapas:
project = crm.projects().get(projectId=flags.projectId).execute()
project['parent'] = {
'type': 'organization',
'id': flags.organizationId
}
Se a API Login do SO na nuvem estiver ativada no projeto de origem, atribua o papel roles/compute.osLoginExternalUser a todos os principais que têm acesso a esse projeto.
VPC compartilhada
É possível migrar projetos de VPC compartilhada em determinadas condições. Primeiro, um
usuário com o papel roles/orgpolicy.policyAdmin no recurso da organização de origem
precisa definir uma política da organização que contenha a
restrição constraints/resourcemanager.allowEnabledServicesForExport no
recurso pai do projeto a ser exportado. Essa restrição precisa listar SHARED_VPC
como um allowed_value.
Não é necessário desativar a VPC compartilhada antes da migração. No entanto, é preciso migrar primeiro o projeto host da VPC compartilhada e, em seguida, todos os projetos de serviço dele. Recomendamos que você corresponda as regras de firewall entre os recursos da organização de origem e de destino para minimizar possíveis problemas e evitar inatividade. Não garantimos a integridade da sua rede se você deixar projetos de serviço no recurso da organização de origem enquanto migra outros.
Se você migrar o projeto host, poderá movê-lo de volta para o recurso da organização de origem. Não há um prazo exato para que os projetos host e de serviço possam estar em organizações diferentes. No entanto, depois de iniciar a migração de projetos de serviço, é necessário migrar todos eles antes de migrar o projeto host novamente.
Papéis personalizados do IAM
Os papéis personalizados do Identity and Access Management fornecem controle granular de acesso aos recursos no nível do recurso da organização, mas só são válidos no recurso da organização em que são criados. Se você migrar um projeto que contém uma vinculação de política de permissão para um papel personalizado do IAM no nível da organização, a migração vai falhar. O erro explica que o papel não existe no recurso da organização de destino.
Para listar todos os papéis personalizados do IAM no recurso da organização, execute o seguinte comando:
gcloud iam roles list --organization ORGANIZATION_ID
Substitua ORGANIZATION_ID pelo ID do recurso da organização. Para mais informações, consulte Acessar o ID do recurso da organização.
Para receber informações sobre um papel personalizado do Identity and Access Management no recurso da organização, execute o seguinte comando:
gcloud iam roles describe --organization ORGANIZATION_ID \
ROLE_ID
Substitua:
- ORGANIZATION_ID: o ID do recurso da organização.
- ROLE_ID: o nome do papel a ser descrito.
Para contornar esse erro, crie papéis personalizados equivalentes para envolvidos no projeto para cada papel personalizado herdado no nível da organização. Em seguida, remova as vinculações de papel do IAM que fazem referência aos papéis personalizados no nível da organização.
Depois de migrar o projeto, é possível atualizar as políticas de permissão para usar os papéis personalizados no nível da organização no recurso de organização de destino.
Para mais informações, consulte Como criar e gerenciar papéis personalizados.
Bloqueio do bucket
O Bloqueio de buckets do Cloud Storage permite configurar uma política de retenção de dados em um bucket do Cloud Storage. Essa política determina por quanto tempo os objetos precisam ser retidos. O bloqueio de bucket é protegido por uma garantia para evitar a exclusão acidental do projeto.
A política de retenção e a garantia são mantidas com o projeto durante a migração. A garantia não impede que você migre o projeto.
Perímetros de segurança do VPC Service Controls
O VPC Service Controls reduz os riscos de exfiltração de dados configurando um perímetro de segurança baseado em projeto em torno dos serviços doGoogle Cloud . 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. Pode levar várias horas ou até um dia para migrar um projeto depois de removê-lo de um perímetro de serviço.
Políticas de acesso baseado no contexto para contas de serviço
O Acesso Baseado no Contexto permite que os usuários definam políticas de acesso em recursos do Google Cloud para contas de serviço com base em atributos de contexto, como rede, local e horário. Não é possível migrar um projeto que tenha pelo menos uma política de acesso baseado no contexto para contas de serviço.
Para excluir uma política de acesso baseado no contexto para contas de serviço, consulte Como gerenciar vinculações de acesso.
Observe as seguintes considerações de tempo ao criar ou excluir políticas:
- Criação de políticas: uma política de acesso baseado no contexto recém-criada pode não bloquear as migrações imediatamente. Esse atraso de propagação pode durar até 24 horas após a criação da política.
- Exclusão de políticas: depois que todas as políticas de acesso baseado no contexto forem removidas de um projeto, pode levar várias horas até que você possa migrar o projeto.
Interconexão dedicada
Recomendamos migrar projetos com objetos de Interconexão dedicada e projetos com anexos da VLAN juntos. Os projetos com esses objetos continuam funcionando após a migração entre recursos da organização. No entanto, não é possível criar novos anexos da VLAN entre recursos da organização enquanto eles estão divididos.
As mudanças de configuração feitas em um projeto dividido podem não ser propagadas nos recursos da organização. Recomendamos que você não deixe os projetos divididos por muito tempo.
Interconexão por parceiro
Não há considerações especiais para migrar projetos com a Interconexão por parceiro. Não há considerações especiais necessárias ao migrar projetos com a Interconexão por parceiro.
Projeto de gerenciamento
O projeto de gerenciamento é um projeto do Google Cloud na pasta habilitada para apps que funciona como um repositório central para todos os metadados centrados em aplicativos. Cada pasta habilitada para apps contém apenas um projeto de gerenciamento. O projeto de gerenciamento fornece a infraestrutura para bibliotecas de aplicativos e APIs, incluindo faturamento, cotas e controle de acesso. Não é possível migrar um projeto de gerenciamento.
Contas de serviço de projetos cruzados
Ao migrar uma conta de serviço entre projetos, os seguintes casos se aplicam:
- Se você migrar um projeto com uma conta de serviço entre projetos anexada, ela vai continuar funcionando no recurso de organização de destino. Isso se aplica mesmo que uma política da organização restrinja o domínio.
- Se você migrar um projeto que tenha uma conta de serviço entre projetos usada por outro projeto, a conta de serviço vai continuar funcionando. No entanto, não é possível usá-lo em recursos que tenham uma política da organização de restrição de domínio aplicada que os restrinja ao domínio do recurso da organização de origem.
Por exemplo, suponha que project-A em organizations/12345678901 tenha
serviceAccount-1 anexado. project-B e project-C na mesma organização também usam serviceAccount-1.
project-C tem uma política da organização que permite apenas o
domínio organizations/12345678901.
Se você adicionar serviceAccount-1 à vinculação do IAM para project-C
antes de migrar project-A para organizations/45678901234, a conta de serviço
vai funcionar.
Se você migrar project-A para organizations/45678901234 e tentar adicionar
serviceAccount-1 à vinculação do IAM para project-C, a
vinculação vai falhar porque viola a restrição de domínio.
Histórico de consultas
Se você migrar um projeto com um caso de suporte aberto, notifique o Cloud Customer Care após a migração. Não será possível visualizar esses casos de suporte até que o Cloud Customer Care atualize os metadados para o novo recurso da organização.
Tela de permissão OAuth
Se o projeto usar uma tela de permissão OAuth interna, somente os membros do recurso da organização de destino poderão autorizar solicitações após a migração. A mudança pode levar até 24 horas para entrar em vigor. Até lá, os membros do recurso da organização de origem ainda poderão autorizar solicitações.
Para garantir que os membros da origem não percam o acesso, crie novos usuários no recurso da organização de destino ou atualize a configuração da tela de permissão do OAuth:
Atualize a tela de consentimento do OAuth para ser externa, em vez de interna.
Se o app usar dados sensíveis, solicite a verificação de apps para escopos sensíveis ou restritos. Caso contrário, os usuários vão ver uma tela de app não verificado.
API Login do SO
Se a API Login do SO na nuvem estiver ativada no projeto de origem, atribua o papel roles/compute.osLoginExternalUser a todos os principais que têm acesso a esse projeto. Isso garante que
esses principais não percam o acesso no recurso da organização de destino.
Reservas compartilhadas de instâncias de máquina virtual (VM)
Em uma reserva compartilhada, o projeto que criou a reserva (projeto proprietário) ou qualquer projeto com que ela seja compartilhada (projeto consumidor) pode consumir a reserva criando instâncias de VM. Só é possível compartilhar uma reserva com projetos da mesma organização do projeto do proprietário.
Quando você migra um projeto de proprietário ou consumidor, acontece o seguinte:
- Se você migrar o projeto proprietário, o Compute Engine vai excluir todas as reservas criadas por ele. As instâncias de VM em execução não são afetadas.
- Se você migrar um projeto de consumidor, ele vai parar de consumir recursos de qualquer reserva compartilhada na organização anterior.
Saiba mais em Como as reservas compartilhadas funcionam.
Como anexar contas de serviço a recursos
Para a maioria dos serviços do Google Cloud , é preciso ter a permissão iam.serviceAccounts.actAs
para anexar uma conta de serviço a um recurso. No entanto, alguns serviços
historicamente permitiam isso sem permissões explícitas de representação. Isso está
documentado em Como exigir permissão para anexar contas de serviço a recursos.
Se o recurso da organização de origem tiver esse comportamento legado, mas o de destino não, conceda o papel roles/iam.serviceAccountUser aos usuários que anexarem essas contas de serviço. Para mais informações sobre permissões, consulte
Papéis para autenticação da conta de serviço.
Para verificar se o recurso da organização tem o comportamento legado:
No console do Google Cloud , acesse a página Políticas da organização:
No seletor de recursos, escolha o recurso da organização que você quer verificar.
Na caixa de filtro, digite
constraints/appengine.enforceServiceAccountActAsCheck.Se a política aparecer, o recurso da organização terá o comportamento legado.
Repita as etapas 3 e 4 para cada uma das seguintes restrições:
appengine.enforceServiceAccountActAsCheckdataflow.enforceComputeDefaultServiceAccountCheckdataproc.enforceComputeDefaultServiceAccountCheckcomposer.enforceServiceAccountActAsCheck
Se alguma dessas restrições aparecer, o recurso da organização usará o comportamento legado. Se ambos os recursos da organização usarem o comportamento legado, nenhuma ação será necessária, mas considere aplicar a política para evitar a representação não intencional.
Como migrar projetos com o BigQuery Sharing
Se você migrar um projeto que usa o compartilhamento do BigQuery para outro recurso da organização, talvez encontre erros. Para resolver esses problemas, entre em contato com o Cloud Customer Care.
Se o recurso de troca de dados da organização anterior não estiver visível na
página do administrador de compartilhamento da nova organização,
use a API de compartilhamento do BigQuery para atualizar um campo (por exemplo,
description) para acionar uma atualização de cache.
Use o 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 }
Substitua:
- PROJECT_ID: o identificador exclusivo do projeto.
- LOCATION: o local da troca de dados
- DATA_EXCHANGE_ID: o ID da troca de dados.
- UPDATE_DX_FIELD: o campo a ser atualizado, como
description - UPDATE_DX_VALUE: o valor atualizado.
Serviço de backup e DR
Desative o Backup e DR antes de migrar projetos para um recurso de organização diferente. Considere o risco de interrupção quando o serviço estiver desativado. Reative o Backup e DR após a conclusão da migração.
Federação de identidade da carga de trabalho
A federação de identidade da carga de trabalho permite conceder acesso às cargas de trabalho locais ou multicloud aos recursos do Google Cloud . Os pools de federação de identidade da carga de trabalho são recursos com escopo de projeto.
Quando você migra um projeto, os pools de identidade da carga de trabalho e os provedores configurados nele são migrados com o projeto. Nenhuma ação adicional é necessária para manter o acesso às cargas de trabalho que usam esses pools.
Tags
Tags são pares de chave-valor anexados a recursos. As tags criadas no nível da organização não são migradas.
Se o projeto usar tags no nível da organização para vinculações ou restrições de política, será necessário recriar as chaves e os valores de tag no recurso de organização de destino e anexá-los novamente aos projetos migrados.
Migrar projetos com concessões herdadas do Privileged Access Manager
Antes de migrar um projeto, recomendamos que você revogue todas as concessões com escopo ativas nele. Uma concessão com escopo é criada em um direito de acesso herdado de uma pasta ou organização e, em seguida, tem o escopo definido para um projeto filho.
Quando você migra um projeto com uma concessão com escopo ativa, a política do IAM é movida para a nova organização, mas a concessão que a gerencia permanece na organização anterior. O agente de serviço do Privileged Access Manager perde a permissão para modificar a política do IAM na nova organização. Consequentemente, qualquer operação de revogação ou retirada nessa concessão falha, e o solicitante mantém o acesso até que a concessão expire.