Resolver problemas comuns do VPC Service Controls nos serviços do Google Cloud

Nesta página, você encontra soluções para problemas que podem ser encontrados ao usar um Google Cloud serviço dentro de um perímetro do VPC Service Controls.

Problemas com o Cloud Build

O uso de recursos do Cloud Build em um perímetro do VPC Service Controls tem algumas limitações conhecidas. Para mais informações, consulte Limitações do uso do VPC Service Controls com o Cloud Build.

Conta de serviço do Cloud Build impedida de acessar recursos protegidos

O Cloud Build usa a conta de serviço do Cloud Build para executar builds em seu nome. Por padrão, quando você executa um build no Cloud Build, ele é executado em um projeto de locatário fora do projeto.

As VMs de worker do Cloud Build que geram saídas de build estão fora do perímetro do VPC Service Controls, mesmo que o projeto esteja dentro do perímetro. Portanto, para que seus builds acessem recursos dentro do perímetro, é necessário conceder à conta de serviço do Cloud Build acesso ao perímetro do VPC Service Controls adicionando-o ao nível de acesso ou à regra de entrada.

Para mais informações, consulte Como conceder à conta de serviço do Cloud Build acesso ao perímetro do VPC Service Controls.

Problemas no Cloud Storage

Negações ao segmentar um bucket do Cloud Storage com geração de registros inexistente

Se o bucket de geração de registros especificado não existir, o VPC Service Controls negará acesso com o motivo da violação RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

É possível analisar o registro da negação de acesso usando o identificador exclusivo do VPC Service Controls (vpcServiceControlUniqueIdentifier). Confira a seguir um exemplo de registro com o motivo da violação RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER:

"serviceName": "storage.googleapis.com",
"methodName": "google.storage.buckets.update",
"resourceName": "projects/325183452875",
"metadata": {
  "violationReason": "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER",
  ...
  "egressViolations": [
    {
      "sourceType": "Resource",
      "targetResource": "projects/0/buckets/this-bucket-does-not-exist",
      "source": "projects/325183452875/buckets/bucket-in-same-project",
      "servicePerimeter": "accessPolicies/875573620132/servicePerimeters/prod_perimeter"
    }]}

Se o campo targetResource no objeto egressViolations mostrar um destino com projects/0/buckets, isso sempre acionará uma negação, já que projects/0 não existe e é considerado fora do perímetro de serviço.

Negações ao acessar buckets públicos do Cloud Storage de propriedade do Google

Um perímetro de serviço não pode conter projetos de organizações diferentes. Um perímetro só pode conter projetos da organização principal. Há algumas limitações quando você quer acessar buckets do Cloud Storage de projetos dentro de um perímetro do VPC Service Controls que reside em uma organização diferente.

Um exemplo típico é quando você quer acessar buckets do Cloud Storage de propriedade do Google. Como o projeto e o projeto do Google que contém o bucket de destino não estão no mesmo perímetro, o VPC Service Controls nega a solicitação com o motivo da violação RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Para resolver esse problema, crie regras de entrada e saída.

Como acessar um bucket do Cloud Storage acessível publicamente de dentro de um perímetro

Se você estiver tentando acessar um bucket do Cloud Storage acessível publicamente de dentro de um perímetro de serviço, o VPC Service Controls poderá bloquear suas solicitações gerando uma violação de saída.

Para garantir um acesso consistente e bem-sucedido ao objeto, conforme necessário, aplicamos uma regra de saída ao perímetro de serviço afetado.

Problemas do Security Command Center

Nesta seção, listamos os problemas que podem ser encontrados ao usar os recursos do Security Command Center dentro de um perímetro do VPC Service Controls.

O Security Command Center foi impedido de enviar notificações ao Pub/Sub

Tentar publicar notificações do Security Command Center em um tópico do Pub/Sub dentro de um perímetro do VPC Service Controls falha com uma violação RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Recomendamos ativar o Security Command Center no nível da organização. O VPC Service Controls não considera uma organização principal como parte do perímetro dos projetos secundários. Para que isso funcione, é preciso conceder acesso ao perímetro para o Security Command Center.

Como solução alternativa, você pode executar uma das seguintes ações:

  • Use um tópico do Pub/Sub em um projeto que não esteja em um perímetro de serviço.
  • Remova a API Pub/Sub do perímetro de serviço até que a configuração da notificação seja concluída.

Para mais informações sobre como ativar as notificações do Security Command Center enviadas para um tópico do Pub/Sub, consulte Como ativar notificações de descoberta no Pub/Sub.

O Security Command Center está impedido de verificar recursos do Compute Engine dentro de um perímetro

O Security Command Center verifica os recursos do Compute Engine nos seus projetos usando a conta de serviço por produto e por projeto (P4SA, na sigla em inglês) service-{project_number}@gcp-sa-computescanning.iam.gserviceaccount.com. Para que o Security Command Center possa acessar recursos dentro do perímetro, o P4SA precisa ser adicionado ao nível de acesso ou à regra de entrada. Caso contrário, o erro NO_MATCHING_ACCESS_LEVEL será exibido.

O Security Command Center está impedido de verificar recursos dentro de um perímetro de serviço

O Security Health Analytics verifica os recursos nos projetos usando o P4SA (conta de serviço por produto e por projeto) service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com. Para que o Security Command Center possa acessar recursos dentro do perímetro, a conta do P4SA precisa ser adicionada ao nível de acesso ou à regra de entrada. Caso contrário, o erro NO_MATCHING_ACCESS_LEVEL será exibido.

Problemas no Google Kubernetes Engine

Nesta seção, listamos os problemas que podem ser encontrados ao usar os recursos do Google Kubernetes Engine que estão dentro de um perímetro do VPC Service Controls.

