VPC Service Controls: proteção do serviço de transferência de dados do BigQuery

1. Introdução

Neste laboratório, vamos aprender a proteger o serviço de transferência de dados do BigQuery usando o VPC Service Controls ao transferir dados do Cloud Storage para um conjunto de dados do BigQuery. Em seguida, protegemos o Cloud Storage e repetimos o processo para transferir dados do Cloud Storage para o BigQuery. A proteção do Cloud Storage causa uma violação do VPC Service Controls, que precisa ser corrigida para que a transferência seja bem-sucedida. Por fim, também protegemos o BigQuery e tentamos copiar o conjunto de dados entre projetos, o que também causa uma violação que precisa ser corrigida.

Neste laboratório, vamos mostrar como corrigir violações de entrada e saída usando as regras de entrada e saída, respectivamente. Também vamos usar um nível de acesso para corrigir a violação de entrada da transferência de dados do BigQuery. As metas deste codelab são:

• Entenda como corrigir violações de entrada e saída usando regras de entrada e saída, respectivamente, em diferentes serviços, principalmente o Cloud Storage, o BigQuery e o serviço de transferência de dados do BigQuery.
• Entender por que uma violação específica ocorreu.

2. Configuração e requisitos de recursos

Antes de começar

Neste codelab, presumimos que você já sabe:

• Como criar uma pasta
• Como criar um projeto em uma pasta ou mover um projeto para uma pasta
• Como criar uma política de acesso com escopo
• Como criar e configurar um perímetro de serviço no console do Google Cloud
• Como encontrar registros de violações nos registros de auditoria

Esses pré-requisitos foram abordados em outros codelabs do VPC Service Controls: Tutorial básico I do VPC Service Controls e Tutorial básico II do VPC Service Controls: como solucionar problemas de violação de saída.

Configuração

Nossa configuração inicial foi projetada da seguinte maneira:

• Uma organização do Google Cloud.
• Uma pasta na organização. Neste codelab, vamos chamá-lo de codelab-folder.
• Dois projetos do Google Cloud na pasta codelab-folder. Neste codelab, chamamos os projetos de project-1 e project-2.
  • Se você ainda não tiver criado a pasta e os projetos, no console do Google Cloud, crie uma pasta na organização e crie dois projetos.
• As permissões necessárias: papéis do IAM para gerenciar pastas, papéis do IAM para gerenciar projetos, papéis do IAM necessários para configurar o VPC Service Controls, papéis do IAM para gerenciar o BigQuery e papéis do IAM para gerenciar o Cloud Storage.
• Conta de faturamento para os projetos project-1 e project-2.

Para este codelab, conceda a si mesmo os seguintes papéis predefinidos: Administrador de pastas e Criador de projetos (no nível da pasta), Proprietário (no nível do projeto), Administrador do BigQuery (no nível do projeto), Administrador de objetos do Storage (no nível do projeto) e Administrador do Access Context Manager (no nível da organização). Assim, você terá os papéis necessários para configurar os recursos necessários para todo o codelab.

Criar uma política com escopo e um perímetro de serviço normal

Neste codelab, vamos usar um perímetro de serviço normal que protege project-2.

• Crie uma política de acesso com escopo no nível da pasta codelab-folder. Para este codelab, vamos presumir que a política de acesso criada tem o ID 987654321.
• Crie um perímetro regular, chamado perimeter-2, e adicione o projeto project-2.

No perímetro perimeter-2, restrinja BigQuery Data Transfer API.

Criação de bucket do Cloud Storage e conjunto de dados do BigQuery

Para este codelab, qualquer arquivo CSV é suficiente, independente do conteúdo. A principal limitação está relacionada ao requisito de colocalização, que exige o seguinte:

• Se o conjunto de dados do BigQuery estiver em uma multirregião, o bucket do Cloud Storage que contém os dados a serem transferidos precisará estar na mesma multirregião ou em um local dentro dela.
• Se o conjunto de dados estiver em uma região, o bucket do Cloud Storage precisará estar na mesma região.

