Solucionar problemas comunes de los Controles del servicio de VPC con los servicios de Google Cloud

En esta página, se proporcionan soluciones a los problemas que pueden surgir al utilizar un Servicio de Google Cloud que se encuentra dentro de un perímetro de Controles del servicio de VPC.

Problemas de Cloud Build

Usar recursos de Cloud Build dentro de un perímetro de Controles del servicio de VPC algunas limitaciones conocidas. Para obtener más información, consulte Limitaciones de uso Los Controles del servicio de VPC Cloud Build

La cuenta de servicio de Cloud Build no puede acceder a los recursos protegidos

Cloud Build usa la cuenta de servicio de Cloud Build para ejecutar compilaciones por ti. De forma predeterminada, cuando ejecutas una compilación en Cloud Build, esta se ejecuta en un proyecto de usuario fuera de tu proyecto.

Las VMs de trabajador de Cloud Build que generan resultados de compilación están fuera de perímetro de los Controles del servicio de VPC, incluso si tu proyecto perímetro de servicio. Por lo tanto, para que tus compilaciones accedan a recursos dentro del perímetro, debes otorgar a la cuenta de servicio de Cloud Build acceso perímetro de los Controles del servicio de VPC agregándolo al acceso nivel o la regla de entrada.

Para obtener más información, consulta Otorga acceso a la cuenta de servicio de Cloud Build a los Controles del servicio de VPC perímetro de servicio.

Problemas con Cloud Storage

Denegaciones cuando se orienta a un bucket de Cloud Storage de registro inexistente

Si el bucket de registros especificado no existe, los Controles del servicio de VPC acceso con el motivo del incumplimiento RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Puedes revisar el registro de la denegación del acceso con los Controles del servicio de VPC. Identificador único (vpcServiceControlUniqueIdentifier). La siguiente es una registro de muestra con el motivo de la infracción de 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"
    }]}

Si el campo targetResource del objeto egressViolations muestra un objetivo, haz lo siguiente: con projects/0/buckets, esto siempre activa una denegación como projects/0 existe y se considera fuera del perímetro de servicio.

Denegaciones cuando se accede a buckets de Cloud Storage públicos de Google

Un perímetro de servicio no puede contener proyectos de diferentes organizaciones. R el perímetro solo puede contener proyectos de su organización superior. Existen ciertas limitaciones cuando quieres acceder a buckets de Cloud Storage desde proyectos dentro de un perímetro de Controles del servicio de VPC que reside en un para que se adapten a las necesidades de tu organización.

Un ejemplo típico es cuando quieres acceder a Cloud Storage buckets. Dado que tu proyecto y el proyecto de Google que contiene los bucket de destino no están en el mismo perímetro, los Controles del servicio de VPC solicitud con el motivo del incumplimiento RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Para resolver este problema, puedes crear reglas de entrada y salida.

Acceder a un bucket de Cloud Storage de acceso público desde un perímetro

Si intentas acceder a un bucket de Cloud Storage de acceso público desde en un perímetro de servicio, los Controles del servicio de VPC podrían con una infracción de salida.

Para garantizar el acceso exitoso y coherente al objeto según sea necesario, debería aplicar una regla de salida al perímetro de servicio afectado.

Problemas de Security Command Center

En esta sección, se enumeran los problemas que pueden surgir al usar Security Command Center recursos que están dentro de un perímetro de Controles del servicio de VPC.

Security Command Center no puede enviar notificaciones a Pub/Sub

Intentas publicar las notificaciones de Security Command Center en un Pub/Sub dentro de un perímetro de Controles del servicio de VPC Incumplimiento de RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Recomendamos activar Security Command Center a nivel de la organización. Los Controles del servicio de VPC no consideran una organización superior como parte de su proyectos secundarios perímetro de servicio. Para que esto funcione, debes otorgar acceso al perímetro Security Command Center.

Como solución alternativa, puedes realizar cualquiera de las siguientes acciones:

  • Usar un tema de Pub/Sub en un proyecto que no esté en un servicio perímetro de servicio.
  • Quita la API de Pub/Sub del perímetro de servicio hasta que se la configuración de notificaciones.

Para obtener más información sobre cómo habilitar las notificaciones de Security Command Center que se enviados a un tema de Pub/Sub, consulta Habilita las notificaciones de resultados para Pub/Sub.

Security Command Center no puede analizar los recursos de Compute Engine dentro de un perímetro

Security Command Center analiza los recursos de Compute Engine en tus proyectos con el cuenta de servicio por producto y por proyecto (P4SA) service-{project_number}@gcp-sa-computescanning.iam.gserviceaccount.com. En para que Security Command Center pueda acceder a los recursos dentro del perímetro, debes agregar el P4SA a tu nivel de acceso o regla de entrada. De lo contrario, es posible que veas un error NO_MATCHING_ACCESS_LEVEL.

Security Command Center no puede analizar recursos dentro de un perímetro de servicio

Security Health Analytics analiza los recursos de tus proyectos con P4SA (por producto, por cuenta de servicio por proyecto) service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com Para que Security Command Center pueda acceder a los recursos dentro del perímetro de servicio, la cuenta P4SA debe agregarse a su nivel de acceso . De lo contrario, verás el error NO_MATCHING_ACCESS_LEVEL.

Problemas de Google Kubernetes Engine