O escalonador automático não está funcionando em perímetros com serviços acessíveis e restritos ativados

O autoscaling.googleapis.com não está integrado ao VPC Service Controls, portanto, não pode ser adicionado aos serviços restritos nem aos serviços acessíveis. Não é possível permitir a API autoscaling.googleapis.com nos serviços acessíveis. Portanto, o escalonador automático de clusters que existem em um perímetro com serviços acessíveis ativados pode não funcionar.

Sugerimos não usar serviços acessíveis. Ao usar o IP virtual restrito (VIP), faça uma exceção para que autoscaling.googleapis.com acesse o VIP particular em um perímetro que contenha um cluster com escalonamento automático.

Problemas com o BigQuery

Nesta seção, listamos os problemas que podem ser encontrados ao usar os recursos do BigQuery que estão dentro de um perímetro do VPC Service Controls.

As restrições do perímetro do VPC Service Controls não se aplicam à exportação de resultados da consulta do BigQuery

Talvez você veja um desvio do comportamento esperado caso esteja tentando restringir a exportação de dados protegidos do BigQuery para o Google Drive, Planilhas Google ou Looker Studio. Quando você executa uma consulta na IU do BigQuery, os resultados são armazenados na memória local da máquina, como o cache do navegador. Isso significa que os resultados agora estão fora do VPC Service Controls e é possível salvá-los em um arquivo CSV ou no Google Drive.

Neste cenário, o VPC Service Controls está funcionando conforme o esperado, porque o resultado está sendo exportado da máquina local que está fora do perímetro de serviço, mas a restrição geral de dados do BigQuery está sendo burlada.

Para resolver esse problema, restrinja as permissões do IAM para os usuários removendo a permissão bigquery.tables.export. Essa ação desativa todas as opções de exportação.

Problemas com o GKE Enterprise

Nesta seção, listamos os problemas que podem ser encontrados ao usar os recursos do GKE Enterprise que estão dentro de um perímetro do VPC Service Controls.

Para resolver erros relacionados ao uso do VPC Service Controls com o Cloud Service Mesh, consulte Resolver problemas do VPC Service Controls para o Cloud Service Mesh gerenciado.

A configuração do GKE Enterprise Config Controller gera uma violação de saída

É esperada um falha no processo de configuração do GKE Enterprise Config Controller quando não há uma configuração de saída que permita acessar containerregistry.googleapis.com com o método google.containers.registry.read em um projeto fora do perímetro.

Para resolver esse erro, crie a seguinte regra de saída:

From:
  Identities:ANY_IDENTITY
To:
  Projects =
    NNNNNNNNNNNN
  Service =
  Service name: containerregistry.googleapis.com
  Service methods:
    containers.registry.read

A violação de saída desaparece depois que você adiciona a regra ao perímetro violado.

Problemas no Container Registry

Nesta seção, listamos os problemas que podem ser encontrados ao usar os recursos do Container Registry que estão dentro de um perímetro do VPC Service Controls.

Solicitações da API Container Registry bloqueadas pelo VPC Service Controls, mesmo sendo permitidas em uma regra de entrada ou saída

Se você permitiu o acesso ao Container Registry usando regras de entrada com o campo identity_type definido como ANY_USER_ACCOUNT ou ANY_SERVICE_ACCOUNT, o acesso será bloqueado pelo VPC Service Controls.

Para resolver esse problema, atualize o campo identity_type para ANY_IDENTITY na regra de entrada ou saída.

Erros de saída de um agente de serviço ao copiar uma imagem do Docker de propriedade do Artifact Registry para um projeto em um perímetro

Ao tentar copiar uma imagem de propriedade do Artifact Registry para o projeto que está em um perímetro do VPC Service Controls, talvez você encontre erros de saída nos registros do agente de serviço cloud-cicd-artifact-registry-copier@system.gserviceaccount.com. Esse erro de saída geralmente ocorre quando a política de perímetro está no modo de teste.

Para resolver esse problema, crie uma regra de saída que permita que o agente de serviço cloud-cicd-artifact-registry-copier@system.gserviceaccount.com acesse o serviço storage.googleapis.com no projeto mencionado nos registros de erro do VPC Service Controls.

Problemas com a Vertex AI

Nesta seção, listamos os problemas que podem ser encontrados ao usar os recursos da Vertex AI que estão dentro de um perímetro do VPC Service Controls.

Solicitações de API de notebooks gerenciados pelo usuário bloqueadas pelo VPC Service Controls, apesar de serem permitidas em uma regra de entrada ou saída

Se você permitiu o acesso à API de notebooks gerenciados pelo usuário usando uma política de entrada e definiu identity_type como ANY_USER_ACCOUNT ou ANY_SERVICE_ACCOUNT, o VPC Service Controls bloqueia o acesso à API.

Para resolver esse problema, atualize o campo identity_type para ANY_IDENTITY na regra de entrada ou saída.

Problemas com o Spanner

O backup do banco de dados do Spanner está bloqueado pela violação NO_MATCHING_ACCESS_LEVEL da conta de serviço por produto e por projeto (P4SA, na sigla em inglês) service-PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com.

Para resolver esse problema, adicione uma regra de entrada com o agente de serviço mencionado acima ou a um nível de acesso.

Problemas do AlloyDB para PostgreSQL

Se o cluster do AlloyDB para PostgreSQL estiver protegido por uma CMEK, você poderá encontrar erros de entrada nos registros dos agentes de serviço service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com e service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com.

Para resolver esse problema, adicione uma regra de entrada com o acesso dos agentes de serviço mencionados acima ao serviço cloudkms.googleapis.com no projeto mencionado nos registros de erro do VPC Service Controls.

A seguir