Daqui em diante, para este codelab, vamos garantir que o bucket do Cloud Storage e o conjunto de dados do BigQuery estejam na mesma região ou multirregião.

Crie um bucket do Cloud Storage no projeto project-1

Neste codelab, vamos usar o Cloud Storage como fonte de dados, que é uma fonte de dados compatível com o serviço de transferência de dados do BigQuery.

Para criar um bucket do Cloud Storage, siga as etapas documentadas para criar um bucket.

• Em "Nome do bucket", insira um nome que atenda aos requisitos de nome de bucket. Neste codelab, vamos chamar o bucket de codelab-bqtransfer-bucket.
• Em "Onde armazenar os dados, local do bucket", selecione um Tipo de local e um Local onde os dados do bucket serão armazenados permanentemente. Neste codelab, vamos usar us (várias regiões nos Estados Unidos).

Criar um arquivo CSV

Se você já tiver um arquivo CSV de amostra, pule esta etapa.

Na sua máquina local ou usando o Cloud Shell, é possível usar o comando echo para criar um arquivo CSV de exemplo, codelab-test-file.csv, com os seguintes comandos:

echo "name,age" > codelab-test-file.csv; \
echo "Alice,10" >> codelab-test-file.csv; \
echo "Bob,20" >> codelab-test-file.csv; \
echo "Carol,30" >> codelab-test-file.csv; \
echo "Dan,40" >> codelab-test-file.csv; \
echo "Eve,50" >> codelab-test-file.csv; \
echo "Frank,60" >> codelab-test-file.csv; \
echo "Grace,70" >> codelab-test-file.csv; \
echo "Heidi,80" >> codelab-test-file.csv;

Fazer upload do arquivo CSV para o bucket do Cloud Storage

Depois que o arquivo CSV for criado, execute o comando a seguir para fazer upload do objeto de arquivo para o bucket criado:

gcloud storage cp codelab-test-file.csv gs://codelab-bqtransfer-bucket

Para verificar se o arquivo foi enviado por upload para o bucket criado, liste os objetos no bucket ou execute o seguinte comando:

gcloud storage ls --recursive gs://codelab-bqtransfer-bucket/**

Criar conjunto de dados e tabela do BigQuery em project-2

1. Crie um conjunto de dados do BigQuery no projeto project-2 seguindo estas etapas.
   1. Em ID do conjunto de dados, insira um nome exclusivo. Neste codelab, usamos: codelab_bqtransfer_dataset.
   2. Em Tipo de local, escolha um local geográfico para o conjunto de dados. Neste codelab, usamos o mesmo local do bucket do Cloud Storage: EUA (várias regiões nos Estados Unidos).
2. Crie uma tabela do BigQuery no conjunto de dados codelab_bqtransfer_dataset seguindo estas etapas.
   1. Na seção Origem, selecione Tabela vazia na lista Criar tabela de.
   2. No campo Tabela, insira o nome da tabela que você quer criar. Neste codelab, vamos usar o nome codelab-bqtransfer-table.
   3. Verifique se o campo Tipo de tabela está definido como Tabela nativa.
   4. Na seção Esquema, insira a definição do esquema. Para inserir informações de esquema, clique em Editar como texto e insira o seguinte esquema, que está de acordo com o formato do arquivo CSV criado.

   [{
   "name": "name",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The name"
   },
   {
   "name": "age",
   "type": "INTEGER",
   "mode": "NULLABLE",
   "description": "The age"
   }]
   

Custo

Ative o faturamento nos projetos project-2 e project-1 para usar os recursos/APIs do Cloud. Recomendamos desligar os recursos usados para evitar cobranças além deste codelab.

Novos usuários do Google Cloud estão qualificados para o programa de US $300 de avaliação sem custos.

Os recursos que geram o custo são o BigQuery e o Cloud Storage. Um custo estimado pode ser encontrado na calculadora de preços do BigQuery e na calculadora do Cloud Storage.

3. Configurar a transferência de dados do objeto do Cloud Storage para a tabela do BigQuery

