Controles del servicio de VPC: Protección del Servicio de transferencia de datos de BigQuery

1. Introducción

En este lab, aprenderemos a proteger el Servicio de transferencia de datos de BigQuery con los Controles del servicio de VPC mientras transferimos datos de Cloud Storage a un conjunto de datos de BigQuery. Luego, protegemos Cloud Storage y repetimos el proceso para transferir datos de Cloud Storage a BigQuery. La protección de Cloud Storage genera una infracción de los Controles del servicio de VPC, que se debe corregir para que la transferencia se realice correctamente. Al final, también protegemos BigQuery y, luego, intentamos copiar el conjunto de datos entre proyectos, lo que también genera un incumplimiento que se debe corregir.

En este lab, veremos cómo corregir los incumplimientos de entrada y salida con las reglas de entrada y salida, respectivamente. También usaremos un nivel de acceso para corregir la infracción de entrada de BigQuery Data Transfer. Los objetivos de este codelab son los siguientes:

• Comprende cómo corregir los incumplimientos de entrada y salida con reglas de entrada y salida, respectivamente, en diferentes servicios, en particular, Cloud Storage, BigQuery y el Servicio de transferencia de datos de BigQuery.
• Comprender por qué se produjo un incumplimiento específico

2. Configuración y requisitos de los recursos

Antes de comenzar

En este codelab, suponemos que ya sabes lo siguiente:

• Cómo crear una carpeta
• Cómo crear un proyecto en una carpeta o mover un proyecto existente a una carpeta
• Cómo crear una política de acceso con alcance
• Cómo crear y configurar un perímetro de servicio desde la consola de Google Cloud
• Cómo encontrar registros de incumplimientos en los registros de auditoría

Estos requisitos previos se abordaron en otros codelabs de los Controles del servicio de VPC: Instructivo básico I de los Controles del servicio de VPC y Instructivo básico II de los Controles del servicio de VPC: Solución de problemas relacionados con incumplimientos de salida.

Configuración

Nuestra configuración inicial está diseñada de la siguiente manera:

• Una organización de Google Cloud.
• Una carpeta en la organización. Para este codelab, lo llamaremos codelab-folder.
• Dos proyectos de Google Cloud en la carpeta codelab-folder En este codelab, llamaremos a los proyectos project-1 y project-2.
  • Si aún no tienes la carpeta y los proyectos creados, en la consola de Google Cloud, crea una carpeta en la organización y crea dos proyectos nuevos.
• Los permisos necesarios: roles de IAM para administrar carpetas, roles de IAM para administrar proyectos, roles de IAM necesarios para configurar controles de servicio de VPC, roles de IAM para administrar BigQuery y roles de IAM para administrar Cloud Storage.
• Cuenta de facturación de los proyectos project-1 y project-2

Para este codelab, puedes otorgarte los siguientes roles predefinidos: Administrador de carpetas y Creador de proyectos (a nivel de la carpeta), Propietario (a nivel del proyecto), Administrador de BigQuery (a nivel del proyecto), Administrador de objetos de almacenamiento (a nivel del proyecto) y Administrador de Access Context Manager (a nivel de la organización). Tendrás los roles necesarios para configurar los recursos necesarios para todo este codelab.

Crea una política con alcance y un perímetro de servicio normal

En este codelab, usaremos un perímetro de servicio normal que proteja project-2.

• Crea una política de acceso con alcance, que se aplica a nivel de la carpeta codelab-folder. En este codelab, suponemos que la política de acceso creada tiene el ID 987654321.
• Crea un perímetro normal, lo llamaremos perimeter-2, y agrega el proyecto project-2.

En el perímetro perimeter-2, restringe BigQuery Data Transfer API.

Creación de un bucket de Cloud Storage y un conjunto de datos de BigQuery

Para los fines de este codelab, cualquier archivo CSV es suficiente, independientemente del contenido. La principal limitación se relaciona con el requisito de colocalización, que establece lo siguiente:

• Si tu conjunto de datos de BigQuery está en una multirregión, el bucket de Cloud Storage que contiene los datos que transferirás debe estar en la misma multirregión o en una ubicación dentro de la multirregión.
• Si tu conjunto de datos está en una región, el bucket de Cloud Storage debe estar en la misma región.

