En esta página, se enumeran varios problemas que pueden surgir cuando configuras los Controles del servicio de VPC.
Comportamiento inesperado de la política con alcance
Es posible que notes algunas infracciones inesperadas de los Controles del servicio de VPC que la política con permiso debe permitirlo. Es un problema conocido que, si no se cuenta de acceso a nivel de organización, es posible que experimentes problemas con tus políticas de acceso con permiso.
Para solucionar este problema, crea una política de acceso a nivel de la organización con el siguiente comando:
gcloud access-context-manager policies create --organization <var>ORGANIZATION_ID</var> --title <var>POLICY_TITLE</var>
Reemplaza lo siguiente:
- ORGANIZATION_ID: El ID de la organización.
- POLICY_TITLE: Es un título legible para tu política de acceso.
Para obtener más información, consulta Crea una política de acceso.
VPC compartida
Cuando usas una VPC compartida, un perímetro de servicio que incluye proyectos que pertenecen a una red de VPC compartida también debe incluir el proyecto que aloja la red. Cuando los proyectos que pertenecen a una red de VPC compartida no están en el mismo perímetro que el proyecto host, es posible que los servicios no funcionen como se espera o que se bloqueen por completo.
Asegúrate de que el host de la red de VPC compartida esté en el mismo perímetro de servicio que los proyectos conectados a la red.
No se pudo agregar una red de VPC
El siguiente error puede ocurrir cuando intentas agregar una red de VPC a un perímetro de servicio:
ERROR: (gcloud.access-context-manager.perimeters.update) PERMISSION_DENIED: Permission 'compute.networks.get' denied on resource '//compute.googleapis.com/projects/PROJECT_NAME/global/networks/VPC_NETWORK_NAME' (or it may not exist)
Este error se produce por uno de los siguientes motivos:
- La red de VPC no existe.
- La red de VPC existe, pero no tiene una subred.
- El llamador no tiene el permiso necesario.
Para resolver este problema, realiza los siguientes pasos:
Verifica si la red de VPC especificada en el mensaje de error existe al ver el redes en tu en un proyecto final.
Antes de verificar la red de VPC, asegúrate de que el La API de Compute Engine debe estar habilitada en el proyecto asociado con la llamada a la API. siguiendo estos pasos:
En la consola de Google Cloud, ve a la página API y servicios.
Ir hasta APIs y ServiciosEn la pestaña APIs & de Google Cloud, verifica si la API de Compute Engine está en la lista.
Si falta la API de Compute Engine, habilítala.
Habilite el API
Verifica si existe al menos una subred en la red de VPC. Para ello, haz lo siguiente: visualización de subredes. Si no hay subredes, agrega una subred a la de VPC de Google Cloud.
Comprueba si el emisor tiene el siguiente permiso en el proyecto host de la Red de VPC:
compute.networks.get
. Este permiso te permite visualizar redes de VPC en un proyecto.Pregunta al administrador de la organización propietaria del proyecto host de a la red de VPC para otorgarle al emisor una IAM con el permiso
compute.networks.get
en el proyecto host. Para ejemplo, el rol Visualizador de red de Compute.Para obtener más información sobre cómo otorgar roles, consulta Administra acceso.
Asegúrate de leer el limitaciones asociada con el uso de redes de VPC en perímetros de servicio.
Solicitudes entre perímetros
Por lo general, los niveles de acceso se usan con el fin de permitir las solicitudes por fuera de un perímetro de servicio para recursos protegidos dentro de un perímetro.
Sin embargo, se rechaza una solicitud de un proyecto que está en el perímetro de un recurso protegido en otro perímetro, incluso si un nivel de acceso suele permitir la solicitud.
Por ejemplo, supongamos que el Proyecto A en el Perímetro 1 solicita un recurso del Proyecto B. El recurso en el Proyecto B está protegido por el Perímetro 2. Dado que el Proyecto A está en un perímetro, incluso si un nivel de acceso para el Perímetro 2 permitiría la solicitud del recurso protegido con normalidad, la solicitud se rechaza.
Usa uno de los siguientes enfoques para facilitar las solicitudes entre perímetros:
Usa la política de salida y de entrada. Para permitir solicitudes de otro perímetro a recursos protegidos en y el otro debe usar una política de salida y configurar una de entrada.
Usa puentes perimetrales. Los puentes permiten que dos o más proyectos en diferentes perímetros realicen solicitudes a los servicios de esos proyectos. Estas solicitudes están permitidas incluso si servicios están protegidos por los perímetros respectivos.
Asegúrate de que los perímetros no protejan al servicio de solicitud ni al recurso de destino. En esta situación, la operación tiene éxito porque los servicios no están protegidos.
La dirección de correo electrónico no es válida o no existe
Cuando actualices un perímetro que contiene una principal borrada, es posible que encuentres
el mensaje de error The email address is invalid or non-existent
.
Para solucionar este problema, puedes realizar una de las siguientes tareas:
Quita la dirección de correo electrónico no válida del perímetro, que incluye lo siguiente: y las reglas de entrada y salida.
Puedes usar la consola de Google Cloud o Google Cloud CLI.
Realizar una operación masiva (Solo en Google Cloud CLI) Si la dirección de correo electrónico está en ambos, la ejecución de prueba y el perímetro de aplicación forzosa.
- Obtén todos tus perímetros:
gcloud access-context-manager perimeters list --format=list \ --policy=<POLICY_NAME> > my-perimeters.yaml
Quita la dirección de correo electrónico no válida del archivo
my-perimeters.yaml
y guardarlo comomy-perimeters-updated.yaml
.Reemplaza todos tus perímetros:
gcloud access-context-manager perimeters replace-all --format=list \ --source-file=my-perimeters-updated.yaml \ --policy=<POLICY_NAME>
Incumplimientos de las reglas de entrada y salida
El registro de auditoría contiene información sobre los incumplimientos de reglas de entrada y salida que te ayudan a comprender los incumplimientos de perímetros.
Incumplimiento de la regla de entrada
Un incumplimiento de la regla de entrada indica que un cliente de API fuera del perímetro intentó acceder a un recurso dentro del perímetro. El perímetro de servicio rechaza la solicitud, ya que no hay reglas de entrada ni niveles de acceso que coincidan.
Un incumplimiento de la regla de entrada en el registro de auditoría contiene los siguientes detalles:
- El nombre del perímetro en el que se produjo el incumplimiento de la regla de entrada.
- El recurso dentro del perímetro al que el cliente de la API fuera del perímetro intentó acceder.
En el siguiente ejemplo de incumplimiento de la regla de entrada, un cliente de API fuera del perímetro intenta acceder al bucket de Cloud Storage prod-protected-storage-bucket
dentro del perímetro prod-perimeter
.
ingressViolations: [
0: {
targetResource: "projects/1234/buckets/prod-protected-storage-bucket"
servicePerimeter: "accessPolicies/123456789/servicePerimeters/prod-perimeter"
}
]
Incumplimiento de la regla de salida
Un incumplimiento de la regla de salida en el registro de auditoría indica uno de los siguientes eventos:
- Un cliente de la API dentro del perímetro intentó acceder a un recurso fuera del perímetro.
- Una solicitud a la API que involucra un recurso dentro del perímetro y un recurso fuera del perímetro. Por ejemplo, un cliente de Cloud Storage que llama a un comando de copia en el que un bucket está dentro del perímetro y el otro está fuera del perímetro.
El perímetro de servicio rechaza la solicitud porque no hay reglas de salida que coincidan. Un incumplimiento de la regla de salida en el registro de auditoría incluye los siguientes detalles:
- El tipo de fuente, como red o recurso.
- La fuente, que es un recurso o una red, cuyo perímetro encontró una infracción de salida.
- El perímetro que encontró una infracción de salida.
- El recurso de destino fuera del perímetro al que la solicitud intentó acceder.
En el siguiente ejemplo de incumplimiento de la regla de salida, la solicitud a la API incluye un recurso de projects/5678, que está dentro del perímetro prod-perimeter
, y un objeto del bucket de Cloud Storage external-storage-bucket
, que está fuera del perímetro.
egressViolations: [
0: {
sourceType: "Resource"
source: "projects/5678"
targetResource: "projects/4321/buckets/external-storage-bucket/objects/corp-resources.json"
servicePerimeter: "accessPolicies/123456789/servicePerimeters/prod-perimeter"
}
]
Solicitudes de depuración bloqueadas por los Controles del servicio de VPC
El registro de auditoría de los Controles del servicio de VPC es la herramienta principal para depurar una solicitud bloqueada por los Controles del servicio de VPC.
Cuando el acceso se haya bloqueado de forma inesperada, consulta los registros de auditoría en el proyecto protegido por el perímetro de servicio. Estos registros contienen datos importantes sobre los recursos solicitados y el motivo del rechazo de la solicitud. Para obtener información sobre los registros de auditoría, consulta Diagnostica problemas con el Solucionador de problemas.
En las siguientes secciones, se enumeran los valores violationReason
que puedes encontrar.
cuando uses los Controles del servicio de VPC.
NETWORK_NOT_IN_SAME_SERVICE_PERIMETER
El motivo de este problema puede ser uno de los siguientes:
- Un cliente de una red de VPC dentro de un perímetro de servicio intenta acceder a un proyecto que no está en el mismo perímetro. Esta solicitud genera un incumplimiento de salida. Crea una regla de salida para solucionar este problema.
- Un cliente de una red de VPC que está fuera del perímetro de servicio intenta acceder un proyecto que está protegido por el perímetro de servicio. Esta solicitud da como resultado un incumplimiento de entrada. Crea una regla de entrada para solucionar este problema.
El cliente puede enviar la solicitud desde una VM de Compute Engine o de Google Kubernetes Engine, o de una red local a través de Cloud Interconnect o de una VPN configurada con una red de VPC.
En el siguiente diagrama, se muestra que se produce una infracción de salida cuando un cliente en una VPC dentro de un perímetro de servicio intenta acceder a un proyecto fuera del perímetro:
Este es un ejemplo de una infracción de salida:
egressViolations: [
{
servicePerimeter: "accessPolicies/<POLICY_NAME>/servicePerimeters/<PERIMETER_NAME>"
source: "projects/<NETWORK_PROJECT_NUMBER>"
sourceType: "Network"
targetResource: "projects/<RESOURCE_PROJECT_NUMBER>"
}
]
Aquí:
<POLICY_NAME>
es el nombre numérico de tu política de acceso.<PERIMETER_NAME>
es el nombre del perímetro de servicio.<NETWORK_PROJECT_NUMBER>
es el número del proyecto de Google Cloud que contiene tu red de VPC.<RESOURCE_PROJECT_NUMBER>
es el número del proyecto de Google Cloud que contiene el recurso.
En el siguiente diagrama se muestra que una infracción de entrada se produce cuando un cliente fuera el perímetro intenta acceder a un proyecto que está dentro de él:
A continuación, se muestra un ejemplo de una infracción de entrada:
ingressViolations: [
{
targetResource: "projects/<RESOURCE_PROJECT_NUMBER>",
source: "projects/<NETWORK_PROJECT_NUMBER>"
servicePerimeter: "accessPolicies/<POLICY_NAME>/servicePerimeters/<PERIMETER_NAME>"
}
]
Aquí:
<RESOURCE_PROJECT_NUMBER>
es el número del proyecto de Google Cloud que contiene el recurso.<NETWORK_PROJECT_NUMBER>
es el número del proyecto de Google Cloud que contiene tu red de VPC.<POLICY_NAME>
es el nombre numérico de tu política de acceso.<PERIMETER_NAME>
es el nombre del perímetro de servicio.
Solución
Para resolver este error, crea una entrada o salida regla general de su perímetro de servicio.
RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER
Este problema ocurre cuando una sola solicitud accede a varios recursos, pero recursos no están en el mismo perímetro de servicio. Este problema ocurre independientemente de dónde está ubicado el cliente y si tiene acceso a los recursos.
En el siguiente diagrama, se muestra a un cliente que accede a los recursos de un proyecto fuera del y desde un proyecto dentro del perímetro de servicio:
En el siguiente diagrama, se muestra a un cliente que accede a recursos desde proyectos que tienen en dos perímetros de servicio diferentes, pero estos no se comunican entre sí:
Este es un ejemplo de una infracción de salida:
egressViolations: [
{
servicePerimeter: "accessPolicies/<POLICY_NAME>/servicePerimeters/<PERIMETER_NAME>"
source: "projects/<RESOURCE_PROJECT_INSIDE_THIS_PERIMETER>"
sourceType: "Resource"
targetResource: "projects/<RESOURCE_PROJECT_OUTSIDE_THIS-PERIMETER>"
}
]
Aquí:
<POLICY_NAME>
es el nombre numérico de tu política de acceso.<PERIMETER_NAME>
es el nombre del perímetro de servicio.<RESOURCE_PROJECT_INSIDE_THIS_PERIMETER>
es el número del proyecto de Google Cloud que está dentro del perímetro.<RESOURCE_PROJECT_OUTSIDE_THIS_PERIMETER>
es el número del proyecto de Google Cloud que está fuera del perímetro.
Solución
A fin de resolver este problema, crea una regla de salida para tu perímetro.
NO_MATCHING_ACCESS_LEVEL
Este problema ocurre cuando la dirección IP, los requisitos del dispositivo o la identidad del usuario
no coincide con ninguna regla de entrada ni nivel de acceso asignado al perímetro. Esta
significa que un cliente que no forma parte de la red de Google Cloud intenta
acceder a los recursos de red de Google Cloud desde fuera del perímetro. Para
Por ejemplo, la dirección IP correspondiente al campo callerIp
de la auditoría
registro no coincide con ninguno de los rangos de CIDR definidos en los niveles de acceso del
en ese perímetro de servicio.
Si falta la dirección IP del emisor o aparece como una dirección IP interna, este incumplimiento podría deberse a un servicio de Google Cloud que no está integrados en los Controles del servicio de VPC. La razón podría ser que el El servicio de Google Cloud intenta acceder a un servicio protegido y falla, ya que lo esperado.
Para solucionar este problema, recomendamos crear una regla de entrada en lugar de una regla de acceso porque una regla de entrada proporciona control de acceso detallado.
En el siguiente diagrama, se muestra a un cliente que intenta acceder a los recursos desde fuera del perímetro:
A continuación, se muestra un ejemplo de una infracción de entrada:
authenticationInfo: {
principalEmail: "EMAIL"
}
requestMetadata: {
callerIp: "<PUBLIC_IP_ADDRESS>"
deviceState: "Cross Organization"
}
ingressViolations: [
{
targetResource: "projects/<RESOURCE_PROJECT_NUMBER>",
servicePerimeter: "accessPolicies/<POLICY_NAME>/servicePerimeters/<PERIMETER-NAME>"
}
]
Aquí:
<EMAIL>
es la dirección de correo electrónico de la cuenta de servicio o del usuario autenticado.Si usas un servicio de Google Cloud que los Controles del servicio de VPC no de Google Workspace, direcciones de correo electrónico que que pertenecen al dominio
google.com
se ocultan y se reemplazan porgoogle-internal
google-internal
se refiere a las identidades internas de Google.<PUBLIC_IP_ADDRESS>
es la dirección IP de la llamador. Para los emisores desde Internet, esta será la dirección IPv4 o IPv6 pública web.<RESOURCE_PROJECT_NUMBER>
es el número del proyecto de Google Cloud que contiene el recurso.<POLICY_NAME>
es el nombre numérico de tu política de acceso.<PERIMETER_NAME>
es el nombre del perímetro de servicio.
Ten en cuenta que, en este caso, metadata.accessLevels
podría seguir presente, ya que
es posible que estos niveles de acceso no se especifiquen en el perímetro con infracción.
SERVICE_NOT_ALLOWED_FROM_VPC
Este problema ocurre cuando un cliente intenta acceder a los recursos de Google Cloud desde una red de VPC. El cliente puede enviar la solicitud desde una VM de Compute Engine o de Google Kubernetes Engine o desde una red local a través de Cloud Interconnect o una VPN configurada con una red de VPC.
Para solucionar este problema, asegúrate de que la VPC accesible services del perímetro de servicio.
Situaciones de ejemplo
Los siguientes ejemplos abarcan situaciones que podrías encontrarte cuando uses los Controles del servicio de VPC.
- Acceso a Cloud Storage desde las instalaciones locales
- Acceso de BigQuery desde una VM fuera del proyecto
- Consulta entre proyectos de BigQuery
- Mueve el archivo de Cloud Storage dentro del perímetro
- Mueve el archivo de Cloud Storage fuera del perímetro
- Copia de un conjunto de datos de BigQuery desde una VM dentro del perímetro
- Lectura de trabajo de Dataproc desde el proyecto
- Servicio no compatible con la VIP restringida
- Exportación de registros al proyecto fuera del perímetro
- Extracción de BigQuery a Cloud Storage
Acceso a Cloud Storage desde las instalaciones locales
En este ejemplo, los Controles del servicio de VPC bloquean una solicitud de una estación de trabajo de empleado (identificada por callerIp
) a un bucket de Cloud Storage en el proyecto corp-storage
.
La solicitud genera el siguiente registro de auditoría:
{
insertId: "222lvajc6f7"
logName: "projects/corp-storage/logs/cloudaudit.googleapis.com%2Fpolicy"
protoPayload: {
@type: "type.googleapis.com/google.cloud.audit.AuditLog"
authenticationInfo: {
principalEmail: "someone@google.com"
}
metadata: {
@type: "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
resourceNames: [
0: "projects/_"
]
violationReason: "NO_MATCHING_ACCESS_LEVEL"
}
methodName: "google.storage.NoBillingOk"
requestMetadata: {
callerIp: "b1d5:d26d:5b17:43fe:d358:586b:db59:9617"
destinationAttributes: {
}
requestAttributes: {
}
}
resourceName: "projects/690885588241"
serviceName: "storage.googleapis.com"
status: {
code: 7
details: [
0: {
@type: "type.googleapis.com/google.rpc.PreconditionFailure"
violations: [
0: {
type: "VPC_SERVICE_CONTROLS"
}
]
}
]
message: "Request is prohibited by organization's policy"
}
}
receiveTimestamp: "2018-11-27T21:40:43.823209571Z"
resource: {
labels: {
method: "google.storage.NoBillingOk"
project_id: "corp-storage"
service: "storage.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"
timestamp: "2018-11-27T21:40:42.973784140Z"
}
El proyecto corp-storage
se incluye en un perímetro de servicio. La estación de trabajo de empleado no forma parte de ninguna red dentro de ese perímetro. Debido a que la estación de trabajo de empleado está fuera del perímetro, la solicitud se bloquea.
Acceso de BigQuery desde una VM fuera del proyecto
En este ejemplo, una VM que pertenece al proyecto 458854174376
(data-collector
) intenta ejecutar una consulta de BigQuery en un conjunto de datos del proyecto 798816221974
(corp-resources-protected
) y se ve rechazada.
La VM usa la siguiente consulta:
bq --project=corp-resources-protected query 'select count(*) from babynames.yob2000'
La consulta muestra el siguiente resultado:
BigQuery error in query operation: VPC Service Controls: Request is
prohibited by organization's policy. Operation ID:
33643962-6a0f-4091-9283-bcdf7e9271f0
Se genera el siguiente registro de auditoría:
{
insertId: "1ei551d2pdq"
logName: "projects/corp-resources-protected/logs/cloudaudit.googleapis.com%2Fpolicy"
protoPayload: {
@type: "type.googleapis.com/google.cloud.audit.AuditLog"
authenticationInfo: {
principalEmail: "714877721106-compute@example.gserviceaccount.com"
}
metadata: {
@type: "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
resourceNames: [
0: "projects/1004338142803"
]
violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"
}
methodName: "bigquery.googleapis.com/bigquery.jobs.create"
requestMetadata: {
callerIp: "10.105.0.2"
callerNetwork: "//compute.googleapis.com/projects/ameet-dataflow/global/networks/__unknown__"
destinationAttributes: {
}
requestAttributes: {
}
}
resourceName: "projects/1004338142803"
serviceName: "bigquery.googleapis.com"
status: {
code: 7
details: [
0: {
@type: "type.googleapis.com/google.rpc.PreconditionFailure"
violations: [
0: {
type: "VPC_SERVICE_CONTROLS"
}
]
}
]
message: "Request is prohibited by organization's policy"
}
}
receiveTimestamp: "2018-11-28T23:06:13.579882505Z"
resource: {
labels: {
method: "bigquery.googleapis.com/bigquery.jobs.create"
project_id: "corp-resources-protected"
service: "bigquery.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"
timestamp: "2018-11-28T23:06:12.799656975Z"
}
En este ejemplo, el violationReason
es NETWORK_NOT_IN_SAME_SERVICE_PERIMETER
. callerNetwork
se incluye, además de callerIp
. La dirección IP es privada, y la red se proporciona para que no haya ambigüedad. Aquí se detallan los recursos relevantes en dos lugares: VpcServiceControlAuditMetadata.resourceNames
y requestMetadata.callerNetwork
(el proyecto que posee la red).
El problema es que el proyecto corp-resources-protected
está dentro de un perímetro de servicio, mientras que data-collector
, el proyecto que incluye la red a la que pertenece la VM, no. En este caso, se rechazó el acceso como se esperaba.
Consulta entre proyectos de BigQuery
En este ejemplo, una VM que pertenece al proyecto perimeter-network
intenta consultar las instancias de BigQuery de dos proyectos diferentes: corp-resources-protected
, que se encuentra en el mismo perímetro de servicio que perimeter-network
, y corp-resources-public
, que no se encuentra en el mismo perímetro.
La VM usa el siguiente comando:
bq query --use_legacy_sql=false \
'select count(priv.name),count(pub.name) from \
`corp-resources-protected.babynames.yob2000` as priv, \
`corp-resources-public.babynames.yob2000` as pub'
La consulta muestra el siguiente resultado:
BigQuery error in query operation: Error processing job
'example:bqjob_r211e6f6eec928ffb_000001675c996aa8_1': VPC Service Controls:
Request is prohibited by organization's policy. Operation ID:
dc4fc177-4850-4fc5-b2e7-8c33f302149a
Se genera el siguiente registro de auditoría:
{
insertId: "17kg4exd24ag"
logName: "projects/perimeter-network/logs/cloudaudit.googleapis.com%2Fpolicy"
protoPayload: {
@type: "type.googleapis.com/google.cloud.audit.AuditLog"
authenticationInfo: {
}
metadata: {
@type: "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
resourceNames: [
0: "projects/117961063178"
1: "projects/690885588241"
]
violationReason: "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
}
methodName: "bigquery.googleapis.com/bigquery.tables.getData"
requestMetadata: {
callerIp: "130.211.225.66"
callerNetwork: "//compute.googleapis.com/projects/perimeter-network/global/networks/__unknown__"
destinationAttributes: {
}
requestAttributes: {
}
}
resourceName: "projects/927005422713"
serviceName: "bigquery.googleapis.com"
status: {
code: 7
details: [
0: {
@type: "type.googleapis.com/google.rpc.PreconditionFailure"
violations: [
0: {
type: "VPC_SERVICE_CONTROLS"
}
]
}
]
message: "Request is prohibited by organization's policy"
}
}
receiveTimestamp: "2018-11-28T20:48:51.384237810Z"
resource: {
labels: {
method: "bigquery.googleapis.com/bigquery.tables.getData"
project_id: "perimeter-network"
service: "bigquery.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"
timestamp: "2018-11-28T20:48:50.561884949Z"
}
Si analizamos callerNetwork
y VpcServiceControlAuditMetadata.resourceNames
, podemos ver tres proyectos: perimeter-network
, 117961063178
(corp-resources-public
) y 690885588241
(corp-resources-protected
). Recuerda que corp-resources-public
no está en el mismo perímetro de servicio que perimeter-network
y corp-resources-protected
.
El violationReason
, RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER
indica que algún recurso de la solicitud está fuera de un perímetro que se aplica a la solicitud. En este caso, ese recurso es corp-resources-public
.
Mueve el archivo de Cloud Storage dentro del perímetro
En este ejemplo, en una VM del proyecto perimeter-network
, se usa un comando para transferir un archivo de un depósito de Cloud Storage, ubicado en el proyecto corp-resources-protected
, a otro depósito, ubicado en el proyecto corp-resources-public
.
La VM usa el siguiente comando:
gcloud storage mv gs://corp-resources-private-1/yob2000.txt gs://corp-resources-public-1/babynames/
El comando muestra el siguiente resultado:
Copying gs://corp-resources-private-1/yob2000.txt [Content-Type=text/plain]...
AccessDeniedException: 403 Request violates VPC Service Controls.
Se genera el siguiente registro de auditoría:
{
insertId: "1xxnssmd2hqo"
logName: "projects/perimeter-network/logs/cloudaudit.googleapis.com%2Fpolicy"
protoPayload: {
@type: "type.googleapis.com/google.cloud.audit.AuditLog"
authenticationInfo: {
principalEmail: "storage-accessing@example.iam.gserviceaccount.com"
}
metadata: {
@type: "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
resourceNames: [
0: "projects/_/buckets/corp-resources-public-1"
]
violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"
}
methodName: "google.storage.BillingRequiredRead"
requestMetadata: {
callerIp: "130.211.225.66"
callerNetwork: "//compute.googleapis.com/projects/perimeter-network/global/networks/__unknown__"
destinationAttributes: {
}
requestAttributes: {
}
}
resourceName: "projects/927005422713"
serviceName: "storage.googleapis.com"
status: {…}
}
receiveTimestamp: "2018-11-28T00:45:31.531623485Z"
resource: {
labels: {
method: "google.storage.BillingRequiredRead"
project_id: "perimeter-network"
service: "storage.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"
timestamp: "2018-11-28T00:45:31.351140381Z"
}
En este caso, el registro es menos claro porque el método enumerado es BillingRequiredRead
, y la acción que se realiza es move
. Esta es una limitación de la funcionalidad del registro de auditoría actual de los Controles del servicio de VPC.
Aunque el motivo es menos claro, este registro de auditoría indica que algún recurso de la solicitud está fuera de un perímetro que se aplica a la solicitud. En este caso, ese recurso es corp-resources-public
.
Mueve el archivo de Cloud Storage fuera del perímetro
En este ejemplo, en una VM del proyecto public-network
, se usa un comando para transferir un archivo de un depósito de Cloud Storage, ubicado en el proyecto corp-resources-protected
, a otro depósito, ubicado en el proyecto corp-resources-public
.
El proyecto corp-resources-protected
está protegido por un perímetro de servicio. El
Los proyectos public-network
y corp-resources-public
existen fuera de
perímetro de servicio.
La VM usa el siguiente comando:
gcloud storage mv gs://corp-resources-private-1/yob2000.txt gs://corp-resources-public-1/babynames/
El comando muestra el siguiente resultado:
Copying gs://corp-resources-private-1/yob2000.txt [Content-Type=text/plain]...
AccessDeniedException: 403 Request violates VPC Service Controls.
Se genera el siguiente registro de auditoría:
{
insertId: "10moqhsch9v"
logName: "projects/corp-resources-private/logs/cloudaudit.googleapis.com%2Fpolicy"
protoPayload: {
@type: "type.googleapis.com/google.cloud.audit.AuditLog"
authenticationInfo: {
principalEmail: "user@example.biz"
}
metadata: {
@type: "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
resourceNames: [
0: "projects/_/buckets/corp-resources-private-1/objects/yob2000.txt"
1: "projects/_/buckets/corp-resources-public-1/objects/out.txt"
]
violationReason: "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
}
methodName: "google.storage.Write"
requestMetadata: {
callerIp: "2620:15c:2c4:203:63d6:5eb8:418d:c034"
destinationAttributes: {
}
requestAttributes: {
}
}
resourceName: "projects/1004338142803"
serviceName: "storage.googleapis.com"
status: {
code: 7
details: [
0: {
@type: "type.googleapis.com/google.rpc.PreconditionFailure"
violations: [
0: {
type: "VPC_SERVICE_CONTROLS"
}
]
}
]
message: "Request is prohibited by organization's policy"
}
}
receiveTimestamp: "2018-11-30T16:34:46.948010626Z"
resource: {
labels: {
method: "google.storage.Write"
project_id: "corp-resources-private"
service: "storage.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"
timestamp: "2018-11-30T16:34:46.898098978Z"
}
En este ejemplo, el registro de auditoría indica que no se pueden copiar datos en el límite de un perímetro de servicio (ambos recursos están en el registro de auditoría).
Recuerda que la solicitud se origina fuera del perímetro (la VM en public-network
) y que uno de los buckets está fuera del perímetro (corp-resources-public-1
).
Desde afuera del perímetro, se puede escribir en el bucket corp-resources-public-1
, por lo que se aprueba la verificación que falló en el ejemplo anterior. Sin embargo, la verificación posterior para copiar los datos falla.
En este ejemplo se muestra cómo, en ciertas ocasiones, una sola operación del usuario da como resultado varias operaciones internas que deben pasar la aplicación de los Controles del servicio de VPC.
Copia de un conjunto de datos de BigQuery desde una VM dentro del perímetro
En este ejemplo, una VM del proyecto 927005422713
(perimeter-network
) intenta copiar un conjunto de datos de BigQuery del proyecto corp-resources-private
a corp-resources-public
(117961063178
). perimeter-network
y corp-resources-private
comparten un perímetro, mientras que corp-resources-public
está fuera del perímetro.
La VM usa el siguiente comando:
bq cp corp-resources-private:babynames.yob2000 \
corp-resources-public:babynames.yob2000
El comando muestra el siguiente resultado:
BigQuery error in cp operation: VPC Service Controls: Request is prohibited by
organization's policy. Operation ID: c00dbc44-460f-4bd0-9d09-cda98ac800f9
Se genera el siguiente registro de auditoría:
{
insertId: "146o5fd2hbp"
logName: "projects/perimeter-network/logs/cloudaudit.googleapis.com%2Fpolicy"
protoPayload: {
@type: "type.googleapis.com/google.cloud.audit.AuditLog"
authenticationInfo: {
}
metadata: {
@type: "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
resourceNames: [
0: "projects/117961063178"
]
violationReason: "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
}
methodName: "bigquery.googleapis.com/bigquery.tables.get"
requestMetadata: {
callerIp: "131.201.221.16"
callerNetwork: "//compute.googleapis.com/projects/perimeter-network/global/networks/__unknown__"
destinationAttributes: {
}
requestAttributes: {
}
}
resourceName: "projects/927005422713"
serviceName: "bigquery.googleapis.com"
status: {
code: 7
details: [
0: {
@type: "type.googleapis.com/google.rpc.PreconditionFailure"
violations: [
0: {
type: "VPC_SERVICE_CONTROLS"
}
]
}
]
message: "Request is prohibited by organization's policy"
}
}
receiveTimestamp: "2018-11-28T00:27:05.688803777Z"
resource: {
labels: {
method: "bigquery.googleapis.com/bigquery.tables.get"
project_id: "perimeter-network"
service: "bigquery.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"
timestamp: "2018-11-28T00:27:05.378584819Z"
}
En este ejemplo, no hay ninguna acción subyacente de la API que muestre todos los recursos en juego en esta solicitud debido a limitaciones del mecanismo de registro y la arquitectura distribuida de BigQuery.
El registro de auditoría indica que la operación falló porque para copiar los datos, BigQuery debe acceder al proyecto de destino (corp-resources-public
) mediante la red del proyecto perimeter-network
(la fuente de la solicitud). Recuerda que corp-resources-public
está fuera del perímetro que protege perimeter-network
. Se rechaza la solicitud como un intento de robo de datos a corp-resources-public
.
En este ejemplo, se muestra que una operación conceptual, como copiar datos, puede activar varios intentos para acceder a datos de diferentes sistemas de almacenamiento, como Cloud Storage, BigQuery y Bigtable. Según cómo se ejecute la operación, el registro de auditoría generado difiere del comando del usuario original. Además, cuando se realizan varias verificaciones dentro de un servicio determinado y estas fallan, el registro de auditoría generado se parece al comando del usuario original.
Lectura de trabajo de Dataproc desde el proyecto
En este ejemplo, se muestra cómo depurar errores de los Controles del servicio de VPC indirectos que se generan cuando se usan servicios de procesamiento de datos, como Dataproc.
En este ejemplo, un clúster de Dataproc se ejecuta en un proyecto que protegen los Controles del servicio de VPC. Hello-world.py
es un trabajo pyspark que intenta acceder a los datos del depósito de Cloud Storage dentro del perímetro y, luego, escribirlo en otro depósito fuera del perímetro.
Los Controles del servicio de VPC bloquean la operación que escribe datos en un bucket fuera del perímetro.
El siguiente comando se usa para ejecutar Hello-world.py
:
gcloud dataproc jobs submit pyspark hello-world.py --cluster test-cluster-new2
El comando muestra el siguiente resultado:
Job [50f16ca8-5102-442b-a545-eed5e4f5f5da] submitted.
Waiting for job output...
18/11/29 00:31:34 INFO org.spark_project.jetty.util.log: Logging initialized @2552ms
18/11/29 00:31:34 INFO org.spark_project.jetty.server.Server: jetty-9.3.z-SNAPSHOT
18/11/29 00:31:34 INFO org.spark_project.jetty.server.Server: Started @2640ms
18/11/29 00:31:34 INFO org.spark_project.jetty.server.AbstractConnector: Started ServerConnector@1f1c18ec{HTTP/1.1,[http/1.1]}{0.0.0.0:4040}
18/11/29 00:31:34 INFO com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystemBase: GHFS version: 1.6.4-hadoop2
18/11/29 00:31:35 INFO org.apache.hadoop.yarn.client.RMProxy: Connecting to ResourceManager at test-cluster-new2-m/10.246.0.3:8032
18/11/29 00:31:37 INFO org.apache.hadoop.yarn.client.api.impl.YarnClientImpl: Submitted application application_1522454176466_0005
Traceback (most recent call last):
File "/tmp/50f16ca8-5102-442b-a545-eed5e4f5f5da/hello-world.py", line 8, in <module>
lear.saveAsTextFile("gs://corp-resources-public-1/out.txt")
File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/rdd.py", line 1553, in saveAsTextFile
File "/usr/lib/spark/python/lib/py4j-0.10.4-src.zip/py4j/java_gateway.py", line 1133, in __call__
File "/usr/lib/spark/python/lib/py4j-0.10.4-src.zip/py4j/protocol.py", line 319, in get_return_value
py4j.protocol.Py4JJavaError: An error occurred while calling o49.saveAsTextFile.
: java.io.IOException: Error accessing: bucket: corp-resources-public-1, object: out.txt
at com.google.cloud.hadoop.gcsio.GoogleCloudStorageImpl.wrapException(GoogleCloudStorageImpl.java:1767)
$sp(PairRDDFunctions.scala:961)
(truncated)
Caused by: com.google.api.client.googleapis.json.GoogleJsonResponseException: 403 Forbidden
{
"code" : 403,
"errors" : [ {
"domain" : "global",
"message" : "Request violates VPC Service Controls.",
"reason" : "vpcServiceControls"
} ],
"message" : "Request violates VPC Service Controls."
}
at com.google.api.client.googleapis.json.GoogleJsonResponseException.from(GoogleJsonResponseException.java:145)
(truncated)
18/11/29 00:31:43 INFO org.spark_project.jetty.server.AbstractConnector: Stopped Spark@1f1c18ec{HTTP/1.1,[http/1.1]}{0.0.0.0:4040}
ERROR: (gcloud.dataproc.jobs.submit.pyspark) Job [50f16ca8-5102-442b-a545-eed5e4f5f5da] entered state [ERROR] while waiting for [DONE].
Presta atención a la excepción de IO que se produce cuando se llama al método saveAsTextFile
.
Cloud Storage muestra un error 403
con el mensaje Request violates VPC Service Controls
. El error indica que la operación del registro de auditoría de Cloud Storage debe revisarse.
En los registros de auditoría del proyecto perimeter-network
, en los que se ejecutó el comando, hay un registro de auditoría para la operación saveAsTextFile
:
{
insertId: "qdj1o9d1run"
logName: "projects/corp-resources-private/logs/cloudaudit.googleapis.com%2Fpolicy"
protoPayload: {
@type: "type.googleapis.com/google.cloud.audit.AuditLog"
authenticationInfo: {
principalEmail: "1004338142803-compute@example.gserviceaccount.com"
}
metadata: {
@type: "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
resourceNames: [
0: "projects/_/buckets/corp-resources-public-1/objects/out.txt"
]
violationReason: "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
}
methodName: "google.storage.BillingRequiredRead"
requestMetadata: {
callerIp: "10.246.0.3"
callerNetwork: "//compute.googleapis.com/projects/corp-resources-private/global/networks/__unknown__"
destinationAttributes: {
}
requestAttributes: {
}
}
resourceName: "projects/1004338142803"
serviceName: "storage.googleapis.com"
status: {
code: 7
details: [
0: {
@type: "type.googleapis.com/google.rpc.PreconditionFailure"
violations: [
0: {
type: "VPC_SERVICE_CONTROLS"
}
]
}
]
message: "Request is prohibited by organization's policy"
}
}
receiveTimestamp: "2018-11-29T00:31:43.666227930Z"
resource: {
labels: {
method: "google.storage.BillingRequiredRead"
project_id: "corp-resources-private"
service: "storage.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"
timestamp: "2018-11-29T00:31:43.608250320Z"
}
Debido a las limitaciones del registro de auditoría, el methodName
para Cloud Storage aparece como Read
, aunque en realidad es una operación write
. El registro de auditoría indica que la operación falló porque una red del proyecto corp-resources-private
intentó acceder a los datos (como escribir, en este caso) de un recurso en el depósito corp-resources-public-1
. Debido a las limitaciones del registro de auditoría de Cloud Storage, no está claro a qué bucket de proyecto pertenece corp-resources-public-1
.
Para identificar el proyecto que contiene corp-resources-public-1
, usa el siguiente comando:
gcloud storage ls gs://corp-resources-public-1 --buckets --log-http 2>&1 | grep projectNumber
El comando muestra el siguiente resultado:
"projectNumber": "117961063178",
117961063178
es el proyecto corp-resources-public
, que está fuera del perímetro externo.
Por lo tanto, se espera que falle.
Error debido a servicios no compatibles
Algunos servicios de Google Cloud dependen de otros servicios, ya que parte de su implementación. Si un servicio no compatible, como App Engine se usa dentro de un proyecto protegido por un perímetro, el los recursos del servicio podrían no ser accesibles.
Para obtener información sobre casos problemáticos conocidos, consulta Limitaciones conocidas del servicio.
Servicio no compatible con la VIP restringida
Intentar acceder a una API que no es compatible con la VIP restringida de los Controles del servicio de VPC dará como resultado un error 403
. Por ejemplo, los Controles del servicio de VPC
no es compatible con App Engine, por lo que se API de App Engine Admin
no está disponible cuando se usa la VIP restringida.
Por ejemplo, supongamos que se usa el siguiente comando para enumerar todas las instancias de App Engine dentro de un perímetro de servicio:
gcloud app services list
El comando muestra el siguiente resultado:
ERROR: (gcloud.app.services.list) User [***] does not have permission to access apps instance [***] (or it may not exist): <!DOCTYPE html>
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>Error 403 (Forbidden)!!1</title>
<style>
*{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){ #logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){ #logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
</style>
<a href=//www.google.com/><span id=logo aria-label=Google></span></a>
<p><b>403.</b> <ins>That's an error.</ins>
<p>Your client does not have permission to get URL <code>/v1/apps/***/services</code> from this server. <ins>That's all we know.</ins>
Este tipo de error es el esperado para los servicios que no son compatibles con los Controles del servicio de VPC y que no están disponibles en la VIP restringida. Si este error para un servicio que es compatible con los Controles del servicio de VPC, te recomendamos que revises el servicio limitaciones para ese servicio ver si se trata de una limitación conocida. De lo contrario, el problema debe debe denunciarse.
Exportación de registros al proyecto fuera del perímetro
En este ejemplo, los Controles del servicio de VPC bloquean una exportación de registro.
El destino de la exportación, el proyecto corp-resources-public
, está fuera del perímetro de los Controles del servicio de VPC, mientras que el receptor se crea en el proyecto perimeter-network
, que está dentro del perímetro.
Por ejemplo, supongamos que se usa el siguiente comando:
gcloud logging sinks describe example-sink
El comando muestra el siguiente resultado:
destination: bigquery.googleapis.com/projects/corp-resources-public/datasets/logs
filter: |-
resource.type="audited_resource"
resource.labels.service="bigquery.googleapis.com"
name: example-sink
outputVersionFormat: V2
writerIdentity: serviceAccount:p927005422713-439672@gcp-sa-logging.iam.gserviceaccount.com
Se genera el siguiente registro de auditoría:
{
insertId: "e5i2i8cbqw"
logName: "projects/perimeter-network/logs/cloudaudit.googleapis.com%2Fpolicy"
protoPayload: {
@type: "type.googleapis.com/google.cloud.audit.AuditLog"
authenticationInfo: {
principalEmail: "p927005422713-439672@gcp-sa-logging.iam.gserviceaccount.com"
}
metadata: {
@type: "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
resourceNames: [
0: "corp-resources-public"
]
violationReason: "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
}
methodName: "google.cloud.bigquery.v2.TableDataService.InsertAll"
requestMetadata: {
callerIp: "2002:a49:8c51::"
destinationAttributes: {
}
requestAttributes: {
}
}
resourceName: "projects/927005422713"
serviceName: "bigquery.googleapis.com"
status: {
code: 7
details: [
0: {
@type: "type.googleapis.com/google.rpc.PreconditionFailure"
violations: [
0: {
type: "VPC_SERVICE_CONTROLS"
}
]
}
]
message: "Request is prohibited by organization's policy"
}
}
receiveTimestamp: "2018-11-29T17:32:19.287138882Z"
resource: {
labels: {
method: "google.cloud.bigquery.v2.TableDataService.InsertAll"
project_id: "perimeter-network"
service: "bigquery.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"
timestamp: "2018-11-29T17:32:19.054662413Z"
}
El registro de auditoría se genera para BigQuery, no para Logging. Esto se debe a que BigQuery es el servicio de receptor al que Logging intenta escribir.
La exportación falla porque corp-resources-public
está por fuera del perímetro que protege a perimeter-network
.
En este ejemplo, se muestra que, en los casos en que un servicio de Google Cloud llama
y otro con una cuenta de servicio administrada
interna de Google Cloud
como, por ejemplo,
p927005422713-439672@gcp-sa-logging.iam.gserviceaccount.com
, la "red"
proyecto" (en este caso, perimeter-network
) de la solicitud se deriva de esa
con tu identidad. La misma identidad representa el recurso de exportación de registros en sí.
Este patrón es común en Google Cloud y se aplica a muchos casos de interacción de servicio a servicio.
Extracción de BigQuery a Cloud Storage
En este ejemplo, se describe cómo depurar extracciones de BigQuery con errores a Cloud Storage.
En este ejemplo, corp-resources-private
y perimeter-network
son proyectos protegidos por un perímetro de servicio. corp-resources-public
es un proyecto que está fuera del perímetro.
Supongamos que se usó el siguiente comando:
bq extract babynames.yob2000
El comando muestra el siguiente resultado:
gs://corp-resources-public-1/export.txt
Waiting on bqjob_r47ee34109d02b41_000001676b27157c_1 ... (1s) Current status: DONE
BigQuery error in extract operation: Error processing job 'corp-resources-private:bqjob_r47ee34109d02b41_000001676b27157c_1': Access
Denied: BigQuery BigQuery: Permission denied while writing data.
En este caso, el error no implica de manera específica los Controles del servicio de VPC. Se muestra un error similar si hay una falla de administración de identidades y accesos.
Se genera el siguiente registro de auditoría:
{
insertId: "4gbh6pe8jld7"
logName: "projects/corp-resources-private/logs/cloudaudit.googleapis.com%2Fdata_access"
protoPayload: {
@type: "type.googleapis.com/google.cloud.audit.AuditLog"
authenticationInfo: {
principalEmail: "storage-accessing@example.iam.gserviceaccount.com"
}
methodName: "jobservice.jobcompleted"
requestMetadata: {
callerIp: "10.5.0.4"
callerNetwork: "//compute.googleapis.com/projects/perimeter-network/global/networks/__unknown__"
callerSuppliedUserAgent: "google-api-python-client/1.6.5 (gzip),gzip(gfe)"
destinationAttributes: {
}
requestAttributes: {
}
}
resourceName: "projects/corp-resources-private/jobs/bqjob_r47ee34109d02b41_000001676b27157c_1"
serviceData: {
@type: "type.googleapis.com/google.cloud.bigquery.logging.v1.AuditData"
jobCompletedEvent: {
eventName: "extract_job_completed"
job: {
jobConfiguration: {
extract: {
destinationUris: [
0: "gs://corp-resources-public-1/export.txt"
]
sourceTable: {
datasetId: "babynames"
projectId: "corp-resources-private"
tableId: "yob2000"
}
}
}
jobName: {
jobId: "bqjob_r47ee34109d02b41_000001676b27157c_1"
location: "US"
projectId: "corp-resources-private"
}
jobStatistics: {
createTime: "2018-12-01T19:03:03.908Z"
endTime: "2018-12-01T19:03:05.494Z"
startTime: "2018-12-01T19:03:04.013Z"
}
jobStatus: {
additionalErrors: [
0: {
code: 7
message: "Access Denied: BigQuery BigQuery: Permission denied while writing data."
}
]
error: {
code: 7
message: "Access Denied: BigQuery BigQuery: Permission denied while writing data."
}
state: "DONE"
}
}
}
}
serviceName: "bigquery.googleapis.com"
status: {
code: 7
message: "Access Denied: BigQuery BigQuery: Permission denied while writing data."
}
}
receiveTimestamp: "2018-12-01T19:03:05.532169998Z"
resource: {
labels: {
project_id: "corp-resources-private"
}
type: "bigquery_resource"
}
severity: "ERROR"
timestamp: "2018-12-01T19:03:05.503Z"
}
En este registro de auditoría, storage-accessing@example.iam.gserviceaccount.com
se identifica como la identidad que intenta ejecutar la operación. En este ejemplo, supongamos que storage-accessing@example.iam.gserviceaccount.com
tiene los permisos de IAM necesarios para ejecutar el comando.
Debido a que los permisos de IAM no son el problema, el siguiente paso es verificar las fallas de los Controles del servicio de VPC.
El registro de auditoría del servicio de destino (Cloud Storage) contiene los motivos detallados de la falla:
{
insertId: "1bq397kcfj1"
logName: "projects/corp-resources-private/logs/cloudaudit.googleapis.com%2Fpolicy"
protoPayload: {
@type: "type.googleapis.com/google.cloud.audit.AuditLog"
authenticationInfo: {
principalEmail: "storage-accessing@example.iam.gserviceaccount.com"
}
metadata: {
@type: "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
resourceNames: [
0: "projects/1004338142803"
1: "projects/_/buckets/corp-resources-public-1"
]
violationReason: "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
}
methodName: "google.storage.BillingRequiredRead"
requestMetadata: {
callerIp: "10.5.0.4"
callerNetwork: "//compute.googleapis.com/projects/perimeter-network/global/networks/__unknown__"
destinationAttributes: {
}
requestAttributes: {
}
}
resourceName: "projects/1004338142803"
serviceName: "storage.googleapis.com"
status: {
code: 7
details: [
0: {
@type: "type.googleapis.com/google.rpc.PreconditionFailure"
violations: [
0: {
type: "VPC_SERVICE_CONTROLS"
}
]
}
]
message: "Request is prohibited by organization's policy"
}
}
receiveTimestamp: "2018-12-01T19:03:05.617451586Z"
resource: {
labels: {
method: "google.storage.BillingRequiredRead"
project_id: "corp-resources-private"
service: "storage.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"
timestamp: "2018-12-01T19:03:05.420005215Z"
}
En este registro, queda claro que se están usando los dos proyectos 1004338142803
(corp-resources-private-1
) y corp-resources-public
para completar el comando. Debido a que estos proyectos no comparten un perímetro, el trabajo de extracción falla.
En este ejemplo, se demuestra que, en las operaciones de varios servicios complejas, los registros de auditoría para los servicios de origen y de destino pueden contener datos de depuración útiles.
Acceso al perímetro a través de la puerta de enlace de Cloud NAT
En este ejemplo, supongamos que el proyecto A de la Organización A no está configurado dentro de ninguna perímetro de servicio. El proyecto B está protegido por un perímetro en otra organización. Los recursos privados del proyecto A usan la puerta de enlace de Cloud NAT para llegar en Internet, así como los servicios y las APIs de Google. Se configuró un nivel de acceso en el proyecto B para permitir el acceso según las direcciones IP de la puerta de enlace externa del proyecto A.
Una VM que pertenece al proyecto A (que puede ser un nodo de Google Kubernetes Engine) intenta acceder a un recurso protegido en el proyecto B, pero la conexión falla, y se genera el siguiente registro de auditoría en el proyecto B:
{
"protoPayload": {
"@type": "type.googleapis.com/google.cloud.audit.AuditLog",
"status": {
"code": 7,
"message": "Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: kmpY9Fgfuhgi2NE90lURjFWuiS1nGRqxCw4L12HdW8h46Un__-_LZw",
"details": [
{
"@type": "type.googleapis.com/google.rpc.PreconditionFailure",
"violations": [
{
"type": "VPC_SERVICE_CONTROLS",
"description": "kmpY9Fgfuhgi2NE90lURjFWuiS1nGRqxCw4L12HdW8h46Un__-_LZw"
}
]
}
]
},
"authenticationInfo": {
"principalEmail": "my-user@example.iam.gserviceaccount.com",
"serviceAccountKeyName": "//iam.googleapis.com/projects/my-project/serviceAccounts/my-user@example.iam.gserviceaccount.com/keys/<code><var>ACCOUNT_KEY</var></code>"
},
"requestMetadata": {
"callerIp": "gce-internal-ip",
"requestAttributes": {},
"destinationAttributes": {}
},
"serviceName": "cloudfunctions.googleapis.com",
"methodName": "google.cloud.functions.v1.CloudFunctionsService.ListFunctions",
"resourceName": "<code><var>PROJECT_ID_1</var></code>",
"metadata": {
"violationReason": "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER",
"resourceNames": [
"projects/<code><var>PROJECT_ID_2</var></code>/locations/-"
],
"securityPolicyInfo": {
"servicePerimeterName": "accessPolicies/<code><var>ACCESS_POLICY</var></code>/servicePerimeters/us_sandbox",
"organizationId": "<code><var>ORGANIZATION_ID</var></code>"
},
"deviceState": "Unknown",
"vpcServiceControlsUniqueId": "kmpY9Fgfuhgi2NE90lURjFWuiS1nGRqxCw4L12HdW8h46Un__-_LZw",
"ingressViolations": [
{
"targetResource": "projects/<code><var>PROJECT_ID_1</var></code>",
"servicePerimeter": "accessPolicies/<code><var>ACCESS_POLICY</var></code>/servicePerimeters/<code><var>PERIMETER_NAME</var></code>",
"source": "<code><var>PROJECT_ID_2</var></code>"
}
],
"@type": "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
}
},
"insertId": "tzf7fd103i",
"resource": {
"type": "audited_resource",
"labels": {
"service": "cloudfunctions.googleapis.com",
"method": "google.cloud.functions.v1.CloudFunctionsService.ListFunctions",
"project_id": "<code><var>PROJECT_ID_2</var></code>"
}
},
"timestamp": "2024-04-02T19:56:10.770681816Z",
"severity": "ERROR",
"logName": "projects/<code><var>PROJECT_ID_2</var></code>/logs/cloudaudit.googleapis.com%2Fpolicy",
"receiveTimestamp": "2024-04-02T19:56:11.463811603Z"
}
El recurso callerIp
no registra una dirección IP externa. En lugar de
la dirección IP externa de la puerta de enlace de Cloud NAT, el recurso callerIp
muestra gce-internal-ip
.
El campo callerIp
se oculta como gce-internal-ip
cuando las solicitudes
se originan en un proyecto u organización diferente y la fuente
La VM de Compute Engine no tiene una dirección IP externa.
Cloud NAT tiene una integración con el Acceso privado a Google que habilita automáticamente el Acceso privado a Google en la subred del recurso, y mantiene el tráfico a los servicios y las APIs de Google interno, en lugar y enrutarlo a Internet con la puerta de enlace externa de Cloud NAT dirección IP pública.
En este caso, como el tráfico se enruta dentro de la red interna de Google, el
El campo RequestMetadata.caller_ip
del objeto AuditLog
se oculta como
gce-internal-ip
Para solucionar esto, en lugar de usar la puerta de enlace
dirección IP externa de la puerta de enlace en el nivel de acceso para la lista de entidades permitidas basada en IP
configurar una regla de entrada para permitir desde el proyecto o la cuenta de servicio.
¿Qué sigue?
- Obtén información para recuperar errores de los Controles del servicio de VPC de los registros de auditoría.
- Obtén información para solucionar problemas comunes relacionados con otros servicios de Google Cloud.