Agora vamos tentar criar um serviço de transferência de dados (em project-2) para transferir do Cloud Storage (localizado em project-1) para o BigQuery (localizado em project-2), enquanto o VPC Service Controls protege o serviço de transferência de dados do BigQuery em project-2. Proteger apenas o serviço de transferência de dados do BigQuery (sem proteger também o BigQuery e o Cloud Storage) restringe os principais a apenas criar e gerenciar transferências de dados (como iniciar manualmente uma transferência de dados).

Configurar a transferência de dados do Cloud Storage

Para criar uma transferência de dados, siga estas etapas:

1. Acesse a página do BigQuery no console do Google Cloud de project-2.
2. Clique em Transferências de dados.

Uma violação do VPC Service Controls vai ocorrer, já que o perímetro perimeter-2 está protegendo o serviço de transferência de dados do BigQuery em project-2. O acesso precisa ser permitido pelos VPC Service Controls antes da configuração da transferência de dados.

Investigar a violação ao acessar a página "Transferências de dados"

No console do Google Cloud, podemos ver o identificador exclusivo do VPC Service Controls. Use o mesmo identificador para filtrar registros e identificar detalhes da violação. Substitua OBSERVED_VPCSC_DENIAL_UNIQUE_ID pelo ID da negação observada:

protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="OBSERVED_VPCSC_DENIAL_UNIQUE_ID"

A violação observada é um NO_MATCHING_ACCESS_LEVEL, que é uma violação de entrada com detalhes semelhantes aos seguintes:

ingressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
targetResource: "projects/[PROJECT2_NUMBER]"
}]
violationReason: "NO_MATCHING_ACCESS_LEVEL"
callerIp: "USER_PUBLIC_IP_ADDRESS"
resource: {
labels: {
method: "google.cloud.bigquery.datatransfer.v1.DataTransferService.ListTransferConfigs"
project_id: "project-2"
service: "bigquerydatatransfer.googleapis.com"
}
type: "audited_resource"
}

O acesso à página "Transferências de dados" tenta listar todas as transferências de dados configuradas. Portanto, há uma violação do método ListTransferConfigs.

Corrigir a violação do serviço bigquerydatatransfer.googleapis.com

Um nível de acesso ou uma regra de entrada podem ser usados para corrigir uma violação de entrada. Neste codelab, vamos usar uma regra de entrada configurada com a identidade de usuário negada, que permite o acesso ao serviço bigquerydatatransfer.googleapis.com e a todos os métodos.

Depois que a regra de entrada estiver em vigor, o acesso à página Transferências de dados vai funcionar sem problemas.

Retomar a configuração da transferência de dados do Cloud Storage

Nas etapas anteriores, na página "Transferências de dados" (depois de clicar em "Transferências de dados"), siga estas etapas:

1. Clique em + Criar transferência.
2. Na seção Tipo de origem, em Origem, escolha Google Cloud Storage.
3. No campo Nome de exibição da seção Nome da configuração de transferência, insira um nome para a transferência, como Codelab Transfer.
4. Na seção Opções de programação:
   1. Selecione uma Frequência de repetição, como 15 minutos.
   2. Selecione Começar agora. Caso contrário, a transferência de dados só vai começar depois da Frequência de repetição configurada.
5. Na seção Configurações de destino, em Conjunto de dados de destino, escolha o conjunto criado para armazenar seus dados: codelab_bqtransfer_dataset
6. Na seção Detalhes da fonte de dados
   1. Em Tabela de destino, insira o nome da tabela. A tabela de destino precisa seguir as regras de nomenclatura de tabela. Neste codelab, vamos usar a tabela que criamos anteriormente: codelab-bqtransfer-table
   2. Em URI do Cloud Storage, insira o URI do Cloud Storage. Neste codelab, vamos usar o bucket e o arquivo criados: codelab-bqtransfer-bucket/codelab-test-file.csv
   3. Em Preferência de gravação, mantenha APPEND ou escolha MIRROR.
   4. NÃO selecione a opção para excluir arquivos após a transferência, porque vamos reutilizar o mesmo arquivo várias vezes. No entanto, é possível usar vários arquivos e excluir os de origem após a transferência.
   5. Em Formato de arquivo, selecione CSV.
   6. Em Opções de transferência, em CSV, insira vírgula(",") como o Delimitador de campo.
