Resolva problemas comuns do VPC Service Controls com os serviços Google Cloud

Esta página oferece soluções para problemas que pode encontrar quando usa um Google Cloud serviço que está dentro de um perímetro dos VPC Service Controls VPC.

Problemas do Cloud Build

A utilização de recursos do Cloud Build num perímetro dos VPC Service Controls tem algumas limitações conhecidas. Para mais informações, consulte o artigo Limitações da utilização do VPC Service Controls com o Cloud Build.

A conta de serviço do Cloud Build está bloqueada e não tem acesso a recursos protegidos

O Cloud Build usa a conta de serviço do Cloud Build para executar compilações em seu nome. Por predefinição, quando executa uma compilação no Cloud Build, a compilação é executada num projeto de inquilino fora do seu projeto.

As VMs de trabalho do Cloud Build que geram resultados da compilação estão fora do perímetro do VPC Service Controls, mesmo que o seu projeto esteja dentro do perímetro. Por conseguinte, para que as suas compilações acedam a recursos dentro do perímetro, tem de conceder à conta de serviço do Cloud Build acesso ao perímetro do VPC Service Controls adicionando-a ao nível de acesso ou à regra de entrada.

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

Problemas do Cloud Storage

Recusas quando segmenta um contentor do Cloud Storage de registo inexistente

Se o contentor de registo especificado não existir, o VPC Service Controls nega o acesso com o motivo de violação RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Pode rever o registo da negação de acesso através do identificador exclusivo (vpcServiceControlUniqueIdentifier) dos VPC Service Controls. Segue-se um registo de exemplo 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, isto aciona sempre uma recusa, uma vez que projects/0 não existe e é considerado fora do perímetro de serviço.

Recusas ao aceder a contentores públicos do Cloud Storage pertencentes à Google

Um perímetro de serviço não pode conter projetos de organizações diferentes. Um perímetro só pode conter projetos da respetiva organização principal. Existem determinadas limitações quando quer aceder a contentores do Cloud Storage a partir de projetos num perímetro do VPC Service Controls que reside numa organização diferente.

Um exemplo típico é quando quer aceder a contentores do Google Cloud Storage pertencentes à Google. Uma vez que o seu projeto e o projeto pertencente à Google que contém o bucket de destino não estão no mesmo perímetro, os VPC Service Controls negam o pedido com o motivo de violação RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Para resolver este problema, pode criar regras de entrada e saída.

Aceder a um contentor do Cloud Storage acessível publicamente a partir de um perímetro

Se estiver a tentar aceder a um contentor do Cloud Storage acessível publicamente a partir de um perímetro de serviço, os VPC Service Controls podem bloquear os seus pedidos ao gerar uma violação de saída.

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

Problemas do Security Command Center

Esta secção apresenta os problemas que pode encontrar ao usar recursos do Security Command Center que estão dentro de um perímetro do VPC Service Controls.

O Security Command Center está impedido de enviar notificações para o Pub/Sub

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

Recomendamos que ative o Security Command Center ao nível da organização. Os VPC Service Controls não consideram uma organização principal como parte do perímetro dos projetos subordinados. Para que isto funcione, tem de conceder acesso ao perímetro ao Security Command Center.

Como solução alternativa, pode fazer uma das seguintes ações:

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

Para mais informações sobre como ativar as notificações do Security Command Center que são enviadas para um tópico do Pub/Sub, consulte o artigo Ativar notificações de resultados para o Pub/Sub.

O Security Command Center está bloqueado para analisar recursos do Compute Engine dentro de um perímetro

O Security Command Center analisa os recursos do Compute Engine nos seus projetos através da conta de serviço por produto e por projeto (P4SA) service-{project_number}@gcp-sa-computescanning.iam.gserviceaccount.com. Para que o Security Command Center possa aceder a recursos dentro do perímetro, tem de adicionar o P4SA ao seu nível de acesso ou regra de entrada. Caso contrário, pode ver um erro NO_MATCHING_ACCESS_LEVEL.

O Security Command Center está bloqueado para analisar recursos dentro de um perímetro de serviço

O Security Health Analytics analisa os recursos nos seus projetos através da 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 aceder a recursos dentro do perímetro, a conta do P4SA tem de ser adicionada ao seu nível de acesso ou regra de entrada. Caso contrário, é apresentado o erro NO_MATCHING_ACCESS_LEVEL.

Problemas do Google Kubernetes Engine

Esta secção enumera os problemas que pode encontrar ao usar recursos do Google Kubernetes Engine que estão dentro de um perímetro dos VPC Service Controls.

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

