Como migrar projetos entre recursos da organização

Neste guia, você aprende a mover um projeto entre recursos da organização ou locais em uma hierarquia de recursos.

Observação :este tópico envolve a migração de projetos de um recurso da organização para outro. Se você quiser mover projetos em uma organização, consulte Mover um projeto. Se você quiser transferir domínios do Google Workspace entre recursos da organização, entre em contato com o representante do suporte.

O recurso do projeto é a entidade organizadora básica em um recurso da organização do Google Cloud. Os projetos são criados em recursos da organização 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 recursos da organização devido a aquisições, requisitos regulamentares e separação entre unidades de negócios, entre outras coisas.

É possível usar a API Resource Manager para mover projetos entre recursos da organização ou para outro local na hierarquia de recursos do recurso atual da organização. A API Resource Manager também permite reverter a migração, movendo o projeto de volta para o lugar original na hierarquia de recursos.

Observação: no geral, leva menos de um minuto para que a migração para o projeto seja concluída. Depois de mover um projeto, pode levar vários minutos para refletir essa mudança no console do Google Cloud. Para informações sobre como encontrar os detalhes atuais de um projeto, consulte Como criar e gerenciar projetos.

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.

Mover o projeto também pode resultar em violações da política da organização, dependendo das políticas da organização do recurso da organização de destino.

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 deveres.

Prévia dos recursos

É possível ativar recursos de visualização nos recursos da organização, da pasta ou do projeto. Se você ativou um recurso Alfa ou Beta para o projeto a ser movido, esse recurso continuará funcionando após a migração. Se o recurso de visualização for particular e não estiver na lista de permissões do recurso de organização de destino, você não vai 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, 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 na migração de um projeto, tanto nos recursos da organização de origem quanto de destino. Para reduzir esse risco, crie pastas específicas que contenham somente projetos para exportação e importação e garanta que as mesmas políticas sejam herdadas pelas pastas nos dois recursos da organização. Também é possível definir permissões nessas pastas que serão herdadas pelos projetos movidos dentro delas, o que ajuda a acelerar o processo de migração.

Ao planejar uma migração, primeiro configure uma pasta de origem dedicada. Para fazer isso, crie uma pasta para cada recurso da organização a 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 para o único recurso da organização a ser exportado.

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 de organização de onde você quer importar projetos. Para fazer isso, crie uma pasta para cada recurso de organização do 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 para 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.

Atribuir permissões

Observação :ao atribuir permissões relacionadas a uma migração de recursos de várias organizações, você precisa designar os papéis no mesmo endereço de e-mail principal nos recursos da organização de origem e de destino.

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

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

Para mover um projeto, você precisa dos seguintes papéis, no recurso pai e no recurso de destino:

• Administrador do IAM do projeto (roles/resourcemanager.projectIamAdmin) no projeto que você quer mover
• Transportador de projeto (roles/resourcemanager.projectMover) no recurso pai do projeto
• Se o recurso de destino for uma pasta: Transportador de projeto (roles/resourcemanager.projectMover) no recurso de destino
• Se o recurso de destino for uma organização: criador de projetos (roles/resourcemanager.projectCreator) no recurso de destino

Esses papéis concedem as seguintes permissões necessárias:

Permissões necessárias

• resourcemanager.projects.getIamPolicy no projeto que você quer mover
• resourcemanager.projects.update no projeto que você quer mover
• resourcemanager.projects.move no recurso pai do projeto
• Se o recurso de destino for uma pasta: resourcemanager.projects.move no recurso de destino
• Se o recurso de destino for uma organização: resourcemanager.projects.create no recurso de destino

Também é possível receber essas permissões com um papel personalizado ou outros papéis predefinidos.

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

Nos recursos da organização de origem e de destino, o usuário que define as políticas da organização precisa ter o papel roles/orgpolicy.policyAdmin, que concede permissão para criar e gerenciar políticas da organização.

Permissões da conta de faturamento

As contas do Cloud Billing podem ser usadas em todos os recursos da organização. Mover um projeto de um recurso da organização para outro não afeta o faturamento, e as cobranças continuarão na conta de faturamento antiga. No entanto, as transferências de recursos da organização também costumam incluir um requisito para fazer a migração para uma nova conta de faturamento.

Para receber as permissões necessárias para alterar a conta de faturamento do projeto, peça ao seu administrador para conceder a você os seguintes papéis de IAM:

• Usuário da conta de faturamento (roles/billing.user) na conta de faturamento de destino
• Gerente de faturamento do projeto (roles/billing.projectManager) no projeto

Para mais informações sobre como conceder papéis, consulte Gerenciar o acesso.

Esses papéis predefinidos têm as permissões necessárias para alterar a conta de faturamento do projeto. Para ver as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

• billing.resourceAssociations.create na conta de faturamento de destino
• resourcemanager.projects.createBillingAssignment no projeto
• resourcemanager.projects.deleteBillingAssignment no projeto

Essas permissões também podem ser concedidas com papéis personalizados ou outros papéis predefinidos.

Configurar políticas da organização

Para mover um recurso de projeto para um novo recurso de organização, aplique primeiro uma política da organização que defina os recursos da organização para onde o projeto pode ser movido. Também é necessário definir uma política da organização no destino que define os recursos da organização de onde os projetos podem ser importados.

Cuidado: se você não definir as políticas da organização a seguir, a migração resultará em um erro FAILED_PRECONDITION.

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, digamos que você tenha um projeto my-test-project que existia em um recurso da organização com o ID 12345678901 e que você queira movê-lo para um novo recurso da 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.

Observação :independentemente de você estar usando pastas de importação e exportação dedicadas, é recomendável remover essas políticas da organização depois de concluir a migração dos projetos entre os recursos da organização. Você poderá aplicá-las novamente se precisar executar outra migração de projeto.

Alterar a conta de faturamento de um projeto

As contas do Cloud Billing podem ser usadas em todos os recursos da organização. Mover um projeto de um recurso da organização para outro não afeta o faturamento, e as cobranças continuarão na conta de faturamento antiga. No entanto, as transferências de recursos da organização também costumam incluir um requisito para fazer a migração para uma nova conta de faturamento.

Para alterar a conta de faturamento, faça o seguinte:

1. Acesse a página Faturamento no Console do Google 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.

Observação: se você alterar a conta de faturamento anexada a um projeto que tem assinaturas ativas do Google Cloud Marketplace, essas assinaturas serão canceladas automaticamente. Para mais informações, consulte Como gerenciar o faturamento de produtos do Cloud Marketplace.

Mover uma conta de faturamento entre recursos da organização

Uma conta de faturamento pode ser movida de um recurso de organização para outro, embora essa geralmente não seja uma etapa necessária. A maioria dos recursos da organização já terá uma conta de faturamento para uso. Se você precisar migrar uma conta de faturamento atual, faça o seguinte:

1. Encontre o papel roles/billing.admin nos recursos da organização de origem e de destino, e o papel roles/billing.creator no recurso da organização de destino.
2. Acesse a página Faturamento no Console do Google 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 o recurso da organização de destino e clique em OK.

A conta de faturamento agora está associada ao recurso da organização especificado.

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.

Observação :as instruções a seguir são apenas para migrar um projeto de um recurso da organização para outro. Se o projeto que você quer migrar não estiver associado a um recurso da organização, consulte Como migrar projetos sem um recurso da organização.

gcloud

Para migrar um projeto para outro recurso da 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 do recurso da organização para onde você quer mover o projeto. Só é possível especificar um destino, que é um recurso da organização ou uma pasta.
• FOLDER_ID é o ID da pasta para onde você quer mover o projeto. Só é possível especificar um destino, que pode ser uma pasta ou um recurso da 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, siga estas etapas:

• Receba o objeto project usando o método projects.get().
• Defina o campo parent como o ID do recurso da organização ou da pasta para que ele será movido.
• 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. É preciso ter as permissões do IAM e políticas da organização necessárias aplicadas para permitir isso como se esta fosse uma migração totalmente nova.

Como lidar com casos especiais

Como migrar projetos sem um recurso da organização

É possível migrar um projeto que não esteja associado a um recurso da organização para um recurso da organização. No entanto, não é possível voltar para Nenhuma organização usando esse processo. Se você tiver um projeto associado ao recurso da organização e quiser revertê-lo para Sem organização, entre em contato com o representante do suporte.

Observação: reverter um projeto para Sem organização requer justificativa de negócios.

O processo de migração de um projeto não associado a um recurso da organização é semelhante ao de um projeto entre recursos da organização, mas não requer todas as etapas envolvidas no plano de migração. Para migrar um projeto para um recurso da 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 no recurso da 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

