Este documento fornece informações sobre como lidar com casos especiais durante a migração de projetos. Ao migrar um projeto, verifique se você tem as permissões necessárias do IAM concedidas no projeto, no recurso pai e no recurso de destino.
Como migrar projetos que não estão associados a um recurso de organização
É possível migrar um projeto que não está associado a um recurso de organização para um recurso de organização. No entanto, não é possível revertê-la para Sem organização usando esse processo. Se você tiver um projeto associado ao recurso da sua organização e quiser revertê-lo para Nenhuma organização, entre em contato com o representante de suporte para receber ajuda.
Você precisa ter o papel roles/resourcemanager.projectCreator atribuído no recurso da organização de destino.
Se você não tiver a permissão resourcemanager.organizations.get no recurso da organização pai do projeto, é provável que seus projetos não sejam refletidos conforme o esperado na organização real no console do Google Cloud. Isso pode fazer parecer que o projeto não está associado
a nenhum recurso da organização. Para mais informações, consulte
Como restringir a visibilidade do projeto para 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 pai não for mostrado na saída, isso confirma que o projeto não está associado a um recurso da organização.
Se o recurso pai (pasta ou recurso de organização) for exibido na saída, isso confirma que o projeto está associado a um recurso de organização.
O processo de migração de um projeto não associado a um recurso de organização é semelhante ao de um projeto entre recursos de organização, mas não exige todas as etapas envolvidas no 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 quiser.
Atribua permissões do Identity and Access Management ao projeto e ao 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.
Console
Para migrar um projeto para um recurso de organização:
Abra a página IAM e administrador > Configurações no console do Google Cloud.
Selecione o Seletor de projetos na parte superior da página.
No seletor de organização, selecione Nenhuma organização. Se você não estiver associado a nenhum recurso de organização, o seletor de organização não vai aparecer, e você poderá pular esta etapa.
Selecione o projeto que você quer migrar.
Na parte superior da página, clique em Migrar.
Na lista suspensa Organização, selecione o recurso da organização para onde você quer migrar seu projeto.
gcloud
Para migrar um projeto para um recurso de organização, execute o seguinte comando:
gcloud beta projects move PROJECT_ID \
--organization ORGANIZATION_ID
Em que:
- PROJECT_ID é o ID do projeto que você quer migrar para o recurso da organização.
- ORGANIZATION_ID é o ID do recurso da organização para o qual você quer migrar o projeto.
API
Usando a API Resource Manager, você pode migrar um projeto para o recurso da organização
definindo o campo parent como o ID do recurso da organização.
Para migrar um projeto para o recurso da organização:
- Receba 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 a seguir demonstra as etapas acima:
project = crm.projects().get(projectId=flags.projectId).execute()
project['parent'] = {
'type': 'organization',
'id': flags.organizationId
}
Se o Login do SO estiver ativado no
projeto de origem, será necessário atribuir o papel roles/compute.osLoginExternalUser
a todos os principais que têm acesso a esse projeto.
VPC compartilhada
Os projetos de VPC compartilhada podem ser migrados seguindo 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 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, 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 os recursos da organização 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 no recurso da organização de origem indefinidamente 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 de quanto tempo o projeto host e os projetos de serviço podem estar em diferentes organizações. No entanto, quando você começar a migrar os projetos de serviço, será necessário migrar todos eles antes de migrar o projeto host novamente.
Papéis personalizados de gerenciamento de identidade e acesso
É possível criar papéis personalizados do Identity and Access Management acesso no nível do recurso da organização para fornecer controle granular do acesso aos recursos. No entanto, eles são válidos apenas no recurso da organização em que foram criados. Se você tentar migrar um projeto que contém uma vinculação de política do IAM de um usuário para um papel do IAM personalizado no nível do recurso da organização, a migração vai falhar com um erro de condição prévia, explicando que o papel em questão não existe no recurso da organização de destino.
Para listar todos os papéis personalizados do IAM no nível do recurso da sua organização, execute o seguinte comando da Google Cloud CLI:
gcloud iam roles list --organization ORGANIZATION_ID
Em que ORGANIZATION_ID é o ID do recurso da organização
que você quer listar os papéis. Para mais informações sobre como encontrar o
ID do recurso da organização, consulte Criar e gerenciar recursos da organização.
Para informações sobre um papel personalizado do Identity and Access Management no recurso da sua organização, execute o seguinte comando da Google Cloud CLI:
gcloud iam roles describe --organization ORGANIZATION_ID \
ROLE_ID
Em que:
ORGANIZATION_IDé o ID do recurso da organização da função mãe.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 no recurso da organização de destino.
Para 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 migrados entre recursos da organização. Essa diretriz se aplica até um dia após a criação ou atualização de um perímetro. Pode levar várias horas para que você possa migrar um projeto depois que ele for 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. Os projetos com objetos de Interconexão dedicada ou anexos da VLAN conectados a esses objetos vão continuar funcionando após a migração entre os recursos da organização. A única restrição é que não será possível criar novos anexos da VLAN entre a divisão de recursos da organização.
As mudanças de configuração feitas em um projeto em um recurso da organização que tenha um objeto de Interconexão dedicada anexado ou um anexo da VLAN para esse objeto podem não ser propagadas para o outro recurso da organização. Recomendamos não deixar esses projetos divididos entre os recursos da organização 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.
Contas de serviço de projetos cruzados
No contexto da migração da conta de serviço de projetos cruzados, os seguintes casos se aplicam:
- Se você migrar um projeto que tem uma conta de serviço entre projetos anexada a ele, essa conta de serviço vai continuar funcionando no recurso da 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ê migrar um projeto que é proprietário de uma conta de serviço entre projetos anexada a outro projeto no recurso da organização de origem, essa conta de serviço vai continuar funcionando no recurso da organização de destino. No entanto, você não poderá usar essa 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 do recurso 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 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, 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 visualizar esses casos até que o Suporte do Google atualize os metadados do caso para apontar para o novo recurso da organização.
Tela de permissão OAuth
Se o projeto estiver configurado para usar uma tela de consentimento do OAuth interno e você migrá-lo para outro recurso da organização, somente os membros do recurso 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 do recurso da organização de origem podem autorizar solicitações.
As etapas abaixo explicam como garantir que os membros do recurso da sua organização de origem não percam o acesso durante a migração. Considere criar novos usuários no recurso da organização de destino para os membros do recurso da organização, para que você não precise mudar a configuração da tela de consentimento do OAuth.
Para evitar a perda de acesso dos membros do recurso da organização de origem:
Atualize a tela de consentimento do OAuth para ser externa, em vez de interna.
Os apps marcados como internos e que usam dados sensíveis não precisam solicitar a verificação de apps. Se o app usar dados sensíveis, quando a tela de consentimento for atualizada para usuários externos, os usuários do recurso da organização de origem vão ver uma tela do app não verificada antes da 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, será necessário atribuir o papel roles/compute.osLoginExternalUser a todos os principais que tiverem acesso a esse projeto. Isso garante que esses participantes
não percam o acesso ao 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 a reserva é compartilhada (projeto consumidor) pode consumir a reserva criando instâncias de VM. Só é possível compartilhar uma reserva com projetos na mesma organização do projeto do proprietário.
Quando você migra um projeto de proprietário ou consumidor para uma organização diferente, acontece o seguinte:
- Se você migrar o projeto proprietário para uma organização diferente, 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 do consumidor para uma organização diferente, ele vai parar de consumir recursos de qualquer reserva compartilhada na organização anterior.
Saiba mais em Como funcionam as reservas compartilhadas.
Como anexar contas de serviço a recursos
Na 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 em Como exigir permissão para
anexar contas de serviço a
recursos.
Se o recurso da 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 o recurso da organização de destino não, conceda o papel de usuário da conta de serviço (roles/iam.serviceAccountUser) aos usuários que anexarem essas contas de serviço a recursos. Para informações sobre as permissões necessárias para anexar contas de serviço a recursos, consulte Papéis para autenticação da conta de serviço.
Para saber se o recurso da sua organização tem o comportamento legado, faça o seguinte:
No console do Google Cloud, acesse a página Políticas da organização.
No seletor de projetos na parte de cima da página, escolha o recurso da organização que você quer verificar o status legado.
Na caixa de filtro na parte superior da lista de políticas da organização, digite
constraints/appengine.enforceServiceAccountActAsCheck.Se a política da organização
appengine.enforceServiceAccountActAsCheckaparecer na lista, o recurso da organização terá o comportamento legado.Repita as etapas 3 e 4 para cada uma das seguintes restrições de política da organização:
appengine.enforceServiceAccountActAsCheckdataflow.enforceComputeDefaultServiceAccountCheckdataproc.enforceComputeDefaultServiceAccountCheckcomposer.enforceServiceAccountActAsCheck
Se alguma dessas restrições de política da organização aparecer, o recurso da organização vai usar o comportamento legado.
Se o recurso da organização de origem tiver o comportamento legado e o destino não tiver, conceda os papéis conforme mencionado acima. Se os recursos da organização 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.
Como migrar projetos com o Analytics Hub
Se você migrar o projeto que usa o Analytics Hub para um recurso de organização diferente, poderá encontrar algum erro. Para resolver erros, entre em contato com o suporte.
Se o recurso de troca de dados da organização antiga não estiver visível na página de administrador do Analytics Hub da nova organização, use a API Analytics Hub para atualizar a troca de dados na nova organização.
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.
- UPDATE_DX_VALUE é o valor atualizado do campo.
Como migrar projetos com o serviço de backup e DR
É necessário desativar o serviço de backup e DR antes de migrar projetos para um recurso de organização diferente. No momento em que o serviço está desativado, há um risco de interrupção que você precisa considerar. Reative o serviço de backup e DR depois que a migração para o novo recurso da organização for concluída.
A seguir
Para saber como realizar a migração, consulte Realizar a migração.