7. No menu Conta de serviço, selecione uma conta de serviço nas contas de serviço associadas ao seu projeto do Google Cloud.
   1. A conta de serviço selecionada precisa ter as permissões necessárias para o Cloud Storage no projeto que hospeda o bucket de armazenamento, project-1 neste codelab.
   2. Neste codelab, vamos usar uma conta de serviço criada em project-2 como [e-mail].
8. Clique em Salvar.

Como selecionamos Começar agora como a opção de programação, a primeira transferência será iniciada assim que Salvar for selecionado.

A conta de serviço especificada na configuração da transferência de dados será usada para acessar o objeto do bucket do Cloud Storage. Para cada tentativa de transferência de dados, os registros em project-1 (o projeto de origem) precisam mostrar uma entrada de registro da conta de serviço fazendo a chamada storage.objects.get (serviceName: "storage.googleapis.com") no objeto que está sendo transferido. Por outro lado, ao verificar os registros em project-2, que hospeda a tabela de destino do BigQuery, você vai descobrir que o agente do serviço de transferência de dados do BigQuery é quem grava os dados (serviceName: 'bigquery.googleapis.com') do objeto de armazenamento na tabela especificada do BigQuery.

Verificar o status do serviço de transferência de dados

Para verificar o status da transferência de dados configurada:

• Acesse a página do BigQuery no console do Google Cloud.
• Clique em Transferências de dados.
• A lista de transferências configuradas é exibida.

Clique em Codelab Transfer (em "Nome de exibição") para mostrar uma lista de todas as execuções realizadas até o momento.

A execução da transferência de dados precisa ser concluída sem violação do VPC Service Controls, tanto para transferências manuais quanto programadas. Observe que apenas a transferência acionada manualmente precisa da regra de entrada para permitir o acesso ao principal que está iniciando a transferência manualmente.

4. Restrições de endereço IP para transferências de dados acionadas manualmente

As regras de entrada configuradas atualmente permitem que a identidade configurada acione a transferência de dados manualmente de qualquer endereço IP.

Com o uso do nível de acesso, o VPC Service Controls oferece a capacidade de limitar o acesso permitido por atributos específicos de solicitação de API, principalmente:

• Sub-redes de IP: verifica se a solicitação está vindo de um endereço IP específico.
• Regiões: verifica se a solicitação está vindo de uma região específica, determinada pela geolocalização do endereço IP.
• Principais: verifica se a solicitação está vindo de uma conta específica.
• Política de dispositivo: verifica se a solicitação vem de um dispositivo que atende a requisitos específicos.

Para aplicar a verificação desses atributos com a regra de entrada já configurada, é necessário criar um nível de acesso que permita os atributos desejados e, em seguida, adicionar o nível de acesso criado como a origem na regra de entrada.

Este diagrama ilustra o acesso iniciado pelos dois principais ([e-mail] e [e-mail]) em três cenários, demonstrando como o VPC Service Controls avalia fontes (nível de acesso de entrada) e atributos de identidade como uma condição AND em que ambos precisam corresponder.

1. O usuário [e-mail] tem acesso permitido ao tentar acessar de um endereço IP permitido pelo nível de acesso, porque o endereço IP e a conta de usuário correspondem às configurações na regra de entrada.
2. O acesso do usuário [e-mail] é bloqueado quando o endereço IP dele não corresponde ao endereço IP permitido, mesmo que a conta dele seja a configurada na regra de entrada.
3. O usuário [e-mail] tem o acesso bloqueado, mesmo tentando acessar de um endereço IP permitido, porque a conta dele não é permitida pela regra de entrada.

Criar nível de acesso

Para criar um nível de acesso que limita o acesso por endereço IP:

1. Abra a página do Access Context Manager no console do Google Cloud.
   • Se solicitado, selecione a pasta codelab-folder.
2. Na parte de cima da página do Access Context Manager, clique em CRIAR NÍVEL DE ACESSO.
3. No painel Novo nível de acesso, dê um Título ao novo nível de acesso. Neste codelab, vamos chamá-lo de project_2_al.
4. Na seção Condições, clique em + ao lado de Sub-redes de IP.
5. Na caixa Sub-redes de IP, selecione IP público
   .
   • Como alternativa, selecione usar o IP particular para usar o endereço IP interno nos níveis de acesso. No entanto, neste codelab, vamos usar um IP público.
   • Insira um ou mais intervalos IPv4 ou IPv6 formatados como blocos CIDR.

Os registros de violação do VPC Service Controls mostram o endereço IP público do usuário, a menos que o acesso tenha sido feito de uma instância do Compute Engine sem um endereço IP externo.

Adicionar nível de acesso à regra de entrada

Na regra de entrada, o nível de acesso é referenciado no campo sources, que é obrigatório, conforme documentado na referência de regra de entrada. Para permitir a entrada de recursos, o VPC Service Controls avalia os atributos sources e identityType como uma condição AND. A regra de entrada usa a identidade do principal que aciona a transferência de dados manualmente, não a conta de serviço especificada na configuração da transferência.

Execute a transferência novamente com as configurações que limitam o acesso por endereço IP.

Para avaliar a eficácia das configurações aplicadas, acione a transferência novamente usando os seguintes cenários:

• usando o endereço IP no intervalo permitido no nível de acesso referenciado pela regra de entrada.
• usando um endereço IP não permitido pelas configurações

O acesso de um endereço IP permitido será bem-sucedido, enquanto o acesso de um endereço IP não permitido vai falhar e resultar em uma violação do VPC Service Controls.

Uma maneira fácil de testar usando um endereço IP diferente é permitir o endereço IP atribuído ao usar o console do Google Cloud e testar usando o Cloud Shell.

No Cloud Shell, execute o comando a seguir para acionar manualmente uma transferência, substituindo RUN_TIME e RESOURCE_NAME:

bq mk \
  --transfer_run \
  --run_time='RUN_TIME' \
  RESOURCE_NAME

Por exemplo, o comando de amostra a seguir é executado imediatamente para uma configuração de transferência 12345678-90ab-cdef-ghij-klmnopqrstuv no projeto 1234567890.

NOW=$(TZ=GMT date +"%Y-%m-%dT%H:%M:%SZ");
bq mk \
  --transfer_run \
  --run_time=$NOW \
  projects/1234567890/locations/us/transferConfigs/12345678-90ab-cdef-ghij-klmnopqrstuv

A saída observada mostra uma violação do VPC Service Controls, como esperado, já que o endereço IP não é permitido.

A violação observada está no método DataTransferService.StartManualTransferRuns.

ingressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
targetResource: "projects/[PROJECT2_NUMBER]"
targetResourcePermissions: [0: "vpcsc.permissions.unavailable"]
}]
violationReason: "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
resource: {
labels: {
method: "google.cloud.bigquery.datatransfer.v1.DataTransferService.StartManualTransferRuns"
project_id: "project-2"
service: "bigquerydatatransfer.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"

5. Como iniciar a transferência de dados e proteger o serviço do Cloud Storage

Como estamos realizando uma transferência do Cloud Storage para o BigQuery, vamos adicionar o Cloud Storage aos serviços protegidos pelo VPC Service Controls e verificar se a transferência continua sendo feita.

Na configuração perimeter-2, adicione a API Cloud Storage como um dos serviços restritos, junto com a API BigQuery Data Transfer.

Depois de proteger a API Storage, aguarde a próxima transferência de dados programada ou inicie uma transferência manualmente seguindo estas etapas:

1. Acesse a página do BigQuery no console do Google Cloud.
2. Clique em Transferências de dados.
3. Selecione a transferência na lista. Neste codelab, vamos usar a transferência Codelab Transfer.
4. Clique em Executar transferência agora.
5. Clique em OK.

Outra transferência será iniciada. Talvez seja necessário atualizar a página para ver a mudança. Desta vez, a transferência vai falhar com uma violação do VPC Service Controls.

Investigar uma violação do VPC Service Controls do Cloud Storage

Filtre os registros de auditoria usando o vpcServiceControlsUniqueIdentifier, conforme mostrado no Resumo da transferência.

A violação observada é uma violação de saída RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER com os seguintes detalhes:

• O principal é a conta de serviço configurada no Serviço de transferência de dados. Seja acionada manualmente ou executando a transferência de dados programada, o principal negado será o mesmo.
• O serviço afetado é o Cloud Storage
• A origem da solicitação é o projeto em que o serviço de transferência de dados está configurado: project-2
• O projeto de destino é aquele em que o objeto do Cloud Storage está localizado: project-1

principalEmail: "[e-mail]"
egressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
source: "projects/[PROJECT2_NUMBER]"
sourceType: "Resource"
targetResource: "projects/[PROJECT1_NUMBER]"
targetResourcePermissions: [0: "storage.objects.get"]
}]
labels: {
method: "google.storage.objects.get"
project_id: "project-2"
service: "storage.googleapis.com"
}

Corrigir a violação de saída do Cloud Storage

Para corrigir a violação de saída, precisamos usar uma regra de saída que permita o tráfego da conta de serviço negada para o projeto com objetos do Cloud Storage.

Depois de modificar o perímetro de serviço perimeter-2, repita o processo para acionar a transferência novamente. A transferência não vai mostrar um erro.

6. Copiar o conjunto de dados do BigQuery do projeto-2 para o projeto-1

Depois de confirmar que podemos transferir dados do bucket do Cloud Storage em project-1 para o conjunto de dados do BigQuery em project-2, vamos copiar o conjunto de dados do BigQuery de project-2 para project-1. A API BigQuery é protegida pelo VPC Service Controls.

Para criar e copiar o conjunto de dados, vamos usar o comando bq mk, que usa a ferramenta bq.

O BigQuery usa o serviço de transferência de dados do BigQuery no back-end para copiar conjuntos de dados.

Criar conjunto de dados de destino no project-1

Antes de copiar o conjunto de dados, é preciso criar o conjunto de dados de destino. Para criar o conjunto de dados de destino, execute o comando a seguir, que cria um conjunto de dados chamado copied_dataset no projeto project-1 com us como local.

bq mk \
  --dataset \
  --location=us \
  project-1:copied_dataset

Proteger o serviço do BigQuery em project-2 com o VPC Service Controls

Modifique a configuração do perímetro perimeter-2 e adicione a API BigQuery como o serviço protegido, junto com os serviços Transferência de dados do BigQuery e Cloud Storage.

Iniciar cópia do conjunto de dados

Para copiar o conjunto de dados, execute o comando bq mk a seguir, que copia o conjunto de dados codelab_bqtransfer_dataset no projeto project-2 para o conjunto de dados copied_dataset em project-1 e substitui o conteúdo do conjunto de dados, se houver.

bq mk \
  --transfer_config \
  --project_id=project-1 \
  --target_dataset=copied_dataset \
  --data_source=cross_region_copy \
  --display_name='Dataset from project-2 to project-1' \
  --params='{
     "source_dataset_id":"codelab_bqtransfer_dataset",
     "source_project_id":"project-2",
     "overwrite_destination_table":"true"
     }'

O comando será executado sem problemas. Enquanto isso, a configuração de transferência será criada para iniciar a operação de cópia do conjunto de dados. A cópia do conjunto de dados vai falhar com uma violação do VPC Service Controls.

Para encontrar os detalhes da violação correspondente do VPC Service Controls, verifique os registros em project-2 (projeto do conjunto de dados de origem) com a seguinte consulta de registro. A consulta de registro filtra os registros no serviço do BigQuery e o nome do recurso do conjunto de dados que está sendo copiado (codelab_bqtransfer_dataset).