Para migrar um projeto para um recurso da organização:

1. Abra a página IAM e administrador > Configurações no Console do Google 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 nenhum recurso da organização, o seletor de organização não vai ser exibido, e poderá pular esta etapa.

4. Selecione o projeto que você quer migrar.

   

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

6. Na lista suspensa Organização, selecione o recurso da organização para onde você quer migrar o projeto.

gcloud

Para migrar um projeto para um recurso da 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 mover para o recurso da organização.
• ORGANIZATION_ID é o ID do recurso da organização para onde você quer mover o projeto.

API

Usando a API Resource Manager, é possível mover um projeto para o recurso da organização. Para isso, defina o campo parent como o ID do recurso da organização.

Para migrar um projeto para o recurso da organização:

• Receba o objeto project usando o método projects.get().
• Defina o campo parent como o ID do recurso 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

Observação: pode levar até dois minutos para que os projetos de serviço da VPC compartilhada sejam migrados após o projeto host correspondente ter sido movido devido ao atraso de propagação. Talvez você encontre um erro dentro desse período ao migrar esses projetos. Se isso acontecer, tente fazer a mudança novamente.

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

Os papéis personalizados do Identity and Access Management acesso podem ser criados no nível da organização para fornecer controle granular de acesso aos recursos, mas são válidos apenas no recurso da organização em que são criados. Se você tentar mover 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 da organização, a migração falhará com um erro de pré-condição que falhou, 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 organização, execute o seguinte comando da Google Cloud CLI:

gcloud iam roles list --organization ORGANIZATION_ID

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

Para ver informações sobre um papel personalizado do Identity and Access Management no recurso da 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 de recurso da organização do recurso da organização pai 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, será possível 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 movidos entre recursos da organização por até um dia após a criação ou atualização de um perímetro. Pode levar várias horas para o projeto se mover após a remoção 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. Os projetos com objetos de Interconexão dedicada ou anexos da VLAN conectados a eles podem ser migrados e funcionarão entre recursos da organização, mas não será possível criar novos anexos da VLAN na divisão de recursos da organização.

As alterações 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 ao objeto da Interconexão dedicada podem não ser propagadas para o outro. Portanto, recomendamos não deixar esses projetos divididos entre 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

Se você estiver movendo um projeto com uma conta de serviço entre projetos anexada a ela, essa conta de serviço ainda funcionará 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ê estiver movendo um projeto que tem uma conta de serviço entre projetos anexada a outro projeto no recurso de organização de origem, a conta de serviço ainda vai funcionar no recurso da organização de destino. No entanto, não será possível usar a conta de serviço em nenhum recurso que tenha 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 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. Os projetos com um caso de suporte aberto no Google não poderão ver esses casos de suporte 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 OAuth interno e você migrar para outro recurso da organização, somente 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 receber solicitações de autorização.

As etapas abaixo explicam como garantir que os membros do recurso da organização de origem não percam o acesso durante a migração. Crie novos usuários no recurso de organização de destino para os membros do recurso de organização. Assim, não será necessário alterar a configuração da tela de permissão OAuth.

Para evitar a perda de acesso dos membros do recurso 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 externo, os usuários do recurso da organização de origem verão uma tela de 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, atribua o papel roles/compute.osLoginExternalUser do IAM aos principais que podem acessar o projeto de origem no recurso da organização de destino para evitar que esses participantes percam o 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 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 normal de papéis) e o recurso da organização de destino não, conceder roles/iam.serviceAccountUser aos usuários que anexam essas contas de serviço aos recursos. Para informações sobre como representar contas de serviço, consulte Falsificação da identidade da conta de serviço.

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

1. No console do Google 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 de cima da página, escolha o recurso da 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 for exibida na lista, o recurso da 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 da política da organização aparecer, o recurso da organização usará o comportamento legado.

Se o recurso de 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, aplique a política para impedir a representação não intencional.

Como migrar projetos com o Analytics Hub

Se você migrar o projeto que está usando o Analytics Hub para um recurso de organização diferente, talvez encontre algum erro. Para resolver erros, entre em contato com o suporte.

Como migrar projetos com o serviço de backup e DR

Projetos que usam serviços de backup e DR não podem ser migrados para uma organização diferente.