Processar casos especiais

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 de IAM necessárias concedidas ao projeto e aos recursos pai e de destino relacionados.

Como migrar projetos que não estão associados a um recurso da organização

É possível migrar um projeto que não esteja associado a um recurso da organização em um recurso da organização. No entanto, não é possível alterá-la de volta para Nenhuma organização usa este processo. Se você tem um projeto associados ao recurso da organização e quiser revertê-lo para Sem organização. Entre em contato com seu 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 qualquer recurso da organização. Para mais informações, consulte Como restringir a visibilidade do projeto para os usuários.

Para determinar se o projeto está associado a um recurso da organização, execute o seguinte:

gcloud projects describe PROJECT_ID

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

1. Verifique o impacto neste projeto das políticas que serão herdadas.

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

3. Atribua permissões do Identity and Access Management para o projeto e o recurso pai de destino como detalhadas em Atribuir permissões.

4. Determine se você precisa alterar a conta de faturamento.

Em seguida, faça a migração.

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

Se o Login do SO estiver ativado projeto de origem, você precisa atribuir o papel roles/compute.osLoginExternalUser aos 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 em o recurso da organização de origem deve definir uma política da organização contendo os constraints/resourcemanager.allowEnabledServicesForExport no pai do projeto a ser exportado. Essa restrição precisa listar SHARED_VPC como um allowed_value.

Não é preciso 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ê faça a correspondência das regras de firewall entre os recursos da organização nos locais de origem e destino, o que deve minimizar problemas potenciais e evitar qualquer tempo de inatividade para os projetos e a rede durante migração. Não oferecemos garantias sobre a integridade da sua rede se você deixa alguns projetos de serviço no recurso da organização de origem indefinidamente enquanto migrar outras pessoas.

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 ficar em organizações diferentes. No entanto, ao iniciar a migração dos projetos de serviço, é necessário migrar todos eles antes poderá migrar o projeto host novamente.

Papéis personalizados de gerenciamento de identidade e acesso

Papéis personalizados do Identity and Access Management podem ser criados recursos da organização para ter controle granular sobre o acesso a eles. mas só são válidos 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, falhar com um erro de pré-condição falha, explicando que a função em questão não não existem 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 CLI do Google Cloud:

gcloud iam roles list --organization ORGANIZATION_ID

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

Para saber mais 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 do recurso da organização mãe 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.

Após a migração do projeto, atualize o IAM políticas para usar os papéis personalizados no nível da organização no recurso da organização.

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 de retenção e a garantia são mantidas no projeto durante a migração, mas é importante saber que, ao migrar um projeto com um bloqueio aplicadas e evitam 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. A migração de projetos em perímetros do VPC Service Controls não pode ser bloqueada entre da organização. Essa diretriz se aplica até um dia após a criação ou o valor de um perímetro atualizado. Pode levar várias horas para que você possa migrar um projeto depois que ele tiver sido removido do perímetro de serviço.

Interconexão dedicada

Recomendamos migrar projetos com a Interconexão dedicada e projetos com anexos da VLAN juntos. Projetos com Objetos da Interconexão dedicada ou anexos da VLAN conectados à esses objetos continuarão 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 alterações de configuração feitas em um projeto em um recurso da organização que tem um um objeto de Interconexão dedicada anexado ou um anexo da VLAN ao este objeto pode não ser propagado para o outro recurso da organização. Recomendamos não deixar esses projetos divididos entre as recursos 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 de uma conta de serviço entre projetos, os seguintes casos se aplicam:

• Se você migrar um projeto que tem uma conta de serviço entre projetos vinculada a ele, essa conta de serviço continuará funcionando no recurso da organização de destino. Esse projeto continuará funcionando conta de serviço anexada, mesmo se houver uma política da organização que restringe o domínio desse em um projeto de IA.
• Se você migrar um projeto que tem uma conta de serviço entre projetos anexada para outro projeto no recurso da organização de origem, essa conta de serviço continuam a funcionar no recurso da organização de destino. No entanto, você não usar essa conta de serviço em qualquer recurso que tenha um domínio política da organização de restrição aplicada a eles que as restringe 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 depois 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, o a vinculação falhará, pois viola a restrição de restrição de domínio.

