Lidar com casos especiais

Este tópico fornece informações sobre como lidar com casos especiais relacionados à migração de projetos.

Como migrar projetos sem o recurso de 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 mudar de volta para Sem organização usando esse processo. Se você tiver um projeto associado ao recurso da sua organização e quiser revertê-lo para Sem organização, entre em contato com seu representante do suporte para receber ajuda.

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 processo de migração 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 aparecer, e essa etapa poderá ser pulada.

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

API

Usando a API Resource Manager, é possível migrar um projeto para o recurso da organização definindo o campo parent dele como o ID do recurso da organização.

Se quiser migrar um projeto para o recurso Organização, faça o seguinte:

• 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
    }

Se o Login do SO estiver ativado no projeto de origem, será necessário atribuir o papel roles/compute.osLoginExternalUser a qualquer principal que tenha acesso a esse projeto.

VPC compartilhada

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

Os projetos de VPC compartilhada podem ser migrados seguindo determinadas condições. Primeiro, um usuário com o papel roles/orgpolicy.policyAdmin no recurso da 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.

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ê corresponda as regras de firewall entre os recursos da organização nos locais de origem e de destino, o que 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 no recurso da organização de origem indefinidamente enquanto migra outros.

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 ter em organizações diferentes. No entanto, quando você começa a migrar os projetos de serviço, é necessário migrar todos eles antes de migrar o projeto host novamente.

Papéis personalizados de gerenciamento de identidade e acesso

Os papéis personalizados do Identity and Access Management podem ser criados no nível do recurso da organização para fornecer controle granular do acesso a recursos, mas são válidos apenas no recurso da organização em que são criados. Se você tentar migrar um projeto que contenha 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, a migração falhará com um erro de pré-condição com falha, 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 do recurso da organização para o qual você quer listar papéis. Para informações sobre como encontrar o ID do recurso da organização, consulte Como criar e gerenciar recursos da organização.

Para receber informações sobre um papel personalizado do Identity and Access Management no recurso da organização, execute o seguinte comando do 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 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, atualize 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 de retenção e a garantia são mantidas no projeto durante uma migração, mas você precisa saber se está migrando um projeto com um bloqueio de bucket aplicado e evitar 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 nos perímetros do VPC Service Controls não podem ter a migração impedida entre os recursos da organização. Essa diretriz se aplica até um dia após a criação ou atualização de um perímetro. Pode levar várias horas para que um projeto seja migrado depois que ele for removido do perímetro de serviço.

Interconexão dedicada

Recomendamos migrar projetos com objetos de Interconexão dedicada e projetos com anexos da VLAN juntos. Os projetos com objetos de Interconexão dedicada ou anexos da VLAN conectados a 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 objeto de Interconexão dedicada ou um anexo da VLAN a esse objeto podem não ser propagadas para o outro recurso da organização. 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

No contexto da migração de uma conta de serviço entre projetos, aplicam-se os seguintes casos:

• Se você migrar um projeto que tem uma conta de serviço entre projetos anexada a ele, essa conta continuará funcionando no recurso da organização de destino. Esse projeto continuará funcionando com a conta de serviço anexada, mesmo se houver uma política da organização que restrinja o domínio desse projeto.
• Se você migrar um projeto que tem uma conta de serviço entre projetos anexada a outro projeto no recurso da organização de origem, essa conta de serviço vai continuar funcionando no recurso da organização de destino. No entanto, não será possível usar essa conta de serviço em recursos que tenham uma política da organização de restrição de domínio aplicada a eles 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 migrar project-A para organizations/45678901234, a conta de serviço funcionará.

Se você migrar 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ê migrar um projeto que tenha um caso de suporte aberto, fale com seu contato do Suporte do Google para informar que a migração ocorreu. Os projetos que tiverem um caso de suporte aberto com o Google não poderão visualizar esses casos até que o Suporte do Google atualize os metadados deles 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 do OAuth interno e você migrar para outro recurso da organização, somente os 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 autorizar solicitações.

As etapas abaixo explicam como garantir que os membros do recurso da organização de origem não percam acesso durante a migração. Considere a criação de novos usuários no recurso da organização de destino para membros do recurso da organização, de modo que você não precise alterar a configuração da tela de permissão OAuth.

Para evitar a perda de acesso de 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 "externa", 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, será necessário atribuir o papel roles/compute.osLoginExternalUser a qualquer principal que tenha acesso a esse projeto. Isso garante que esses principais não percam o acesso ao recurso da organização de destino.

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 anexá-la a um recurso. No entanto, anteriormente, para facilitar a integração, determinados serviços permitiam que os usuários aninhassem contas de serviço a recursos mesmo que os usuários não tivessem permissão para representar essas contas. Isso está documentado em Como exigir permissão para anexar contas de serviço a recursos.

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 do papel) e o recurso da organização de destino não, conceda o papel de usuário da conta de serviço (roles/iam.serviceAccountUser) aos usuários que anexam essas contas de serviço aos recursos. Para informações sobre as permissões necessárias para anexar contas de serviço a recursos, consulte Papéis para autenticação 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 superior 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 aparecer 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íticas da organização:

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

6. Se alguma dessas restrições de política da organização aparecer, o recurso da organização usará o comportamento legado.

Se o recurso da organização de origem tiver o comportamento legado e o destino não, 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, considere aplicar 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 usa o Analytics Hub para um recurso da organização diferente, poderá encontrar alguns erros. Para resolver erros, entre em contato com o suporte.

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

Desative o serviço de backup e DR antes de migrar projetos para outro recurso da organização. No momento em que o serviço é desativado, há um risco de interrupção que você precisa considerar. Reative o serviço de backup e DR após concluir a migração para o novo recurso da organização.

A seguir

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