A partir de ahora, en este codelab, nos aseguraremos de que el bucket de Cloud Storage y el conjunto de datos de BigQuery estén en la misma región o multirregión.

Crea un bucket de Cloud Storage nuevo en el proyecto project-1

En este codelab, usaremos Cloud Storage como fuente de datos, que es una fuente de datos compatible con el Servicio de transferencia de datos de BigQuery.

Para crear un bucket de Cloud Storage nuevo, sigue los pasos documentados para crear un bucket nuevo.

• Para el nombre del bucket, ingresa uno que cumpla con los requisitos de nombres de buckets. En este codelab, llamaremos al bucket codelab-bqtransfer-bucket.
• En Dónde almacenar los datos, ubicación del bucket, selecciona un Tipo de ubicación y una Ubicación en la que se almacenarán los datos del bucket de forma permanente. En este codelab, usaremos us (varias regiones en Estados Unidos).

Cree un archivo CSV

Si ya tienes un archivo CSV de muestra, puedes omitir este paso.

Desde tu máquina local o con Cloud Shell, podemos usar el comando echo para crear un archivo CSV de muestra, codelab-test-file.csv, con los siguientes comandos:

echo "name,age" > codelab-test-file.csv; \
echo "Alice,10" >> codelab-test-file.csv; \
echo "Bob,20" >> codelab-test-file.csv; \
echo "Carol,30" >> codelab-test-file.csv; \
echo "Dan,40" >> codelab-test-file.csv; \
echo "Eve,50" >> codelab-test-file.csv; \
echo "Frank,60" >> codelab-test-file.csv; \
echo "Grace,70" >> codelab-test-file.csv; \
echo "Heidi,80" >> codelab-test-file.csv;

Sube el archivo CSV al bucket de Cloud Storage

Una vez que se cree el archivo CSV, ejecuta el siguiente comando para subir el objeto de archivo al bucket creado:

gcloud storage cp codelab-test-file.csv gs://codelab-bqtransfer-bucket

Para verificar que el archivo se subió al bucket creado, enumera los objetos del bucket o ejecuta el siguiente comando:

gcloud storage ls --recursive gs://codelab-bqtransfer-bucket/**

Crea un conjunto de datos y una tabla de BigQuery en project-2

1. Crea un conjunto de datos de BigQuery en el proyecto project-2 siguiendo estos pasos.
   1. En ID de conjunto de datos, ingresa un nombre único para el conjunto de datos. En este codelab, usamos codelab_bqtransfer_dataset.
   2. En Tipo de ubicación, elige una ubicación geográfica para el conjunto de datos. En este codelab, usamos la misma ubicación que el bucket de Cloud Storage: EE.UU. (varias regiones en Estados Unidos).
2. Sigue estos pasos para crear una tabla de BigQuery en el conjunto de datos codelab_bqtransfer_dataset creado.
   1. En la sección Fuente, selecciona Tabla vacía en la lista Crear tabla desde.
   2. En el campo Tabla, ingresa el nombre de la tabla que deseas crear. En este codelab, usaremos el nombre codelab-bqtransfer-table.
   3. Verifica que el campo Tipo de tabla esté configurado como Tabla nativa.
   4. En la sección Esquema, ingresa la definición del esquema. Para ingresar información del esquema, haz clic en Editar como texto y, luego, ingresa el siguiente esquema, que se ajusta al formato del archivo CSV creado.

   [{
   "name": "name",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The name"
   },
   {
   "name": "age",
   "type": "INTEGER",
   "mode": "NULLABLE",
   "description": "The age"
   }]
   

Costo

Debes habilitar la facturación en los proyectos project-2 y project-1 para usar las APIs o los recursos de Cloud. Te recomendamos que cierres los recursos que usaste para evitar que se te facture más allá de este codelab.

Los usuarios nuevos de Google Cloud son aptos para participar en el programa de Prueba gratuita de USD 300.

Los recursos que incurren en el costo son BigQuery y Cloud Storage. Puedes encontrar un costo estimado en la calculadora de precios de BigQuery y la calculadora de Cloud Storage.

3. Configura la transferencia de datos de un objeto de Cloud Storage a una tabla de BigQuery

