Lidar com casos especiais

Saiba como lidar com casos especiais ao migrar projetos. Antes de migrar um projeto, verifique se você tem as permissões necessárias do Identity and Access Management (IAM) permissões no projeto, no recurso pai e no recurso de destino.

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

É possível migrar um projeto que foi criado sem um recurso da organização associado para a hierarquia de um recurso da organização. No entanto, não é possível reverter esse processo. Para reverter um projeto para Nenhuma organização, entre em contato com o Cloud Customer Care para receber ajuda.

Para migrar um projeto que não está associado a um recurso da organização, você precisa ter o papel roles/resourcemanager.projectIamAdmin no projeto. Você também precisa ter o papel roles/resourcemanager.projectCreator no recurso da organização de destino.

Se você não tiver a permissão resourcemanager.organizations.get no recurso da organização pai, seus projetos poderão não aparecer como esperado na organização no Cloud de Confiance console. Isso pode fazer parecer que o projeto não está associado a um recurso da organização. Para mais informações, consulte Restringir a visibilidade do projeto para usuários.

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

gcloud projects describe PROJECT_ID

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 exige todas as etapas do 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 em o recurso da organização de destino, se necessário.

3. Atribua permissões do Identity and Access Management ao projeto e ao recurso pai de destino , conforme detalhado em Atribuir permissões.

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

Em seguida, você pode realizar a migração usando um destes métodos:

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 a API Login do SO na nuvem estiver ativada no projeto de origem, atribua o roles/compute.osLoginExternalUser papel a todos os principais que têm acesso a esse projeto.

VPC compartilhada

É possível migrar projetos de VPC compartilhada em 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 é necessário desativar a VPC compartilhada antes da migração. No entanto, é necessário migrar o projeto host da VPC compartilhada primeiro, seguido de todos os projetos de serviço. Recomendamos que você corresponda as regras de firewall entre os recursos da organização de origem e de destino para minimizar possíveis problemas e evitar inatividade. Não garantimos a integridade da sua rede se você deixar projetos de serviço no recurso da organização de origem 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 para quanto tempo os projetos host e de serviço podem estar em organizações diferentes. No entanto, depois de começar a migrar projetos de serviço, mova todos eles para migrar o projeto host novamente.

Papéis personalizados do IAM

Os papéis personalizados do Identity and Access Management fornecem controle granular do acesso aos recursos no nível do recurso da organização, mas eles são válidos apenas no recurso da organização em que foram criados. Se você migrar um projeto que contém uma vinculação de política de permissão para um papel personalizado do IAM no nível da organização, a migração falhará. O erro explica que o papel não existe no recurso da organização de destino.

Para listar todos os papéis personalizados do IAM no recurso da organização, execute o seguinte comando:

gcloud iam roles list --organization ORGANIZATION_ID

Substitua ORGANIZATION_ID pelo ID do recurso da organização. Para mais informações, consulte Receber o ID do recurso da organização.

Para informações sobre um papel personalizado do Identity and Access Management no recurso da organização, execute o seguinte comando:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Substitua:

• ORGANIZATION_ID: o ID do recurso da organização
• ROLE_ID: o nome do papel a ser descrito

Para contornar esse erro, crie papéis personalizados equivalentes para envolvidos no projeto para cada papel personalizado herdado no nível da organização. Em seguida, remova as vinculações de papéis do IAM que referenciam os papéis personalizados no nível da organização.

Depois de migrar o projeto, você poderá atualizar as políticas de permissão para usar os papéis personalizados no nível da organização no recurso da organização de destino.

Para mais informações, consulte Como criar e gerenciar papéis personalizados.

Bloqueio do bucket

O Bloqueio de bucket do Cloud Storage permite configurar uma política de retenção de dados em um bucket do Cloud Storage. Essa política determina quanto tempo os objetos 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 a migração. A garantia não impede a migração do projeto.

Perímetros de segurança do VPC Service Controls

O VPC Service Controls reduz os riscos de exfiltração de dados configurando um perímetro de segurança baseado em projetos em torno dos Cloud de Confiance by S3NS serviços. 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. Pode levar várias horas ou até um dia para migrar um projeto depois de removê-lo de um perímetro de serviço.

