Para uma migração de projeto, é necessário avaliar 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 mudança na hierarquia de recursos provavelmente terá um impacto na função do projeto e nos serviços em execução. As políticas de permissão, negação ou da organização que são herdadas em vez de anexadas diretamente ao projeto não serão migradas com ele. As políticas da organização e as contas de serviço anexadas diretamente ao recurso serão migradas. Isso pode causar um comportamento não intencional depois que a migração é concluída.
A migração do projeto também pode resultar em violações da política da organização, dependendo das políticas da organização do recurso de organização de destino.
Antes de migrar seu projeto entre recursos da organização, considere criar um plano de migração para determinar a prontidão do recurso da organização e dos projetos que você quer migrar. Neste plano de migração, faça um inventário de cada um dos serviços que seu projeto está executando e de outros serviços que possam ser afetados pela migração ou pela hierarquia de recursos no destino do projeto.
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 permissão. 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.
Para conferir uma lista de todas as políticas de permissão e negação que afetam o acesso a um projeto, consulte Ver todas as políticas de permissão e negação que se aplicam a um recurso.
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 permissão, negação e 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 ela 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 deveres.
Prévia dos recursos
É possível ativar os recursos de prévia em recursos da organização, pastas ou projetos. Se você ativou um recurso Alfa ou Beta no projeto, ele vai continuar funcionando após a migração. Se o recurso de prévia for particular e não estiver na lista de permissões do recurso da organização de destino, você não poderá fazer mudanças de configuração após a conclusão da migração.
Plano de reversão
Se você descobrir que algo não está funcionando em nenhum dos projetos migrados, restaure-os 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 nos recursos da organização 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 ambos os recursos da organização. 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 recurso da organização de destino em 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 o único recurso da organização para o 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 no recurso da organização de destino, uma para cada recurso da organização de onde você quer importar projetos. Para fazer isso, crie uma pasta para cada recurso da organização de origem de que
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 o único recurso da 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.
A seguir
Para atribuir papéis e permissões do Identity and Access Management para migrar projetos entre organizações, consulte Atribuir papéis e permissões do gerenciamento de identidade e acesso.