Ahora, intentaremos crear un servicio de transferencia de datos (en project-2) para transferir datos de Cloud Storage (ubicado en project-1) a BigQuery (ubicado en project-2), mientras que los controles de servicio de VPC protegen el Servicio de transferencia de datos de BigQuery en project-2. Si solo proteges el Servicio de transferencia de datos de BigQuery (sin proteger BigQuery ni Cloud Storage), se restringe a los principales a solo crear y administrar transferencias de datos (como iniciar una transferencia de datos de forma manual).

Configura la transferencia de datos desde Cloud Storage

Para crear una transferencia de datos, sigue estos pasos:

1. Ve a la página de BigQuery en la consola de Google Cloud de project-2.
2. Haz clic en Transferencias de datos.

Se debe producir una infracción de los Controles del servicio de VPC, ya que el perímetro perimeter-2 protege el Servicio de transferencia de datos de BigQuery en project-2. Los Controles del servicio de VPC deben permitir el acceso para poder configurar la transferencia de datos.

Investiga el incumplimiento cuando accedas a la página Transferencias de datos

En la consola de Google Cloud, podemos ver el identificador único de los Controles del servicio de VPC. Usa el mismo identificador para filtrar registros y, luego, identificar los detalles del incumplimiento (reemplaza OBSERVED_VPCSC_DENIAL_UNIQUE_ID por el ID de denegación observado):

protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="OBSERVED_VPCSC_DENIAL_UNIQUE_ID"

El incumplimiento observado es un NO_MATCHING_ACCESS_LEVEL, que es un incumplimiento de entrada con detalles similares a los siguientes:

ingressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
targetResource: "projects/[PROJECT2_NUMBER]"
}]
violationReason: "NO_MATCHING_ACCESS_LEVEL"
callerIp: "USER_PUBLIC_IP_ADDRESS"
resource: {
labels: {
method: "google.cloud.bigquery.datatransfer.v1.DataTransferService.ListTransferConfigs"
project_id: "project-2"
service: "bigquerydatatransfer.googleapis.com"
}
type: "audited_resource"
}

El acceso a la página Transferencias de datos intenta enumerar las transferencias de datos configuradas; por lo tanto, se incumple el método ListTransferConfigs.

Cómo corregir el incumplimiento del servicio bigquerydatatransfer.googleapis.com

Se puede usar un nivel de acceso o una regla de entrada para corregir una infracción de entrada. En este codelab, usaremos una regla de entrada configurada con la identidad de usuario denegada, que permite el acceso al servicio bigquerydatatransfer.googleapis.com y a todos los métodos.

Una vez que se implemente la regla de entrada, el acceso a la página Transferencias de datos debería funcionar sin problemas.

Cómo reanudar la configuración de la transferencia de datos desde Cloud Storage

Desde los pasos anteriores, en la página Transferencias de datos (después de hacer clic en Transferencias de datos), continúa con los siguientes pasos:

1. Haz clic en + Crear transferencia.
2. En la sección Tipo de fuente (Source type), para Fuente (Source), elige Google Cloud Storage.
3. En la sección Nombre de la configuración de transferencia (Transfer config name), en Nombre visible (Display name), ingresa un nombre para la transferencia, como Codelab Transfer.
4. En la sección Opciones de programación, haz lo siguiente:
   1. Selecciona una Frecuencia de repetición, como 15 minutos.
   2. Asegúrate de seleccionar Comenzar ahora. De lo contrario, la transferencia de datos comenzará solo después de la frecuencia de repetición configurada.
5. En la sección Configuración de destino, en Conjunto de datos de destino, elige el conjunto de datos que creaste para almacenar tus datos: codelab_bqtransfer_dataset
6. En la sección Detalles de la fuente de datos, haz lo siguiente:
   1. En Tabla de destino, ingresa el nombre de tu tabla de destino. La tabla de destino debe seguir las reglas de nombres de las tablas. En este codelab, usaremos la tabla que creamos antes: codelab-bqtransfer-table
   2. En URI de Cloud Storage, ingresa el URI de Cloud Storage. En este codelab, usaremos el bucket y el archivo creados: codelab-bqtransfer-bucket/codelab-test-file.csv
   3. En Preferencia de escritura, mantén APPEND (o elige MIRROR).
   4. NO selecciones la opción para borrar los archivos después de la transferencia (ya que reutilizaremos el mismo archivo varias veces). Sin embargo, puedes usar varios archivos y borrar los archivos de origen después de la transferencia).
   5. En Formato de archivo, selecciona CSV.
   6. En Opciones de transferencia, en CSV, ingresa la coma(",") como Delimitador de campos.
