Como migrar projetos

Neste guia, explicamos como mover um projeto entre organizações ou lugares dentro de uma hierarquia de recursos.

O recurso de projeto é a entidade organizacional de nível básico em uma organização do Google Cloud. Os projetos são criados em organizações e podem ser colocados em pastas ou no próprio recurso da organização, formando a hierarquia de recursos. Talvez seja preciso migrar projetos entre organizações devido a aquisições, requisitos regulatórios e separação entre unidades de negócios, entre outras coisas.

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

Criar um plano de migração

O mais importante a considerar durante a migração do projeto é como a migração afetará os serviços executados dentro do projeto. A API Resource Manager trata o recurso do projeto e todos os serviços executados sob ele como uma única unidade, o que significa que nenhuma alteração na configuração será aplicada dentro do projeto.

Embora a migração não faça alterações diretas na configuração do projeto, a alteração na hierarquia de recursos provavelmente terá um impacto na função do projeto e nos serviços em execução. Políticas herdadas, como gerenciamento de identidade e acesso ou políticas da organização, não serão transferidas com o projeto durante a migração. Somente políticas e contas de serviço anexadas diretamente ao recurso. Isso pode causar um comportamento não intencional após a conclusão da migração.

Antes de mover seu projeto, considere criar um plano de migração para determinar a prontidão da organização e dos projetos que você quer mover. Neste plano de migração, pegue o inventário de cada um dos serviços que o projeto está executando e qualquer outro serviço que possa ser afetado pela transferência ou pela hierarquia de recursos no destino do projeto. para começar.

Visão geral do inventário

usar o Cloud Asset Inventory para criar uma visão geral dos recursos em uso, incluindo as políticas de gerenciamento de identidade e acesso. Use essa visão geral para ajudar a descrever seu plano de migração.

Você também pode usar o Cloud Asset Inventory 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 a exportação desses dados, consulte Como exportar para o BigQuery.

Verificação de políticas

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. Recomendamos que você verifique se as políticas efetivas no destino do projeto correspondem o máximo possível das políticas em seu local de origem.

Qualquer política aplicada diretamente ao projeto ainda será anexada após a conclusão da migração. Aplicar políticas diretamente ao projeto é uma boa maneira de verificar se as políticas corretas são aplicadas a partir do momento em que a transferência é concluída.

As políticas de gerenciamento de identidade e acesso são herdadas pela hierarquia de recursos e podem bloquear a funcionamento de um serviço se não forem definidas corretamente. Determine a política vigente no destino do projeto na hierarquia de recursos para garantir que ela esteja alinhada aos 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 pertencem ao projeto, e um usuário com acesso owner a esse projeto poderá gerenciar e executar operações criptográficas em chaves no Cloud KMS nesse projeto.

Para mais informações, consulte Separação de tarefas.

Recursos de visualização

Você pode ativar os recursos de visualização em organizações, pastas ou projetos. Se você ativou um recurso Alfa ou Beta no projeto a ser movido, ele continuará funcionando após a migração. Se o recurso de visualização for particular e não estiver permitido para a organização de destino, não será possível fazer alterações na configuração após a conclusão da transferência.

Reverter plano

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, você precisa 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 inversamente.

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 dedicadas de importação e exportação

A herança de política pode causar efeitos não intencionais durante a migração de um projeto, tanto nas organizações de origem quanto de destino. É possível reduzir esse risco criando pastas específicas para conter apenas projetos para exportação e importação e garantir que as mesmas políticas sejam herdadas pelas pastas em ambas as organizações. Também é possível definir permissões nessas pastas que serão herdadas nos projetos movidos dentro delas, o que ajuda a acelerar o processo de migração do projeto.

Ao planejar uma migração, considere configurar uma pasta de origem dedicada primeiro. Para fazer isso, crie uma pasta para cada organização para a qual 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 a única organização para a 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 apropriadas definidas.

Da mesma forma, configure pastas de importação dedicadas na organização de destino, uma para cada organização de onde você quer importar projetos. Para fazer isso, crie uma pasta para cada organização da 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 a única organização da qual 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 apropriadas definidas.

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 quaisquer 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 obter mais informações sobre como definir políticas da organização, consulte Configurar políticas da organização.