Políticas de Acesso Baseado no Contexto para contas de serviço

O Acesso Baseado no Contexto permite que os usuários definam políticas de acesso em Cloud de Confiance by S3NS recursos para contas de serviço com base em atributos de contexto, como rede, local e hora. Não é possível migrar um projeto que tenha pelo menos uma política de Acesso Baseado no Contexto para contas de serviço.

Para excluir uma política de Acesso Baseado no Contexto para contas de serviço, consulte Gerenciar vinculações de acesso.

Considere as seguintes considerações de tempo ao criar ou excluir políticas:

• Criação de políticas:uma política de Acesso Baseado no Contexto recém-criada pode não bloquear migrações imediatamente. Esse atraso de propagação pode durar até 24 horas após a criação da política.
• Exclusão de políticas:depois que todas as políticas de Acesso Baseado no Contexto forem removidas de um projeto, pode levar várias horas até que você possa migrar o projeto.

Interconexão dedicada

Recomendamos migrar projetos com objetos de Interconexão dedicada e projetos com anexos da VLAN. Os projetos com esses objetos continuam funcionando após a migração entre recursos da organização. No entanto, não é possível criar novos anexos da VLAN entre recursos da organização enquanto eles estiverem divididos.

As mudanças de configuração feitas em um projeto dividido podem não ser propagadas entre os recursos da organização. Recomendamos não deixar os projetos divididos por muito tempo.

Interconexão por parceiro

Não há considerações especiais para migrar projetos com o Interconexão por parceiro. Não há considerações especiais necessárias ao migrar projetos com a Interconexão por parceiro.

Projeto de gerenciamento

O projeto de gerenciamento é um Cloud de Confiance by S3NS projeto na pasta habilitada para apps que atua como um repositório central para todos os metadados centrados no aplicativo. Cada pasta habilitada para apps contém apenas um projeto de gerenciamento. O projeto de gerenciamento fornece a infraestrutura para bibliotecas de aplicativos e APIs, incluindo faturamento, cotas e controle de acesso. Não é possível migrar um projeto de gerenciamento.

Contas de serviço de projetos cruzados

Quando você migra uma conta de serviço entre projetos, os seguintes casos se aplicam:

• Se você migrar um projeto com uma conta de serviço entre projetos anexada, a conta de serviço continuará funcionando no recurso da organização de destino. Isso se aplica mesmo que uma política da organização restrinja o domínio.
• Se você migrar um projeto que é proprietário de uma conta de serviço entre projetos usada por outro projeto, a conta de serviço continuará funcionando. No entanto, não é possível usá-la em recursos que tenham uma política da organização de restrição de domínio aplicada que os restrinja ao domínio do recurso da organização de origem.

Por exemplo, suponha que project-A em organizations/12345678901 tenha serviceAccount-1 anexada. project-B e project-C na mesma organização também usam serviceAccount-1.

project-C tem uma política da organização que permite apenas o domínio organizations/12345678901.

Se você adicionar serviceAccount-1 à vinculação do IAM para project-C antes de 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 com um caso de suporte aberto, notifique o Cloud Customer Care após a migração. Não é possível visualizar esses casos de suporte até que o Cloud Customer Care atualize os metadados para o novo recurso da organização.

Tela de permissão OAuth

Se o projeto usar uma tela de permissão OAuth interna, somente os membros do recurso da organização de destino poderão autorizar solicitações após a migração. Essa mudança pode levar até 24 horas para entrar em vigor. Até lá, os membros do recurso da organização de origem ainda poderão autorizar solicitações.

Para garantir que os membros de origem não percam o acesso, considere criar novos usuários no recurso da organização de destino ou atualizar a configuração da tela de permissão OAuth:

1. Atualize a tela de permissão do OAuth para ser externa, em vez de interna.

2. Se o app usar dados sensíveis, solicite a verificação de apps para escopos sensíveis ou restritos. Caso contrário, os usuários vão ver uma tela de app não verificado.

API Login do SO

Se a API Login do SO na nuvem estiver ativada no projeto de origem, atribua o roles/compute.osLoginExternalUser papel a todos os principais que têm acesso a esse projeto. Isso garante que esses principais não percam o acesso no 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 (projeto proprietário) ou qualquer projeto com que ela seja compartilhada (projeto do consumidor) pode consumir a reserva criando instâncias de VM. Só é possível compartilhar uma reserva com projetos da mesma organização do projeto proprietário.