7. En el menú Cuenta de servicio, selecciona una cuenta de servicio de las cuentas de servicio asociadas con tu proyecto de Google Cloud.
   1. La cuenta de servicio seleccionada debe tener los permisos necesarios para Cloud Storage en el proyecto que aloja el bucket de almacenamiento (project-1 en este codelab).
   2. En este codelab, usaremos una cuenta de servicio creada en project-2 como [e-mail].
8. Haz clic en Guardar.

Como seleccionamos Comenzar ahora como opción de programación, la primera transferencia comenzará en cuanto se seleccione Guardar.

La cuenta de servicio especificada en la configuración de transferencia de datos se usará para acceder al objeto del bucket de Cloud Storage. Para cada intento de transferencia de datos, los registros de project-1 (el proyecto de origen) deben mostrar una entrada de registro de la cuenta de servicio que realiza la llamada storage.objects.get (serviceName: "storage.googleapis.com") en el objeto que se transfiere. Por otro lado, cuando revises los registros en project-2, que aloja la tabla de BigQuery de destino, verás que el agente del Servicio de transferencia de datos de BigQuery es el que escribe datos (serviceName: 'bigquery.googleapis.com') del objeto de almacenamiento en la tabla de BigQuery especificada.

Verifica el estado del servicio de transferencia de datos

Para verificar el estado de la transferencia de datos configurada, sigue estos pasos:

• Ve a la página de BigQuery en la consola de Google Cloud.
• Haz clic en Transferencias de datos.
• Se muestra la lista de transferencias configuradas.

Haz clic en Codelab Transfer (en Nombre visible) para ver una lista de todas las ejecuciones realizadas hasta el momento.

La ejecución de la transferencia de datos debería ser exitosa, sin infracciones de los Controles del servicio de VPC para la transferencia de datos programada y activada de forma manual. Ten en cuenta que solo la transferencia activada de forma manual necesita la regla de entrada para permitir el acceso al principal, que inicia la transferencia de forma manual.

4. Restricciones de direcciones IP para transferencias de datos activadas de forma manual

Las reglas de entrada configuradas actualmente permiten que la identidad configurada active la transferencia de datos de forma manual desde cualquier dirección IP.

Con el uso del nivel de acceso, los Controles del servicio de VPC proporcionan la capacidad de limitar el acceso permitido por atributos específicos de la solicitud de API, en particular:

• Subredes de IP: Comprueba si la solicitud proviene de una dirección IP específica.
• Regiones: Verifica si la solicitud proviene de una región específica, que se determina según la ubicación geográfica de la dirección IP.
• Principales: Comprueba si la solicitud proviene de una cuenta específica.
• Política de dispositivos: Comprueba si la solicitud proviene de un dispositivo que cumple con requisitos específicos.

Para aplicar la verificación de estos atributos junto con la regla de entrada ya configurada, debemos crear un nivel de acceso que permita los atributos deseados y, luego, agregar el nivel de acceso creado como la fuente en la regla de entrada.

En este diagrama, se ilustra el acceso que inician los dos principales ([e-mail] y [e-mail]) en tres situaciones, lo que demuestra cómo los Controles del servicio de VPC evalúan las fuentes (nivel de acceso de entrada) y los atributos de identidad como una condición Y en la que ambos deben coincidir.

1. Se le permite acceso al usuario [e-mail] cuando intenta acceder desde una dirección IP permitida por el nivel de acceso, ya que su dirección IP y cuenta de usuario coinciden con las configuraciones de la regla de entrada.
2. Se bloquea el acceso del usuario [e-mail] cuando su dirección IP no coincide con la dirección IP permitida, a pesar de que su cuenta es la que se configuró en la regla de entrada.
3. Se bloquea el acceso del usuario [e-mail] a pesar de que intenta acceder desde una dirección IP permitida, ya que la regla de entrada no permite su cuenta.

Crea un nivel de acceso

Para crear un nivel de acceso que limite el acceso por dirección IP, sigue estos pasos:

1. Abre la página Access Context Manager en la consola de Google Cloud.
   • Si se te solicita, selecciona la carpeta codelab-folder.