resource.labels.service="bigquery.googleapis.com"
protoPayload.metadata.resourceNames:"datasets/codelab_bqtransfer_dataset"

A violação observada do VPC Service Controls é uma violação de saída de project-2 para project-1.

egressViolations: [
  0: {
   servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
   source: "projects/[PROJECT-2-NUMBER]"
   sourceType: "Resource"
   targetResource: "projects/[PROJECT-1-NUMBER]"
   targetResourcePermissions: [
     0: "bigquery.transfers.update"
     1: "bigquery.transfers.get"
     2: "bigquery.jobs.create"
     ]
   }
]
method: "bigquery.tables.getData"
service: "bigquery.googleapis.com"

Corrigir todas as violações do BigQuery e iniciar a cópia do conjunto de dados novamente

Ao realizar uma cópia de conjunto de dados do BigQuery entre projetos que não estão no mesmo perímetro de serviço, a regra de entrada/saída precisa permitir todos os métodos para que o processo funcione. Esse comportamento pode mudar no futuro. Acompanhe as atualizações no rastreador de problemas público.

Para corrigir a violação de saída, precisamos criar uma regra que permita o principal negado. O principal negado é aquele que executa o comando mk.

Depois que a regra de saída estiver em vigor, no perímetro perimeter-2, execute o mesmo comando para copiar o conjunto de dados. Desta vez, ele vai copiar o conjunto de dados sem violação do VPC Service Controls.

7. Limpeza

Não há cobrança extra pelo uso do VPC Service Controls quando o serviço não está em uso, mas é recomendável limpar a configuração usada neste laboratório. Você também pode excluir a instância de VM e/ou os projetos do Cloud para evitar cobranças. A exclusão do projeto na nuvem interrompe o faturamento de todos os recursos usados nele.

• Para excluir o bucket do Cloud Storage, siga estas etapas:
  • No console do Google Cloud, acesse a página "Buckets do Cloud Storage".
  • Marque a caixa de seleção do bucket que você quer excluir e clique em Excluir.
  • Na janela de sobreposição que aparece, confirme que você quer excluir o bucket e o conteúdo dele.
• Para excluir o conjunto de dados do BigQuery, siga estas etapas:
  • No console do Google Cloud, acesse a página do BigQuery.
  • No painel Explorer, expanda o projeto e selecione um conjunto de dados.
  • Abra o menu de três pontos e clique em Excluir.
  • Na caixa de diálogo Excluir conjunto de dados, digite delete no campo e clique em Excluir.
• Para excluir o perímetro de serviço, siga estas etapas:
  • No console do Google Cloud, selecione Segurança e VPC Service Controls no nível em que a política de acesso está no escopo, neste caso, no nível da pasta.
  • Na página do VPC Service Controls, na linha da tabela correspondente ao perímetro que você quer excluir, selecione Delete Icon.
• Para excluir o nível de acesso, siga estas etapas:
  • No console do Google Cloud, abra a página Access Context Manager no escopo da pasta.
  • Na grade, identifique a linha do nível de acesso que você quer excluir, selecione o menu de três pontos e clique em Excluir.
• Para encerrar os projetos, siga estas etapas:
  • No console do Google Cloud, acesse a página Configurações do IAM e do administrador do projeto que você quer excluir.
  • Na página "Configurações do IAM e administrador", selecione Desativar.
  • Digite o ID do projeto e selecione Encerrar mesmo assim.

8. Parabéns!

Neste codelab, você criou, aplicou e resolveu problemas em um perímetro do VPC Service Controls.

Saiba mais

Você também pode conferir os seguintes cenários:

• Adicione project-1 em um perímetro diferente que também proteja o BigQuery, o serviço de transferência de dados do BigQuery e o Cloud Storage.
• Faça a transferência de dados do BigQuery de outras fontes compatíveis.
• Restrinja o acesso do usuário por outros atributos, como localização ou política de dispositivo.

Licença

Este conteúdo está sob a licença Atribuição 2.0 Genérica da Creative Commons.