Nesta página, você verá soluções para problemas que podem ser encontrados ao usar um serviço do Google Cloud dentro de um perímetro do VPC Service Controls.
Problemas do 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.
Resolva esse problema criando uma regra de saída que permita ao serviço
acesso de cloud-cicd-artifact-registry-copier@system.gserviceaccount.com
do agente
ao serviço storage.googleapis.com
no projeto mencionado no
Registros de erros 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 do Spanner
O backup do banco de dados do Spanner foi bloqueado pelo NO_MATCHING_ACCESS_LEVEL
violação 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.
A seguir
- Saiba mais sobre as limitações conhecidas do uso do VPC Service Controls com vários serviços do Google Cloud.
- Saiba como o identificador exclusivo do VPC Service Controls ajuda a resolver problemas relacionados aos perímetros de serviço.