2. En la parte superior de la página Access Context Manager, haz clic en CREATE ACCESS LEVEL.
3. En el panel Nuevo nivel de acceso, asigna un Título al nivel de acceso nuevo. Para este codelab, lo llamaremos project_2_al.
4. En la sección Condiciones, haz clic en + frente a Subredes de IP.
5. En el cuadro Subredes de IP, selecciona IP pública.
   • Como alternativa, puedes seleccionar usar una IP privada para usar una dirección IP interna en los niveles de acceso. Sin embargo, para este codelab, usaremos una IP pública.
   • Ingresa uno o más rangos IPv4 o IPv6 con formato de bloques CIDR.

Los registros de incumplimientos de los Controles del servicio de VPC mostrarán la dirección IP pública del usuario, a menos que el acceso se haya realizado desde una instancia de Compute Engine sin dirección IP externa.

Agrega el nivel de acceso en la regla de entrada

Dentro de la regla de entrada, se hace referencia al nivel de acceso en el campo sources, que es un campo obligatorio, como se documenta en la referencia de la regla de entrada. Para permitir la entrada a recursos, los Controles del servicio de VPC evalúan los atributos sources y identityType como una condición Y. La regla de entrada usa la identidad del principal que activa la transferencia de datos de forma manual, no la cuenta de servicio especificada en la configuración de transferencia de datos.

Vuelve a ejecutar la transferencia con las configuraciones que limitan el acceso por dirección IP

Para evaluar la eficacia de las configuraciones aplicadas, vuelve a activar la transferencia con las siguientes situaciones:

• con la dirección IP en el rango permitido en el nivel de acceso al que hace referencia la regla de entrada.
• usar una dirección IP que no está permitida por las configuraciones

El acceso desde direcciones IP permitidas debería ser exitoso, mientras que el acceso desde direcciones IP no permitidas debería fallar y generar una infracción de los Controles del servicio de VPC.

Una forma sencilla de probar con una dirección IP diferente es permitir la dirección IP asignada mientras usas la consola de Google Cloud y, luego, realizar la prueba con Cloud Shell.

En Cloud Shell, ejecuta el siguiente comando para activar una transferencia de forma manual. Para ello, reemplaza RUN_TIME y RESOURCE_NAME:

bq mk \
  --transfer_run \
  --run_time='RUN_TIME' \
  RESOURCE_NAME

Por ejemplo, el siguiente comando de muestra se ejecuta de inmediato para una configuración de transferencia 12345678-90ab-cdef-ghij-klmnopqrstuv en el proyecto 1234567890.

NOW=$(TZ=GMT date +"%Y-%m-%dT%H:%M:%SZ");
bq mk \
  --transfer_run \
  --run_time=$NOW \
  projects/1234567890/locations/us/transferConfigs/12345678-90ab-cdef-ghij-klmnopqrstuv

El resultado observado muestra un incumplimiento de los Controles del servicio de VPC, como se esperaba, ya que la dirección IP no está permitida.

La infracción observada se encuentra en el método DataTransferService.StartManualTransferRuns.

ingressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
targetResource: "projects/[PROJECT2_NUMBER]"
targetResourcePermissions: [0: "vpcsc.permissions.unavailable"]
}]
violationReason: "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
resource: {
labels: {
method: "google.cloud.bigquery.datatransfer.v1.DataTransferService.StartManualTransferRuns"
project_id: "project-2"
service: "bigquerydatatransfer.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"

5. Cómo iniciar la transferencia de datos mientras proteges el servicio de almacenamiento en la nube

Como realizaremos una transferencia de Cloud Storage a BigQuery, agreguemos Cloud Storage entre los servicios protegidos por los Controles del servicio de VPC y veamos si la transferencia se realiza correctamente.

En la configuración de perimeter-2, agrega la API de Cloud Storage como uno de los servicios restringidos, junto con la API de BigQuery Data Transfer.

Después de proteger la API de Cloud Storage, espera a la próxima transferencia de datos programada o activa una transferencia de forma manual siguiendo estos pasos:

1. Ve a la página de BigQuery en la consola de Google Cloud.
2. Haz clic en Transferencias de datos.
3. Selecciona tu transferencia en la lista: para este codelab, usaremos la transferencia Codelab Transfer.
4. Haz clic en Ejecutar transferencia ahora.
5. Haz clic en Aceptar.

Se iniciará otra transferencia. Es posible que debas actualizar la página para verla. Esta vez, la transferencia fallará con un incumplimiento de los Controles del servicio de VPC.

Investiga el incumplimiento de los Controles del servicio de VPC de Cloud Storage

Filtra los registros de auditoría con vpcServiceControlsUniqueIdentifier, como se ve en el Resumen de la transferencia.

El incumplimiento observado es un incumplimiento de salida de RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER con los siguientes detalles:

• El principal es la cuenta de servicio configurada en el servicio de transferencia de datos (ya sea que se active de forma manual o se ejecute la transferencia de datos programada, el principal rechazado será el mismo).
• El servicio afectado es Cloud Storage
• La fuente de la solicitud es el proyecto en el que se configuró el servicio de transferencia de datos: project-2
• El proyecto de destino es el proyecto en el que se encuentra el objeto de Cloud Storage: project-1

principalEmail: "[e-mail]"
egressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
source: "projects/[PROJECT2_NUMBER]"
sourceType: "Resource"
targetResource: "projects/[PROJECT1_NUMBER]"
targetResourcePermissions: [0: "storage.objects.get"]
}]
labels: {
method: "google.storage.objects.get"
project_id: "project-2"
service: "storage.googleapis.com"
}

Corrige la infracción de salida de Cloud Storage

Para corregir la infracción de salida, debemos usar una regla de salida que permita el tráfico de la cuenta de servicio rechazada hacia el proyecto con objetos de Cloud Storage.

Después de modificar el perímetro de servicio perimeter-2, repite el proceso para volver a activar la transferencia. La transferencia no mostrará un error.

6. Copia el conjunto de datos de BigQuery de project-2 a project-1

Después de confirmar que podemos transferir datos del bucket de Cloud Storage en project-1 al conjunto de datos de BigQuery en project-2, copiemos el conjunto de datos de BigQuery de project-2 a project-1, mientras que la API de BigQuery está protegida por los controles de servicio de VPC.

Para crear y copiar el conjunto de datos, usaremos el comando bq mk, que usa la herramienta bq.

BigQuery usa el Servicio de transferencia de datos de BigQuery en el backend para copiar conjuntos de datos.

Crea el conjunto de datos de destino en project-1

Antes de copiar el conjunto de datos, primero debes crear el conjunto de datos de destino. Para crear el conjunto de datos de destino, podemos ejecutar el siguiente comando, que crea un conjunto de datos llamado copied_dataset, en el proyecto project-1 con us como ubicación.

bq mk \
  --dataset \
  --location=us \
  project-1:copied_dataset

Protege el servicio de BigQuery en project-2 con los Controles del servicio de VPC

Modifica la configuración del perímetro perimeter-2 y agrega la API de BigQuery como el servicio protegido, junto con los servicios de BigQuery Data Transfer y Cloud Storage.

Inicia la copia del conjunto de datos

Para copiar el conjunto de datos, ejecuta el siguiente comando bq mk, que copia el conjunto de datos codelab_bqtransfer_dataset del proyecto project-2 en el conjunto de datos copied_dataset de project-1 y reemplaza el contenido del conjunto de datos, si corresponde.

bq mk \
  --transfer_config \
  --project_id=project-1 \
  --target_dataset=copied_dataset \
  --data_source=cross_region_copy \
  --display_name='Dataset from project-2 to project-1' \
  --params='{
     "source_dataset_id":"codelab_bqtransfer_dataset",
     "source_project_id":"project-2",
     "overwrite_destination_table":"true"
     }'

El comando se ejecutará correctamente. Mientras tanto, la configuración de transferencia se crea correctamente para iniciar la operación de copia del conjunto de datos. La copia del conjunto de datos fallará y se mostrará un incumplimiento de los Controles del servicio de VPC.

Para encontrar los detalles del incumplimiento de los Controles del servicio de VPC correspondientes, revisa los registros en project-2 (proyecto del conjunto de datos de origen) con la siguiente consulta de registro. La consulta de registro filtra los registros del servicio de BigQuery y el nombre de recurso del conjunto de datos que se copia (codelab_bqtransfer_dataset).

resource.labels.service="bigquery.googleapis.com"
protoPayload.metadata.resourceNames:"datasets/codelab_bqtransfer_dataset"