En esta sección, se enumeran los problemas que pueden surgir al usar Google Kubernetes Engine recursos que están dentro de un perímetro de Controles del servicio de VPC.

El escalador automático no funciona en perímetros con servicios accesibles y servicios restringidos habilitados

El autoscaling.googleapis.com no está integrado con Los Controles del servicio de VPC, por lo que no se pueden agregar a los servicios restringidos ni a los servicios accesibles. No se puede permitir La API de autoscaling.googleapis.com en los servicios accesibles Por lo tanto, el escalador automático de clústeres que existen en un perímetro con servicios accesibles habilitados podrían no funcionar.

No recomendamos el uso de servicios accesibles. Cuando se usa una IP virtual restringida (VIP); haz una excepción para que autoscaling.googleapis.com pase a una VIP privada. en un perímetro con un clúster con ajuste de escala automático.

Problemas con BigQuery

En esta sección, se enumeran los problemas que pueden surgir al usar BigQuery recursos que están dentro de un perímetro de Controles del servicio de VPC.

Las restricciones del perímetro de los Controles del servicio de VPC no se aplican a la exportación de resultados de consultas de BigQuery

Si intentas restringir la exportación de datos protegidos de de BigQuery a Google Drive, Hojas de cálculo de Google o Looker Studio, podrías detectar alguna desviación del comportamiento esperado. Cuando ejecutas una consulta desde el IU de BigQuery, los resultados se almacenan en la memoria local de tu máquina como la caché del navegador. Esto significa que los resultados ahora los Controles del servicio de VPC, por lo que puedes guardar los resultados en un archivo CSV Google Drive

En esta situación, los Controles del servicio de VPC funcionan según lo previsto, ya que el resultado se exporta desde una máquina local que está fuera del perímetro de servicio, pero se elude la restricción general de los datos de BigQuery.

Para solucionar este problema, restringe los permisos de IAM para los usuarios de la siguiente manera: Quita el permiso bigquery.tables.export. Ten en cuenta que esta acción inhabilita todas las opciones de exportación.

Problemas con GKE Enterprise

En esta sección, se enumeran los problemas que podrías encontrar al utilizar Recursos de GKE Enterprise que se encuentran dentro de Controles del servicio de VPC perímetro de servicio.

Para solucionar errores relacionados con el uso de los Controles del servicio de VPC con Cloud Service Mesh, consulta Cómo solucionar problemas de los Controles del servicio de VPC para servicios Malla de servicios de Cloud.

La configuración del controlador de configuración de GKE Enterprise genera un incumplimiento de salida.

Se espera que el proceso de configuración del controlador de configuración de GKE Enterprise fallarán si no hay una configuración de salida que permita acceder containerregistry.googleapis.com por el método google.containers.registry.read en un proyecto fuera del perímetro.

Para resolver este error, crea la siguiente regla de salida:

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

El incumplimiento de salida desaparece después de que agregas la regla al perímetro de servicio.

Problemas con Container Registry

En esta sección, se enumeran los problemas que pueden surgir al usar Container Registry. recursos que están dentro de un perímetro de Controles del servicio de VPC.

Solicitudes a la API de Container Registry bloqueadas por los Controles del servicio de VPC a pesar de que están permitidas en una regla de entrada o salida

Si permitiste el acceso a Container Registry usando reglas de entrada con el El campo identity_type se estableció en ANY_USER_ACCOUNT o ANY_SERVICE_ACCOUNT, acceso está bloqueada por los Controles del servicio de VPC.

Para resolver este problema, actualiza el campo identity_type a ANY_IDENTITY en el una regla de entrada o salida.

Errores de salida de un agente de servicio cuando se copia una imagen de Docker que es propiedad de Artifact Registry a un proyecto en un perímetro

Cuando intentas copiar una imagen que pertenece a Artifact Registry a tu proyecto, dentro de un perímetro de Controles del servicio de VPC, es posible que encuentres errores de salida en los registros del agente de servicio cloud-cicd-artifact-registry-copier@system.gserviceaccount.com. Esta salida por lo general, ocurre cuando la política del perímetro está en modo de ejecución de prueba.

Para resolver este problema, crea una regla de salida que permita que el servicio acceso de agente cloud-cicd-artifact-registry-copier@system.gserviceaccount.com al servicio storage.googleapis.com del proyecto que se menciona en las Registros de errores de los Controles del servicio de VPC.

Problemas con Vertex AI

En esta sección, se enumeran los problemas que podrías encontrar mientras usas Vertex AI. recursos que están dentro de un perímetro de Controles del servicio de VPC.

Solicitudes a la API de notebooks administrados por el usuario bloqueadas por los Controles del servicio de VPC a pesar de que están permitidas en una regla de entrada o salida

Si permitiste el acceso a la API de notebooks administrados por el usuario con una política de entrada y configuraste el identity_type como ANY_USER_ACCOUNT o ANY_SERVICE_ACCOUNT, bloques de Controles del servicio de VPC acceso a la API.

Para resolver este problema, actualiza el campo identity_type a ANY_IDENTITY en el una regla de entrada o salida.

Problemas con Spanner

NO_MATCHING_ACCESS_LEVEL bloquea la copia de seguridad de la base de datos de Spanner incumplimiento de la cuenta de servicio por producto y por proyecto (P4SA) service-PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com

Para resolver este problema, agrega una regla de entrada con el agente de servicio mencionado anteriormente o agregarlo a un nivel de acceso.

¿Qué sigue?