Atribuir permissões

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

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 transferência do projeto

No recurso do projeto que você quer transferir e no recurso pai, é necessário ter o papel de Movimentador de projetos (roles/resourcemanager.projectMover) ou outro papel que inclua as seguintes permissões para a API Resource Manager v1:

  • Permissão necessária para o recurso que você está movendo:

    • resourcemanager.projects.update
  • Permissão necessária para o recurso pai:

    • resourcemanager.projects.move

No recurso de destino, a permissão necessária depende do recurso para onde você está movendo o projeto.

  • Se o recurso de destino for uma pasta, você precisará do papel de Movimentador de projetos (roles/resourcemanager.projectMover) ou de outro papel que inclua a permissão resourcemanager.projects.move.

  • Se o recurso de destino for uma organização, você precisará do papel de Criador do projeto (roles/resourcemanager.projectCreator) ou de outro papel que inclua as permissões resourcemanager.projects.create.

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

Nas organizações de origem e de destino, você precisa ter o papel roles/orgpolicy.policyAdmin, que concede permissão para criar e gerenciar as políticas da organização.

Configure políticas da organização

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

No recurso pai para o projeto que você quer mover, defina uma política da organização que inclua a restrição constraints/resourcemanager.allowedExportDestinations. Isso definirá o destino de destino como um local válido para o qual o projeto será migrado.

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 de onde você pode migrar seu projeto.

Por exemplo, digamos que você tenha um projeto my-test-project que existia em uma organização com o ID 12345678901 e você queira movê-lo para uma nova 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, você poderá movermy-test-project daorganizations/12345678901 para organizations/45678901234, supondo que você tenha as permissões mencionadas em Atribuir permissões para começar.

Alterar a conta de faturamento de um projeto

As Contas de faturamento do Cloud podem ser usadas em todas as organizações. Mover um projeto de uma organização para outra não afeta o faturamento, e as cobranças continuarão na conta de faturamento antiga. No entanto, as movimentações da organização também incluem um requisito para migrar para uma nova conta de faturamento.

Para alterar a conta de faturamento de um projeto existente, é necessário ter o papel roles/owner no projeto e o papel roles/billing.admin na conta de faturamento de destino. Para alterar a conta de faturamento, faça o seguinte:

  1. Acesse a Página de faturamento no Console do 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.

Mover uma conta de faturamento entre organizações

É possível mover uma conta de faturamento de uma organização para outra, embora essa geralmente não seja uma etapa necessária. A maioria das organizações atuais já terá uma conta de faturamento. Se você precisar migrar uma conta de faturamento atual, faça o seguinte:

  1. Consiga o papel roles/billing.admin nas organizações de origem e de destino.
  2. Acesse a Página de faturamento no Console do 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 da conta, clique em Alterar organização.
  5. Selecione a organização de destino e clique em Ok.

A conta de faturamento agora está associada à organização especificada.

Faça a migração

Se você tem as permissões do IAM apropriadas e as políticas da organização necessárias, use a API Resource Manager para mover um recurso de projeto. para começar.

gcloud

Para migrar um projeto em uma organização, execute o seguinte comando:

gcloud beta projects move PROJECT_ID /
    --organization ORGANIZATION_ID

Você também pode especificar uma pasta como recurso de destino com o comando a seguir:

gcloud beta projects move PROJECT_ID /
    --folder FOLDER_ID

Em que:

  • PROJECT_ID é o ID ou número do projeto que você quer migrar.
  • ORGANIZATION_ID é o ID da organização para onde você quer migrar o projeto. Só é possível especificar um destino, seja uma organização ou uma pasta.
  • FOLDER_ID é o ID da pasta para onde você quer mover o projeto. Só é possível especificar um destino, seja uma pasta ou uma organização.

API

Usando a API Resource Manager v1, é possível mover um projeto definindo seu campo parent como o ID do recurso de destino.

Para migrar um projeto=:

  • Receba o objeto project usando o método projects.get().
  • Defina o campo parent como o código da organização ou o código da pasta para onde você está movendo-o.
  • 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 acidentalmente um projeto, poderá reverter a operação executando a movimentação novamente, com a origem antiga como o novo destino, e o destino antigo como a nova origem. É preciso ter as permissões do IAM e as políticas da organização aplicadas para permitir isso como se fosse uma migração totalmente nova.