Quando você migra um projeto proprietário ou do consumidor, o seguinte acontece:

• Se você migrar o projeto proprietário, o Compute Engine vai excluir todas as reservas criadas por esse projeto. As instâncias de VM em execução não são afetadas.
• Se você migrar um projeto do consumidor, ele deixará de consumir recursos de qualquer reserva compartilhada na organização anterior.

Saiba mais em Como as reservas compartilhadas funcionam.

Como anexar contas de serviço a recursos

Para a maioria dos Cloud de Confiance by S3NS serviços, você precisa da iam.serviceAccounts.actAs permissão para anexar uma conta de serviço a um recurso. No entanto, alguns serviços permitiram isso historicamente sem permissões de representação explícitas. Isso está documentado em Como exigir permissão para anexar contas de serviço a recursos.

Se o recurso da organização de origem tiver esse comportamento legado, mas o destino não, conceda o papel roles/iam.serviceAccountUser aos usuários que anexarem essas contas de serviço. Para mais informações sobre permissões, consulte Papéis para autenticação da conta de serviço.

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

1. No Cloud de Confiance 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 recursos, escolha o recurso da organização que você quer verificar.

3. Na caixa de filtro, digite constraints/appengine.enforceServiceAccountActAsCheck.

4. Se a política aparecer, o recurso da organização terá o comportamento legado.

5. Repita as etapas 3 e 4 para cada uma das seguintes restrições:

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

Se alguma dessas restrições aparecer, o recurso da organização usará o comportamento legado. Se os dois recursos da organização usarem o comportamento legado, nenhuma ação será necessária. No entanto, é necessário aplicar a política para evitar a representação não intencional.

Migrar projetos com BigQuery Sharing

Se você migrar um projeto que usa o compartilhamento do BigQuery para outro recurso da organização, poderá encontrar erros. Para resolvê-los, entre em contato com o Cloud Customer Care.

Se o recurso de troca de dados da organização anterior não estiver visível na página do administrador de compartilhamento da nova organização, use a API de compartilhamento do BigQuery para atualizar um campo (por exemplo, description) para acionar uma atualização do cache.

Use o projects.locations.dataExchanges.patch método.

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, como description
• UPDATE_DX_VALUE: o valor atualizado

Serviço de backup e DR

Desative o Backup e DR antes de migrar projetos para um recurso da organização diferente. Considere o risco de interrupção quando o serviço estiver desativado. Reative o Backup e DR após a conclusão da migração.

Federação de identidade da carga de trabalho

A federação de identidade da carga de trabalho permite conceder acesso às cargas de trabalho locais ou multicloud aos Cloud de Confiance by S3NS recursos. Os pools de federação de identidade da carga de trabalho são recursos com escopo de projeto.

Quando você migra um projeto, os pools de identidade da carga de trabalho e os provedores configurados nesse projeto são migrados com ele. Nenhuma ação adicional é necessária para manter o acesso às cargas de trabalho que usam esses pools.

Tags

As tags são pares de chave-valor anexados a recursos. As tags criadas no nível da organização não são migradas.

Se o projeto usar tags no nível da organização para vinculações ou restrições de políticas, será necessário recriar as chaves e os valores de tag no recurso da organização de destino e anexá-los novamente aos projetos migrados.

Migrar projetos com concessões herdadas do Privileged Access Manager

Antes de migrar um projeto, recomendamos que você revogue todas as concessões ativas com escopo nesse projeto. Uma concessão com escopo é criada em um direito herdado de uma pasta ou organização e, em seguida, é definida para um projeto filho.

Quando você migra um projeto com uma concessão ativa com escopo, a política do IAM é movida para a nova organização, mas a concessão que a gerencia permanece na organização anterior. O agente de serviço do Privileged Access Manager perde a permissão para modificar a política do IAM na nova organização. Consequentemente, todas as operações de revogação ou retirada nessa concessão falham, e o solicitante mantém o acesso até que a concessão expire.

A seguir

• Faça a migração