O autoscaling.googleapis.com não está integrado com os VPC Service Controls e, por isso, 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. Por conseguinte, o redimensionador automático de clusters que existem num perímetro com os serviços acessíveis ativados pode não funcionar.

Sugerimos que não use serviços acessíveis. Quando usar um IP virtual (VIP) restrito, faça uma exceção para que autoscaling.googleapis.com aceda ao VIP privado num perímetro que contenha um cluster com escalabilidade automática.

Problemas do BigQuery

Esta secção apresenta os problemas que pode encontrar ao usar recursos do BigQuery que estão dentro de um perímetro dos VPC Service Controls.

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

Se estiver a tentar restringir a exportação de dados protegidos do BigQuery para o Google Drive, o Google Sheets ou o Looker Studio, pode verificar algum desvio do comportamento esperado. Quando executa uma consulta a partir da IU do BigQuery, os resultados são armazenados na memória local do seu computador, como a cache do navegador. Isto significa que os resultados estão agora fora dos VPC Service Controls, pelo que pode guardar os resultados num ficheiro CSV ou no Google Drive.

Neste cenário, os VPC Service Controls estão a funcionar conforme previsto, uma vez que o resultado está a ser exportado da máquina local, que está fora do perímetro de serviço, mas a restrição geral dos dados do BigQuery está a ser contornada.

Para resolver este problema, restrinja as autorizações da IAM para os utilizadores removendo a autorização bigquery.tables.export. Tenha em atenção que esta ação desativa todas as opções de exportação.

Problemas do GKE Enterprise

Esta secção lista os problemas que pode encontrar ao usar recursos do GKE Enterprise que estão dentro de um perímetro do VPC Service Controls.

Para resolver problemas relacionados com a utilização dos VPC Service Controls com o Cloud Service Mesh, consulte o artigo Resolva problemas dos VPC Service Controls para o Cloud Service Mesh gerido.

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

Espera-se que o processo de configuração do GKE Enterprise Config Controller falhe se não existir uma configuração de saída que permita alcançar containerregistry.googleapis.com com o método google.containers.registry.read num projeto fora do perímetro.

Para resolver este 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 de adicionar a regra ao perímetro violado.

Problemas do Container Registry

Esta secção lista os problemas que pode encontrar ao usar recursos do Container Registry que estão dentro de um perímetro dos VPC Service Controls.

Pedidos da API Container Registry bloqueados pelos VPC Service Controls, apesar de serem permitidos numa regra de entrada ou saída

Se permitiu o acesso ao Container Registry através de regras de entrada com o campo identity_type definido como ANY_USER_ACCOUNT ou ANY_SERVICE_ACCOUNT, o acesso é bloqueado pelos VPC Service Controls.

Para resolver este 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 Docker pertencente ao Artifact Registry para um projeto num perímetro

Quando tenta copiar uma imagem pertencente ao Artifact Registry para o seu projeto que está dentro de um perímetro dos VPC Service Controls, pode encontrar erros de saída nos registos do agente de serviço cloud-cicd-artifact-registry-copier@system.gserviceaccount.com. Este erro de saída ocorre normalmente quando a política de perímetro está no modo de teste.

Pode resolver este problema criando uma regra de saída que permita o acesso do agente de serviço cloud-cicd-artifact-registry-copier@system.gserviceaccount.com ao serviço storage.googleapis.com no projeto mencionado nos registos de erros dos VPC Service Controls.

Problemas do Vertex AI

Esta secção enumera os problemas que pode encontrar ao usar recursos do Vertex AI que estão dentro de um perímetro do VPC Service Controls.

Pedidos da API Notebooks geridos pelo utilizador bloqueados pelos VPC Service Controls, apesar de serem permitidos numa regra de entrada ou saída

Se permitiu o acesso à API Notebooks geridos pelo utilizador através de uma política de entrada e definiu o identity_type como ANY_USER_ACCOUNT ou ANY_SERVICE_ACCOUNT, os VPC Service Controls bloqueiam o acesso à API.

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

Problemas do Spanner

A cópia de segurança da base de dados do Spanner está bloqueada devido à NO_MATCHING_ACCESS_LEVEL violação da conta de serviço por produto e por projeto (P4SA) service-PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com.

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

Problemas do AlloyDB para PostgreSQL

Se o seu cluster do AlloyDB para PostgreSQL estiver protegido por uma CMEK, pode encontrar erros de entrada nos registos 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 este problema, adicione uma regra de entrada com o acesso dos agentes do serviço mencionados acima ao cloudkms.googleapis.com serviço no projeto mencionado nos registos de erros do VPC Service Controls.

O que se segue?