Como gerenciar casos especiais

Como migrar projetos sem organização

É possível migrar um projeto que não está associado a uma organização. No entanto, não é possível alterá-lo para Nenhuma organização usando esse processo. Se você tiver um projeto associado à sua organização e quiser reverter para Sem organização, entre em contato com o representante de suporte para receber ajuda.

O processo de migração de um projeto não associado a uma organização é semelhante ao de migrar de um projeto entre organizações, mas não exige todas as etapas envolvidas no plano de migração. Para migrar um projeto para uma organização, siga estas etapas:

  1. Verifique o impacto nesse projeto das políticas que ele herdará.

  2. Crie uma pasta dedicada de importação na organização de destino, se quiser.

  3. Atribua permissões de Gerenciamento de identidade e acesso para o projeto e o 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

Se você quiser migrar um projeto para uma organização, faça o seguinte:

  1. Abra a página IAM e administrador > Configurações no Console do 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 nenhuma organização, o seletor de organização não será exibido, e você poderá ignorar esta etapa.

  4. Selecione o projeto que você quer migrar.

    Captura de tela do seletor de projetos

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

  6. Na lista suspensa Organização, selecione a organização que receberá o projeto.

gcloud

Se você quiser migrar um projeto para uma organização, execute o seguinte comando:

gcloud beta projects move PROJECT_ID /
    --organization ORGANIZATION_ID

Onde:

  • PROJECT_ID é o código do projeto que você quer mover para a organização
  • ORGANIZATION_ID é o código da organização para onde você quer migrar o projeto.

API

Usando a Resource Manager API, você pode mover um projeto para o recurso da organização definindo seu campo parent como o ID da organização.

Se você quiser migrar um projeto para a organização, faça o seguinte:

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

É possível migrar projetos de VPC compartilhada 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 deve listar SHARED_VPC como um allowed_value.

O projeto de host da VPC compartilhada precisa ser migrado primeiro, seguido por 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 minimiza os possíveis problemas e evita qualquer inatividade nos projetos e na rede durante a migração. Não oferecemos garantias sobre a integridade da rede se você deixar alguns projetos de serviço na organização de origem indefinidamente ao migrar outros.

Se você transferir o projeto host, poderá movê-lo de volta para a organização de origem, mas, depois de começar a mover os projetos de serviço, mova todos eles antes de migrar o projeto host novamente.

Papéis personalizados do Identity and Access Management

É possível criar papéis personalizados de gerenciamento de identidade e acesso no nível da organização para fornecer controle granular de acesso a recursos, mas eles só são válidos na organização em que são criados. Se você tentar mover um projeto que contém uma vinculação de política de IAM de um usuário para um papel de IAM personalizado no nível da organização, a transferência falhará com um erro de condição prévia com falha, explicando que o papel em questão não existe na organização de destino.

Para listar todos os papéis personalizados do IAM no nível da organização, execute o seguinte comando da ferramenta de linha de comando gcloud:

gcloud iam roles list --organization ORGANIZATION_ID

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

Para obter informações sobre um papel personalizado de gerenciamento de identidade e acesso na sua organização, execute o seguinte comando da ferramenta de linha de comando gcloud:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Em que:

  • ORGANIZATION_ID é o ID da organização pai do papel.

  • ROLE_ID é o nome do papel que você quer descrever.

Para contornar o erro de condição prévia com falha, crie papéis personalizados no nível do projeto para cada um dos papéis personalizados no nível da organização que o projeto herda. 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 que o projeto for migrado, será possível atualizar as políticas de IAM para usar os papéis personalizados no nível da organização na organização de destino.

Para mais 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 rege o tempo que 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 são mantidas com o projeto durante a migração, mas esteja ciente se você estiver movendo um projeto com um bloqueio de bucket aplicado e impedir movimentos acidentais.

Perímetros de segurança do VPC Service Controls

Os VPC Service Controls permitem que os usuários configurem um perímetro de segurança baseado em projeto 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 nos perímetros do VPC Service Controls podem não ser impedidos de serem movidos entre organizações por até um dia após a criação ou atualização de um perímetro. Pode levar várias horas para que o projeto seja removível após ele ter sido removido do perímetro de serviço.

