Este documento fornece informações sobre o processamento de casos especiais durante a migração de projetos. Quando migrar um projeto, certifique-se de que tem as autorizações de IAM necessárias concedidas no projeto, no respetivo recurso principal e no recurso de destino.
Migrar projetos que não estão associados a um recurso de organização
Pode migrar um projeto que não esteja associado a um recurso de organização para um recurso de organização. No entanto, não pode voltar a alterá-la para Nenhuma organização através deste processo. Se tiver um projeto associado ao recurso da sua organização e quiser revertê-lo para Nenhuma organização, contacte o representante do apoio técnico para receber assistência.
Tem de ter a função roles/resourcemanager.projectCreator atribuída no recurso da organização de destino.
Se não tiver a autorização resourcemanager.organizations.get no recurso da organização principal do projeto, é provável que os seus projetos não sejam apresentados como esperado na organização real naGoogle Cloud consola. Isto pode fazer parecer que o projeto não está associado a nenhum recurso da organização. Para mais informações, consulte o artigo
Restringir a visibilidade do projeto para utilizadores.
Para determinar se o projeto está associado a um recurso de organização, faça o seguinte:
gcloud
Execute o seguinte comando:
gcloud projects describe PROJECT_ID
Substitua PROJECT_ID pelo ID do projeto que quer migrar.
Se o recurso principal não for apresentado na saída, confirma que o projeto não está associado a um recurso de organização.
Se o recurso principal (recurso de pasta ou organização) for apresentado no resultado, 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 processo de migração de um projeto entre recursos de organização, mas não requer todos os passos envolvidos no plano de migração. Para migrar um projeto para um recurso de organização, deve seguir estes passos:
Verifique o impacto neste projeto das políticas que vai herdar.
Crie uma pasta de importação dedicada no recurso da organização de destino, se quiser.
Atribua autorizações de gestão de identidade e de acesso para o projeto e o recurso principal de destino, conforme detalhado em Atribuir autorizações.
Determine se precisa de alterar a conta de faturação.
Em seguida, pode realizar a migração.
Consola
Para migrar um projeto para um recurso de organização:
Abra a página IAM e administrador > Definições na Google Cloud consola.
Selecione o Selecionador de projetos na parte superior da página.
No seletor de organizações, selecione Nenhuma organização. Se não estiver associado a nenhum recurso de organização, o seletor de organizações não é apresentado e pode ignorar este passo.
Selecione o projeto que quer migrar.
Na parte superior da página, clique em Migrar.
Na lista pendente Organização, selecione o recurso da organização para o qual quer migrar o 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
Onde:
- PROJECT_ID é o ID do projeto que quer migrar para o recurso de organização.
- ORGANIZATION_ID é o ID do recurso da organização para o qual quer migrar o projeto.
API
Com a API Resource Manager, pode migrar um projeto para o recurso da organização definindo o respetivo campo parent para o ID do recurso da organização do recurso da organização.
Para migrar um projeto para o recurso da organização:
- Obtenha o objeto
projectatravés do métodoprojects.get(). - Defina o campo
parentpara o ID de recurso da organização do recurso organization. - Atualize o objeto
projectatravés do métodoprojects.update().
Não pode alterar o campo parent depois de o definir.
O seguinte fragmento do código demonstra os passos acima:
project = crm.projects().get(projectId=flags.projectId).execute()
project['parent'] = {
'type': 'organization',
'id': flags.organizationId
}
Se o Início de sessão do SO estiver ativado no projeto de origem, tem de atribuir a função roles/compute.osLoginExternalUser a todos os responsáveis que tenham acesso a esse projeto.
VPC partilhada
Os projetos de VPC partilhada podem ser migrados mediante
determinadas condições. Primeiro, um utilizador com a função roles/orgpolicy.policyAdmin no recurso da organização de origem tem de definir uma política da organização que contenha a restrição constraints/resourcemanager.allowEnabledServicesForExport no elemento principal do projeto a ser exportado. Esta restrição deve indicar
SHARED_VPC como um allowed_value.
Não tem de desativar a VPC partilhada antes da migração. No entanto, o projeto anfitrião da VPC partilhada tem de ser migrado primeiro, seguido de todos os respetivos projetos de serviço. Recomendamos que faça corresponder as regras da firewall entre os recursos da organização nas localizações de origem e de destino, o que deve minimizar potenciais problemas e evitar qualquer tempo de inatividade para os projetos e a rede durante a migração. Não oferecemos garantias sobre a integridade da sua rede se deixar alguns projetos de serviço no recurso da organização de origem indefinidamente enquanto migra outros.
Se migrar o projeto anfitrião, pode movê-lo novamente para o recurso da organização de origem. Não existe um prazo exato para a duração da permanência do projeto anfitrião e dos projetos de serviço em organizações diferentes. No entanto, quando começar a migrar os projetos de serviço, tem de migrá-los todos antes de poder migrar novamente o projeto anfitrião.
Funções de gestão de identidade e de acesso personalizadas
As funções personalizadas de gestão de identidades e acessos podem ser criadas ao nível do recurso da organização para oferecer um controlo detalhado do acesso aos recursos, mas só são válidas no recurso da organização em que são criadas. Se tentar migrar um projeto que contenha uma associação de política de permissão de um utilizador para uma função de IAM personalizada ao nível da organização, a migração falha com um erro de pré-condição falhada, explicando que a função em questão não existe no recurso da organização de destino.
Para apresentar uma lista de todas as funções de IAM personalizadas ao nível do recurso da sua organização, execute o seguinte comando da CLI do Google Cloud:
gcloud iam roles list --organization ORGANIZATION_ID
Onde ORGANIZATION_ID é o ID do recurso da organização para o qual quer listar funções. Para obter informações sobre como encontrar o ID do recurso da sua organização, consulte o artigo Criar e gerir recursos da organização.
Para obter informações sobre uma função personalizada da 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
Onde:
ORGANIZATION_IDé o ID do recurso da organização do recurso da organização principal da função.ROLE_IDé o nome da função que quer descrever.
Para contornar o erro de pré-condição falhada, deve criar funções personalizadas ao nível do projeto equivalentes para cada uma das funções personalizadas ao nível da organização que o projeto herda. Em seguida, remova as associações de funções de IAM que fazem referência às funções personalizadas ao nível da organização.
Depois de o projeto ter sido migrado, pode atualizar as políticas de permissão para usar as funções personalizadas ao nível da organização no recurso da organização de destino.
Para mais informações sobre funções personalizadas, consulte o artigo Criar e gerir funções personalizadas.
Bloqueio de contentores
O bloqueio de contentores do Cloud Storage permite-lhe configurar uma política de retenção de dados num contentor do Cloud Storage que determina durante quanto tempo os objetos no contentor têm de ser retidos. O bloqueio do contentor está protegido através de um vínculo para evitar a eliminação acidental do projeto.
A política de retenção e o bloqueio de conta são mantidos com o projeto durante uma migração, mas deve ter em atenção se estiver a migrar um projeto com um bloqueio de contentor aplicado e evitar movimentos acidentais.
Perímetros de segurança dos VPC Service Controls
Os VPC Service Controls permitem que os utilizadores configurem um perímetro de segurança baseado em projetos em torno dos respetivos Google Cloud serviços para mitigar os riscos de exfiltração de dados. Não pode migrar um projeto protegido por um perímetro de segurança dos VPC Service Controls.
Para remover um projeto de um perímetro de segurança, consulte o artigo Gerir perímetros de serviço. Os projetos nos perímetros dos VPC Service Controls podem não estar bloqueados para migração entre recursos da organização. Esta diretriz aplica-se até um dia após a criação ou a atualização de um perímetro. Pode demorar várias horas até poder migrar um projeto depois de este ter sido removido do perímetro de serviço.
Interligação dedicada
Recomendamos que migre os projetos com objetos do Dedicated Interconnect e os projetos com anexos de VLAN em conjunto. Os projetos com objetos do Dedicated Interconnect ou anexos de VLAN ligados a estes objetos vão continuar a funcionar após a migração entre recursos da organização. A única restrição é que não pode criar novas associações de VLAN entre a divisão do recurso da organização.
As alterações de configuração feitas a um projeto num recurso de organização que tenha um objeto Dedicated Interconnect anexado ou um anexo de VLAN a este objeto podem não ser propagadas para o outro recurso de organização. Recomendamos que não deixe esses projetos divididos entre recursos da organização durante muito tempo, se possível.
Interligação de parceiro
Não são necessárias considerações especiais ao migrar projetos com o Partner Interconnect.
Contas de serviço entre projetos
No contexto da migração da conta de serviço entre projetos, aplicam-se os seguintes casos:
- Se migrar um projeto que tenha uma conta de serviço entre projetos anexada, essa conta de serviço continua a funcionar no recurso da organização de destino. Esse projeto continua a funcionar com a conta de serviço associada, mesmo que exista uma política da organização que restrinja o domínio desse projeto.
- Se migrar um projeto que seja 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 continua a funcionar no recurso da organização de destino. No entanto, não pode usar essa conta de serviço em recursos aos quais tenha sido aplicada uma política da organização de restrição de domínio que os restrinja ao domínio do recurso da organização de origem.
Por exemplo, suponha que tem project-A, em organizations/12345678901. Este projeto tem serviceAccount-1 anexado, que está configurado como uma conta de serviço entre projetos. project-B e project-C, também em
organizations/12345678901, use também serviceAccount-1.
Aplicou uma política da organização com a restrição de domínios a project-C, o que só lhe permite aceder ao domínio de organizations/12345678901.
Se adicionar serviceAccount-1 à associação do IAM para project-C e, em seguida, migrar project-A para organizations/45678901234, a conta de serviço funciona.
Se migrar project-A para organizations/45678901234 e, em seguida, tentar adicionar serviceAccount-1 à associação do IAM para project-C, a associação falha porque viola a restrição de domínio.
Registos de apoio técnico
Se migrar um projeto que tenha um registo de apoio técnico aberto, tem de contactar o seu contacto do Apoio técnico da Google para o informar de que a migração ocorreu. Os projetos que tenham um registo de apoio ao cliente aberto com a Google não vão poder ver esses registos de apoio ao cliente até que o Apoio técnico da Google atualize os metadados do registo para apontar para o novo recurso da organização.
Ecrã de consentimento OAuth
Se o seu projeto estiver configurado para usar um ecrã de consentimento de OAuth interno e o migrar para outro recurso da organização, apenas os membros do recurso da organização de destino podem autorizar pedidos. Este comportamento pode demorar até 24 horas a entrar em vigor. Até lá, os membros do recurso da organização de origem podem autorizar pedidos.
Os passos abaixo explicam como garantir que os membros da organização de origem do recurso não perdem o acesso durante a migração. Considere criar novos utilizadores no recurso da organização de destino para os membros do recurso da organização, para não ter de alterar a configuração do ecrã de consentimento OAuth.
Para evitar a perda de acesso dos membros do recurso da organização de origem:
Atualize o ecrã de consentimento OAuth para ser externo em vez de interno.
As apps marcadas como internas e que usam dados confidenciais não precisam de se candidatar à validação de apps. Se a app usar dados confidenciais, quando o ecrã de consentimento for atualizado para externo, os utilizadores do recurso da organização de origem vão ver um ecrã de app não validada antes do ecrã de autorização. Para evitar esta situação, candidate-se à validação de apps para a utilização de âmbitos restritos ou confidenciais.
Início de sessão do SO
Se o Início de sessão do SO estiver ativado no projeto de origem, tem de atribuir a função roles/compute.osLoginExternalUser a todos os responsáveis que tenham acesso a esse projeto. Isto garante que estes principais não perdem o acesso no recurso da organização de destino.
Reservas partilhadas de instâncias de máquinas virtuais (VMs)
Numa reserva partilhada, o projeto que criou a reserva (owner project) ou quaisquer projetos com os quais a reserva é partilhada (consumer project) podem consumir a reserva através da criação de instâncias de VMs. Só pode partilhar uma reserva com projetos na mesma organização do projeto proprietário.
Quando migra um projeto de proprietário ou consumidor para uma organização diferente, ocorre o seguinte:
- Se migrar o projeto proprietário para uma organização diferente, o Compute Engine elimina todas as reservas criadas pelo projeto proprietário. As instâncias de VM em execução não são afetadas.
- Se migrar um projeto de consumidor para uma organização diferente, o projeto de consumidor deixa de consumir recursos de qualquer reserva partilhada na organização anterior.
Para mais informações, consulte o artigo Como funcionam as reservas partilhadas.
Anexar contas de serviço a recursos
Para a maioria dos Google Cloud serviços, os utilizadores precisam da autorização iam.serviceAccounts.actAs
numa conta de serviço para anexar essa conta de serviço a um recurso.
No entanto, no passado, para facilitar a integração, determinados serviços permitiam que os utilizadores anexassem contas de serviço a recursos, mesmo que não tivessem autorização para se fazerem passar pelas contas de serviço. Isto está documentado no artigo Autorização necessária para anexar contas de serviço a recursos.
Se o recurso da organização de origem de um cliente tiver o comportamento antigo (é possível anexar contas de serviço sem a concessão normal de funções) e o recurso da organização de destino não tiver, conceda a função Utilizador da conta de serviço (roles/iam.serviceAccountUser) aos utilizadores que anexarem estas contas de serviço a recursos. Para obter informações sobre as autorizações necessárias para anexar contas de serviço a recursos, consulte o artigo Funções para autenticação de contas de serviço.
Para ver se o recurso da sua organização tem o comportamento antigo, faça o seguinte:
Na Google Cloud consola, aceda à página Políticas de organização.
No seletor de projetos na parte superior da página, escolha o recurso de organização que quer verificar quanto ao estado de legado.
Na caixa de filtro na parte superior da lista de políticas de organização, introduza
constraints/appengine.enforceServiceAccountActAsCheck.Se a política da organização
appengine.enforceServiceAccountActAsCheckaparecer na lista, o recurso da organização tem o comportamento antigo.Repita os passos 3 e 4 para cada uma das seguintes restrições da política de organização:
appengine.enforceServiceAccountActAsCheckdataflow.enforceComputeDefaultServiceAccountCheckdataproc.enforceComputeDefaultServiceAccountCheckcomposer.enforceServiceAccountActAsCheck
Se aparecer alguma destas restrições de políticas organizacionais, o recurso da sua organização usa o comportamento antigo.
Se o recurso da organização de origem tiver o comportamento antigo e o destino não, conceda as funções conforme mencionado acima. Se os recursos da organização de origem e de destino tiverem o comportamento antigo, não é necessária nenhuma ação, mas considere aplicar a política para evitar roubo de identidade não intencional.
Migrar projetos com partilha do BigQuery
Se migrar o projeto que está a usar a partilha do BigQuery (anteriormente Analytics Hub) para um recurso de organização diferente, pode encontrar alguns erros. Para resolver erros, contacte o apoio técnico.
Se o recurso de troca de dados da organização antiga não estiver visível na página de administrador de partilha da nova organização, use a API Analytics Hub para atualizar a troca de dados na nova organização.
Use o
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 }
Substitua o seguinte:
- PROJECT_ID é o identificador exclusivo do projeto.
- LOCATION é a localização da troca de dados.
- DATA_EXCHANGE_ID é o ID da troca de dados.
- UPDATE_DX_FIELD é o campo a atualizar.
- UPDATE_DX_VALUE é o valor atualizado do campo.
Migrar projetos com o serviço de cópia de segurança e RD
Tem de desativar o serviço de cópia de segurança e recuperação de desastres antes de migrar projetos para um recurso de organização diferente. Neste momento, quando o serviço está desativado, existe um risco de indisponibilidade que tem de ter em conta. Deve voltar a ativar o serviço de cópia de segurança e recuperação após desastres depois de a migração para o novo recurso da organização estar concluída.
O que se segue?
Para saber como fazer a migração, consulte o artigo Faça a migração.