Soluciona problemas habituales de los Controles del servicio de VPC con los servicios de Google Cloud

En esta página, se proporcionan soluciones a los problemas que podrías encontrar cuando uses un servicioGoogle Cloud dentro de un perímetro de los Controles del servicio de VPC.

Problemas de Cloud Build

El uso de recursos de Cloud Build dentro de un perímetro de Controles del servicio de VPC tiene algunas limitaciones conocidas. Para obtener más información, consulta Limitaciones del uso de los Controles del servicio de VPC con 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 en tu nombre. 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 trabajo de Cloud Build que generan resultados de compilación están fuera del perímetro de los Controles del servicio de VPC, incluso si tu proyecto está dentro del perímetro. Por lo tanto, para que tus compilaciones accedan a los recursos dentro del perímetro, debes otorgarle acceso al perímetro de los Controles del servicio de VPC a la cuenta de servicio de Cloud Build. Para ello, agrégala al nivel de acceso o a la regla de entrada.

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

Problemas de Cloud Storage

Rechazos cuando se segmenta para un bucket de Cloud Storage de registro inexistente

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

Puedes revisar el registro del rechazo de acceso con el identificador único (vpcServiceControlUniqueIdentifier) de los Controles del servicio de VPC. El siguiente es un registro de muestra con el motivo del incumplimiento 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 en el objeto egressViolations muestra un objetivo con projects/0/buckets, esto siempre activa un rechazo, ya que projects/0 no existe y se considera fuera del perímetro del servicio.

Rechazos cuando se accede a buckets públicos de Cloud Storage que pertenecen a Google

Un perímetro de servicio no puede contener proyectos de diferentes organizaciones. Un perímetro solo puede contener proyectos de su organización superior. Existen ciertos límites cuando deseas acceder a los buckets de Cloud Storage desde proyectos dentro de un perímetro de Controles del servicio de VPC que reside en una organización diferente.

Un ejemplo típico es cuando quieres acceder a buckets de Cloud Storage de Google. Como tu proyecto y el proyecto de Google que contiene el bucket de destino no están en el mismo perímetro, los Controles del servicio de VPC rechazan la solicitud con el motivo de 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 un perímetro de servicio, es posible que los Controles del servicio de VPC bloqueen tus solicitudes arrojando una infracción de salida.

Para garantizar un acceso coherente y exitoso al objeto según sea necesario, debemos 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 puedes encontrar cuando usas los recursos de Security Command Center que se encuentran dentro de un perímetro de Controles del servicio de VPC.

Security Command Center no puede enviar notificaciones a Pub/Sub

Si intentas publicar notificaciones de Security Command Center en un tema de Pub/Sub dentro de un perímetro de Controles del servicio de VPC, se producirá un error de incumplimiento de RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

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

Como solución alternativa, puedes hacer lo siguiente:

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

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

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

Security Command Center analiza los recursos de Compute Engine en tus proyectos con la cuenta de servicio por producto y por proyecto (P4SA) service-{project_number}@gcp-sa-computescanning.iam.gserviceaccount.com. Para que Security Command Center pueda acceder a los recursos dentro del perímetro, se debe 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 la P4SA (cuenta de servicio por producto y 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, la cuenta de la P4SA debe agregarse a tu nivel de acceso o regla de entrada. 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 puedes encontrar cuando usas recursos de Google Kubernetes Engine que se encuentran 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

autoscaling.googleapis.com no está integrado en los Controles del servicio de VPC, por lo que no se puede agregar a los servicios restringidos ni a los servicios accesibles. No es posible permitir la API de autoscaling.googleapis.com en los servicios accesibles. Por lo tanto, es posible que el escalador de clústeres que existe en un perímetro con servicios accesibles habilitados no funcione.

No recomendamos usar servicios accesibles. Cuando uses una IP virtual restringida (VIP), haz una excepción para que autoscaling.googleapis.com vaya a la VIP privada en un perímetro que contenga un clúster con el ajuste de escala automático.

Problemas de BigQuery

En esta sección, se enumeran los problemas que podrías encontrar cuando uses recursos de BigQuery que se encuentran dentro de un perímetro de Controles del servicio de VPC.

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

Si intentas restringir la exportación de datos protegidos de BigQuery a Google Drive, Hojas de cálculo de Google o Looker Studio, es posible que observes alguna desviación del comportamiento esperado. Cuando ejecutas una consulta desde la 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 están fuera de los Control de servicios de VPC, por lo que puedes guardarlos en un archivo CSV o en Google Drive.

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

Para solucionar este problema, quita el permiso bigquery.tables.export y, así, restringe los permisos de IAM para los usuarios. Ten en cuenta que, de esta manera, se inhabilitan todas las opciones de exportación.

Problemas de GKE Enterprise

En esta sección, se enumeran los problemas que puedes encontrar cuando usas recursos de GKE Enterprise que se encuentran dentro de un perímetro de los Controles del servicio de VPC.

Para solucionar problemas relacionados con el uso de los Controles del servicio de VPC con Cloud Service Mesh, consulta Soluciona problemas de los Controles del servicio de VPC para Cloud Service Mesh administrado.

La configuración del controlador de Config de GKE Enterprise genera una infracción de salida

Se espera que el proceso de configuración del controlador de configuración de GKE Enterprise falle si no hay una configuración de salida que permita llegar a containerregistry.googleapis.com con 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

La infracción de salida desaparece después de agregar la regla al perímetro violado.

Problemas de Container Registry

En esta sección, se enumeran los problemas que puedes encontrar cuando usas recursos de Container Registry que se encuentran 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 se permiten en una regla de entrada o salida

Si permitiste el acceso a Container Registry con reglas de entrada con el campo identity_type configurado en ANY_USER_ACCOUNT o ANY_SERVICE_ACCOUNT, los Controles del servicio de VPC bloquean el acceso.

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

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

Cuando intentas copiar una imagen de Artifact Registry a tu proyecto que se encuentra 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. Este error de salida suele ocurrir cuando la política de perímetro está en modo de ejecución de prueba.

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

Problemas de Vertex AI

En esta sección, se enumeran los problemas que puedes encontrar cuando usas recursos de Vertex AI que se encuentran dentro de un perímetro de Controles del servicio de VPC.

Solicitudes de la API de Notebooks administradas por el usuario bloqueadas por los Controles del servicio de VPC a pesar de que se permiten 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 identity_type como ANY_USER_ACCOUNT o ANY_SERVICE_ACCOUNT, los Controles del servicio de VPC bloquean el acceso a la API.

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

Problemas de Spanner

La copia de seguridad de la base de datos de Spanner está bloqueada por la infracción de NO_MATCHING_ACCESS_LEVEL 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 antes mencionado o agrégalo a un nivel de acceso.

Problemas de AlloyDB para PostgreSQL

Si tu clúster de AlloyDB para PostgreSQL está protegido por una CMEK, es posible que encuentres errores de entrada en los registros de los agentes de servicio service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com y service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com.

Para resolver este problema, agrega una regla de entrada con el acceso de los agentes de servicio mencionados anteriormente al servicio cloudkms.googleapis.com en el proyecto mencionado en los registros de errores de los Controles del servicio de VPC.

¿Qué sigue?