Interconexão dedicada

Recomendamos migrar projetos com objetos e projetos de Interconexão dedicada com anexos da VLAN para esses objetos da Interconexão dedicada. Embora projetos com objetos de Interconexão dedicada ou anexos da VLAN conectados a eles possam ser migrados e funcionem entre organizações, não será possível criar novos anexos da VLAN em toda a organização.

As alterações de configuração feitas em um projeto em uma organização que têm um objeto de Interconexão dedicada anexada ou um anexo da VLAN para o objeto de Interconexão dedicada podem não se propagar para a outra. Por isso, recomendamos não separar esses projetos em organizações 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.

Assured Workloads

Não é possível mover um projeto Assured Workloads entre organizações. Qualquer tentativa de fazer isso será bloqueada programaticamente.

Contas de serviço entre projetos

Se você estiver migrando um projeto que tenha uma conta de serviço entre projetos anexada a ela, essa conta de serviço ainda funcionará na organização de destino. Esse projeto continuará a funcionar com a conta de serviço anexada, mesmo que exista uma política da organização que restringe o domínio desse projeto.

Se você estiver movendo um projeto que tem uma conta de serviço entre projetos anexados a outro projeto na organização de origem, a conta de serviço ainda funcionará na 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 de restrição de domínio aplicada a eles e que as restrinja ao domínio da organização de origem.

Por exemplo, suponha que você tenha project-A em organizations/12345678901. Esse projeto tem serviceAccount-1 anexado a ele, que é 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 a project-C, que permite que ela acesse apenas o domínio de organizations/12345678901.

Se você adicionar serviceAccount-1 à vinculação do IAM de project-C e, em seguida, 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 violar a restrição de domínio.

Histórico de consultas

Se você migrar um projeto que tem um caso de suporte aberto, precisará entrar em contato com o contato do Suporte do Google para informar que a migração ocorreu. Qualquer projeto que tenha um caso de suporte aberto com o Google não poderá ver esses casos de suporte até que o Suporte do Google atualize os metadados do caso para apontar para a nova organização.

Caso seu projeto esteja configurado para usar uma tela de consentimento OAuth interno e você a migrar para outra organização, somente os membros da organização de destino poderão autorizar as solicitações. Pode levar até 24 horas para que esse comportamento entre em vigor. Até lá, os membros da organização de origem podem autorizar solicitações.

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

Para evitar a perda de acesso aos membros na organização de origem:

  1. Atualizar a tela de consentimento do OAuth para que ela seja externa, e não interna.

  2. Apps marcados como internos e que usam dados confidenciais não precisam ser solicitados para a verificação de apps. Se o aplicativo usar dados confidenciais, quando a tela de consentimento for atualizada para externo, os usuários da organização de origem verão uma tela não verificada do app antes do 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 do IAM roles/compute.osLoginExternalUser aos membros do projeto de origem na organização de destino para evitar esses membros. perder 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, no passado, para facilitar a integração de determinados serviços, os usuários podiam anexar contas de serviço a recursos, mesmo se os usuários não tiverem permissão para personificar as contas de serviço. Veja o documento disponível aqui.

Se a 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 a organização de destino não tiver, conceda roles/iam.serviceAccountUser aos usuários que anexam essas contas de serviço. recursos. Para informações sobre como personificar contas de serviço, consulte Como representar contas de serviço.

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

  1. No Console do 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 superior da página, escolha a organização que você quer verificar para ver o status legado.

  3. Na caixa de filtro na parte superior da lista de políticas da organização, insira constraints/appengine.enforceServiceAccountActAsCheck.

  4. Se a política da organização appengine.enforceServiceAccountActAsCheck aparecer na lista, ela terá o comportamento legado.

  5. Repita as etapas 3 e 4 para cada uma das seguintes restrições da política da organização:

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck
  6. Se alguma dessas restrições de política da organização for exibida, sua organização usa o comportamento legado.

Se a organização de origem tiver o comportamento legado e o destino não, conceda os papéis conforme mencionado acima. Se as organizações de origem e de destino tiverem o comportamento legado, nenhuma ação será necessária, mas considere aplicar a política para evitar falsificação de identidade não intencional.