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 concluída. 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 regras de entrada e saída, respectivamente. Também vamos usar um nível de acesso para corrigir a violação de entrada de transferência de dados do BigQuery. Os objetivos 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 do VPC Service Controls I e Tutorial básico do VPC Service Controls II: solução de problemas de violação de saída.

Configuração

Nossa configuração inicial é 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. Para este codelab, chamamos os projetos de project-1 e project-2.
  • Se você ainda não tiver a pasta e os projetos criados, no console do Google Cloud, crie uma pasta na organização e crie dois novos 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 os controles de serviço da VPC, 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, você pode conceder 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 Gerenciador de contexto de acesso (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 regular

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

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

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

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

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

• 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 da multirregião.
• Se o conjunto de dados estiver em uma região, o bucket do Cloud Storage precisará estar na mesma região.

A partir de agora, neste 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 a fonte de dados, que é uma fonte de dados com suporte para o serviço de transferência de dados do BigQuery.

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

• Para o nome do bucket, insira um nome que atenda aos requisitos de nome de bucket. Neste codelab, vamos chamar o bucket de codelab-bqtransfer-bucket.
• Para armazenar os dados, selecione um Tipo de local e um Local em que 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á tem um arquivo CSV de exemplo, pule esta etapa.

Na sua máquina local ou usando o Cloud Shell, podemos usar o comando echo para criar um arquivo CSV de amostra, codelab-test-file.csv, usando 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 no 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, listar objetos no bucket ou executar o seguinte comando:

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

Criar um conjunto de dados e uma tabela do BigQuery no 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 para o conjunto de dados. 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 criado 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, usamos 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 do esquema, clique em Editar como texto e insira o esquema a seguir, que está em conformidade 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

É necessário ativar o faturamento nos projetos project-2 e project-1 para usar os recursos/APIs do Cloud. Recomendamos encerrar os recursos usados para evitar cobranças além deste codelab.

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

Os recursos que geram o custo são o BigQuery e o Cloud Storage. É possível encontrar um custo estimado 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 os controles de serviço da VPC protegem o serviço de transferência de dados do BigQuery em project-2. A proteção apenas do serviço de transferência de dados do BigQuery (sem proteger o BigQuery e o Cloud Storage) restringe os principais usuários a criar e gerenciar transferências de dados, como iniciar uma transferência manualmente.

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 pelo VPC Service Controls antes de configurar a 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 os detalhes da violação (substitua OBSERVED_VPCSC_DENIAL_UNIQUE_ID pelo ID de negação observado):

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

A violação observada é uma NO_MATCHING_ACCESS_LEVEL, que é uma violação de entrada com detalhes semelhantes a estes:

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 Transferir nome da configuração, 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 Iniciar agora. Caso contrário, a transferência de dados só vai começar após a 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. Ela 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, usamos 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 de excluir os arquivos após a transferência. Vamos reutilizar o mesmo arquivo várias vezes. No entanto, você pode usar vários arquivos e excluir os arquivos de origem após a transferência.
   5. Em Formato de arquivo, selecione CSV.
   6. Em Opções de transferência, em CSV, insira uma vírgula(",") como 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 Start Now como a opção de programação, assim que Save for selecionado, a primeira transferência vai começar.

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) mostram uma entrada de registro da conta de serviço que faz a chamada storage.objects.get (serviceName: "storage.googleapis.com") no objeto 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 é o que grava dados (serviceName: 'bigquery.googleapis.com') do objeto de armazenamento na tabela do BigQuery especificada.

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 ver uma lista de todas as execuções realizadas até o momento.

A execução da transferência de dados precisa ser bem-sucedida, sem violações do VPC Service Controls para a transferência de dados programada e acionada manualmente. Somente a transferência acionada manualmente precisa da regra de entrada para permitir o acesso ao principal, que inicia 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 permite limitar o acesso permitido por atributos específicos de solicitação de API, principalmente:

• Sub-redes 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.
• Princípios: verifica se a solicitação está vindo de uma conta específica.
• Política de dispositivo: verifica se a solicitação está vindo de um dispositivo que atende a requisitos específicos.

Para aplicar a verificação desses atributos com a regra de entrada já configurada, precisamos criar um nível de acesso, que permite os atributos desejados, e 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 as origens (nível de acesso de entrada) e os atributos de identidade como uma condição AND em que ambos precisam corresponder.

1. O usuário [e-mail] tem permissão para acessar o conteúdo quando tenta fazer isso 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 acesso do usuário [e-mail] é bloqueado, mesmo que ele tente 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 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 + em frente a Sub-redes de IP.
5. Na caixa Sub-redes de IP, selecione IP público
   .
   • Como alternativa, você pode selecionar o IP particular para usar o endereço IP interno nos níveis de acesso. No entanto, neste codelab, estamos usando um IP público.
   • Insira um ou mais intervalos IPv4 ou IPv6 formatados como blocos CIDR.

Os registros de violação dos controles de serviço da VPC 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 endereço IP externo.

Adicionar o nível de acesso na regra de entrada

Na regra de entrada, o nível de acesso é referenciado no campo sources, que é obrigatório, conforme documentado na referência da 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 de dados.

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 endereços IP permitidos deve ser bem-sucedido, enquanto o acesso de endereços IP não permitidos deve 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, em seguida, 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 exemplo 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, porque 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 enquanto protege o serviço do Cloud Storage

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

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 Cloud Storage, aguarde a próxima transferência de dados programada ou ative manualmente uma transferência 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, estamos usando 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 mensagem. Dessa vez, a transferência vai falhar com uma violação do VPC Service Controls.

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

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

A violação observada é uma violação de saída de 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. Se a transferência de dados programada for acionada manualmente ou executada, 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 de project-2 para project-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. Enquanto a API BigQuery é protegida pelos controles de serviço da VPC.

Para criar e copiar o conjunto de dados, usaremos 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 em project-1

Antes de copiar o conjunto de dados, o conjunto de dados de destino precisa ser criado. Para criar o conjunto de dados de destino, podemos executar 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 no 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 BigQuery Data Transfer e Cloud Storage.

Iniciar a 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. 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 consulta de registro a seguir. 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"

Corrija todas as violações do BigQuery e inicie 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. As atualizações podem ser acompanhadas no rastreador de problemas público.

Para corrigir a violação de saída, precisamos criar uma regra de saída 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. Dessa vez, o conjunto de dados será copiado sem violar o VPC Service Controls.

7. Limpeza

Embora não haja cobrança extra pelo uso do VPC Service Controls quando o serviço não está em uso, é recomendável limpar a configuração usada neste laboratório. Também é possível excluir a instância de VM e/ou os projetos do Cloud para evitar cobranças. A exclusão do projeto do Cloud 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 a ser excluído 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á definida, neste caso, no nível da pasta.
  • Na página 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 desligar os projetos, siga estas etapas:
  • No console do Google Cloud, acesse a página Configurações de IAM e administrador do projeto que você quer excluir.
  • Na página "Configurações de IAM e administrador", selecione Encerrar.
  • 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 estes 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.
• Executar a transferência de dados do BigQuery de outras fontes com suporte.
• Restringir o acesso do usuário por outros atributos, como local ou política do dispositivo.

Licença

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