El incumplimiento observado de los Controles del servicio de VPC es un incumplimiento de salida de project-2 a project-1.

egressViolations: [
  0: {
   servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
   source: "projects/[PROJECT-2-NUMBER]"
   sourceType: "Resource"
   targetResource: "projects/[PROJECT-1-NUMBER]"
   targetResourcePermissions: [
     0: "bigquery.transfers.update"
     1: "bigquery.transfers.get"
     2: "bigquery.jobs.create"
     ]
   }
]
method: "bigquery.tables.getData"
service: "bigquery.googleapis.com"

Corrige todos los incumplimientos de BigQuery y vuelve a iniciar la copia del conjunto de datos

Cuando se realiza una copia de un conjunto de datos de BigQuery entre proyectos que no están en el mismo perímetro de servicio, la regla de entrada/salida debe permitir todos los métodos para que el proceso funcione. Es posible que este comportamiento cambie en el futuro. Puedes hacer un seguimiento de las actualizaciones en el registrador de problemas público.

Para corregir la infracción de salida, debemos crear una regla de salida que permita el principal denegado. El principal denegado es el que ejecuta el comando mk.

Una vez que se implemente la regla de salida, en el perímetro perimeter-2, ejecuta el mismo comando para copiar el conjunto de datos. Esta vez, debería copiar el conjunto de datos correctamente sin infringir los Controles del servicio de VPC.

7. Limpieza

Si bien no se cobra por separado el uso de los Controles del servicio de VPC cuando el servicio no está en uso, se recomienda limpiar la configuración que se usó en este laboratorio. También puedes borrar la instancia de VM o los proyectos de Cloud para evitar que se generen cargos. Si borras el proyecto de Cloud, se detendrá la facturación de todos los recursos que se usen en él.

• Para borrar el bucket de Cloud Storage, completa los siguientes pasos:
  • En la consola de Google Cloud, ve a la página Buckets de Cloud Storage.
  • Selecciona la casilla de verificación del bucket que quieres borrar y, luego, haz clic en Borrar.
  • En la ventana de superposición que aparece, confirma que deseas borrar el bucket y su contenido.
• Para borrar el conjunto de datos de BigQuery, completa los siguientes pasos:
  • En la consola de Google Cloud, ve a la página de BigQuery.
  • En el panel Explorador, expande tu proyecto y elige un conjunto de datos.
  • Expande el menú de tres puntos y haz clic en Borrar.
  • En el cuadro de diálogo Borrar conjunto de datos, escribe delete en el campo y, luego, haz clic en Borrar.
• Para borrar el perímetro de servicio, completa los siguientes pasos:
  • En la consola de Google Cloud, selecciona Seguridad y, luego, Controles del servicio de VPC en el nivel en el que se aplica el alcance de la política de acceso, en este caso, a nivel de la carpeta.
  • En la página Controles del servicio de VPC, en la fila de la tabla correspondiente al perímetro que deseas borrar, selecciona Delete Icon.
• Para borrar el nivel de acceso, completa los siguientes pasos:
  • En la consola de Google Cloud, abre la página Access Context Manager en el alcance de la carpeta.
  • En la cuadrícula, identifica la fila del nivel de acceso que quieres borrar, selecciona el menú de tres puntos y, luego, Borrar.
• Para cerrar los proyectos, completa los siguientes pasos:
  • En la consola de Google Cloud, ve a la página Configuración de IAM y administración del proyecto que deseas borrar.
  • En la página Configuración de IAM y administración, selecciona Cerrar.
  • Ingresa el ID del proyecto y selecciona Cerrar de todos modos.

8. ¡Felicitaciones!

En este codelab, creaste un perímetro de Controles del servicio de VPC, lo aplicaste y solucionaste problemas relacionados con él.

Más información

También puedes explorar las siguientes situaciones:

• Agrega project-1 en un perímetro diferente que también proteja BigQuery, el Servicio de transferencia de datos de BigQuery y Cloud Storage.
• Realiza la transferencia de datos de BigQuery desde otras fuentes compatibles.
• Restringir el acceso de los usuarios según otros atributos, como la ubicación o la política del dispositivo

Licencia

Este trabajo cuenta con una licencia Atribución 2.0 Genérica de Creative Commons.