Histórico de consultas

Se você migrar um projeto que tem um caso de suporte aberto, será necessário entrar em contato com seu contato do Suporte do Google para informar que a migração foi concluída. Qualquer um os projetos com um caso de suporte em aberto com o Google não poderão visualizar 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 seu projeto estiver configurado para usar um Tela interna de permissão OAuth e migrar para outro recurso da organização, somente os membros recurso da organização de destino pode autorizar solicitações. Pode levar até 24 horas para que esse comportamento tenha efeito. Até lá, os membros da origem recurso da organização pode autorizar solicitações.

As etapas abaixo explicam como garantir que os membros da sua organização de origem recurso não perca o acesso durante a migração. Considere criar novos usuários em o recurso da organização de destino para os membros do recurso da organização, para que não será preciso 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. Apps marcados como internos e que usam dados sensíveis não precisarão solicitar a verificação de apps. Se o app usa dados sensíveis, quando a tela de consentimento for atualizada para externa, os usuários da origem recurso da organização verá uma tela do app não verificado 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 seu projeto de origem, você precisa atribuir o papel roles/compute.osLoginExternalUser aos principais que têm acesso a ele. Isso garante que esses principais não perca 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 (owner projeto) ou qualquer projeto com o qual a reserva seja compartilhada (consumidor projeto) podem consumir a reserva criando instâncias de VM. Só é possível compartilhar uma reserva com projetos dentro da mesma organização de do projeto do proprietário.

Ao migrar um projeto de proprietário ou consumidor para outra organização, o seguinte acontece:

• Se você migrar o projeto do proprietário para outra organização, faça o seguinte: O Compute Engine exclui qualquer reserva criada pelo projeto do proprietário. 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, o deixa de consumir recursos de qualquer reserva compartilhada no organização.

Saiba mais em Como funcionam as reservas compartilhadas.

Como anexar contas de serviço a recursos

Para a maioria dos serviços do Google Cloud, os usuários precisam do iam.serviceAccounts.actAs permissão em uma conta de serviço para anexá-la a um recurso. No entanto, no passado, para facilitar a integração, alguns serviços permitiam que os usuários anexar contas de serviço a recursos, mesmo que os usuários não tenham permissão para representem as contas de serviço. Isso está documentado em Como solicitar permissão para anexar contas de serviço a do Google Cloud.

Se um recurso da organização de origem do cliente tiver o comportamento legado (serviços anexo de contas é possível sem a concessão normal de papel) e o recurso da organização de destino, conceda o papel de usuário da conta de serviço (roles/iam.serviceAccountUser) aos usuários que anexarem essas contas de serviço do Google Cloud. Para mais informações sobre as permissões necessárias para anexar ao serviço contas a recursos, consulte Papéis da conta de serviço autenticaçã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 superior da página, escolha a organização recurso em 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 aparecer na lista, o recurso da organização tem o comportamento legado.

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

   • appengine.enforceServiceAccountActAsCheck
   • dataflow.enforceComputeDefaultServiceAccountCheck
   • dataproc.enforceComputeDefaultServiceAccountCheck
   • composer.enforceServiceAccountActAsCheck

6. Se uma dessas restrições de política da organização aparecer, usa 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 valores de origem e destino da organização têm o comportamento legado, mas nenhuma ação é necessária, aplique a política para evitar a falsificação de identidade não intencional.

Como migrar projetos com o Analytics Hub

Se você migrar o projeto que está usando o Analytics Hub para uma em outro recurso da organização, pode haver erros. Para resolva os erros, entre em contato com o suporte.

Se o recurso de troca de dados da organização antiga não for visível na página de administrador do Analytics Hub organização, use a API Analytics Hub para atualizar os 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

É preciso desativar o serviço de backup e DR antes de migrar projetos para um recurso da organização. No momento em que o serviço está desativado, há uma interrupção risco que você precisa considerar. Reativar o serviço de backup e DR após a conclusão da migração para o novo recurso da organização.

A seguir

Para saber como fazer a migração, consulte Fazer a migração.