Seguridad y permisos de Dataflow

Las canalizaciones de Dataflow se pueden ejecutar de forma local (para hacer pruebas en conjuntos de datos pequeños) o en recursos administrados de Google Cloud con el servicio administrado de Dataflow. Si se ejecuta de forma local o en la nube, la canalización y sus trabajadores usan un sistema de permisos para mantener un acceso seguro a los archivos y recursos de la canalización. Los permisos de Dataflow se asignan de acuerdo con la función que se usa para acceder a los recursos de la canalización. En este documento, se explican los siguientes conceptos:

  • Actualiza VM de Dataflow
  • Funciones y permisos necesarios para ejecutar canalizaciones locales y de Google Cloud.
  • Funciones y permisos obligatorios para acceder a los recursos de canalización en todos los proyectos.
  • Tipos de datos que se usan en un servicio de Dataflow y en seguridad de datos.

Antes de comenzar

Obtén información de los identificadores de proyectos de Google Cloud en la Descripción general de la plataforma. Estos identificadores incluyen el nombre, ID y número del proyecto.

Actualiza y aplica parches a las VM de Dataflow

Dataflow usa Container-Optimized OS. Por lo tanto, los procesos de seguridad de Container-Optimized OS también se aplican a Dataflow.

Las canalizaciones por lotes tienen un límite de tiempo y no requieren mantenimiento. Cuando se inicia una canalización por lotes nueva, se usa la imagen de Dataflow más reciente.

En las canalizaciones de transmisión, si se requiere un parche de seguridad de inmediato, Google Cloud te notifica con boletines de seguridad. En el caso de las canalizaciones de transmisión, te recomendamos que uses la opción --update para reiniciar tu trabajo con la última imagen de Dataflow.

Las imágenes de contenedor de Dataflow están disponibles en la consola de Google Cloud.

Seguridad y permisos para canalizaciones locales

De forma local, la canalización de Apache Beam se ejecuta con la cuenta de Google Cloud que configuraste con el archivo ejecutable de Google Cloud CLI. Por lo tanto, las operaciones del SDK de Apache Beam que se ejecutan de manera local y tu cuenta de Google Cloud tienen acceso a los mismos archivos y recursos.

Para mostrar la cuenta de Google Cloud que seleccionaste como predeterminada, ejecuta el comando gcloud config list.

Seguridad y permisos para canalizaciones en Google Cloud

Cuando ejecutas la canalización, Dataflow usa dos cuentas de servicio para administrar la seguridad y los permisos:

  • La cuenta de servicio de Dataflow. El servicio de Dataflow usa su cuenta de servicio como parte de la solicitud de creación de trabajo (por ejemplo, para verificar la cuota del proyecto y crear instancias de trabajadores en tu nombre). Dataflow también usa la cuenta de servicio de Dataflow durante la ejecución del trabajo para administrarlo. Esta cuenta también se conoce como agente de servicio de Dataflow.

  • La cuenta de servicio de trabajador. Las instancias de trabajador usan la cuenta de servicio de trabajador para acceder a los recursos de entrada y salida después de que envías el trabajo. De forma predeterminada, los trabajadores usan la cuenta de servicio predeterminada de Compute Engine asociada con tu proyecto como la cuenta de servicio de trabajador. Para que la cuenta de servicio de trabajador pueda crear, ejecutar y examinar un trabajo, debe tener los siguientes roles:

    • roles/dataflow.admin
    • roles/dataflow.worker

Además, cuando las canalizaciones de Apache Beam acceden a los recursos de Google Cloud, debes otorgar los roles necesarios a la cuenta de servicio de trabajador del proyecto de Dataflow. La cuenta de servicio de trabajador debe poder acceder a los recursos mientras ejecuta el trabajo de Dataflow. Por ejemplo, si un trabajo escribe en BigQuery, la cuenta de servicio también debe tener por lo menos el rol roles/bigquery.dataEditor. Entre los ejemplos de recursos se incluyen los siguientes:

Por último, para actuar en nombre de la cuenta de servicio, la cuenta de usuario debe tener el siguiente rol: iam.serviceAccounts.actAs. Según otros permisos del proyecto, es posible que tu cuenta de usuario también necesite el rol roles/dataflow.developer.

Para agregar los roles necesarios a tu proyecto, sigue estos pasos.

Consola

  1. En la consola de Google Cloud, ve a la página IAM.

    Ir a IAM

  2. Selecciona tu proyecto.

  3. En la fila que contiene tu cuenta de usuario, haz clic en Editar principal y, luego, en Agregar otro rol.

  4. En la lista desplegable, selecciona el rol Usuario de cuenta de servicio.

  5. En la fila que contiene la cuenta de servicio predeterminada de Compute Engine, haz clic en Editar principal y, luego, en Agregar otro rol.

  6. En la lista desplegable, selecciona el rol Trabajador de Dataflow.

  7. Repite los pasos para el Administrador de Dataflow y los roles que requieren los recursos usados en tu trabajo y, luego, haz clic en Guardar.

    Para obtener más información para otorgar roles, consulta Otorga un rol de IAM con la consola.

gcloud CLI

  1. Otorga el rol roles/iam.serviceAccountUser a la cuenta de usuario. Ejecute el siguiente comando:

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS --role=roles/iam.serviceAccountUser
    
    • Reemplaza PROJECT_ID con el ID del proyecto.
    • Reemplaza EMAIL_ADDRESS por la dirección de correo electrónico de la cuenta del usuario.
  2. Otorga roles a tu cuenta de servicio predeterminada de Compute Engine. Ejecuta el siguiente comando una vez para cada uno de los siguientes roles de IAM: roles/dataflow.admin, roles/dataflow.worker y cualquier rol que requieran los recursos usados en tu trabajo.

    gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" --role=SERVICE_ACCOUNT_ROLE
    
    • Reemplaza PROJECT_ID con el ID del proyecto.
    • Reemplaza PROJECT_NUMBER por el número del proyecto. Para encontrar el número de tu proyecto, consulta Identifica proyectos o usa el comando gcloud projects describe.
    • Reemplaza SERVICE_ACCOUNT_ROLE por cada rol individual.

Cuenta de servicio de Dataflow

Todos los proyectos que usaron el recurso Dataflow Job tienen una cuenta de servicio de Dataflow, también conocida como agente de servicio de Dataflow, que tiene el siguiente correo electrónico:

service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com

Google crea y administra esta cuenta de servicio, y se asigna a tu proyecto de forma automática cuando se usa por primera vez el recurso Dataflow Job.

Como parte de la ejecución de la canalización de Dataflow, este servicio manipula los recursos en tu nombre. Por ejemplo, crea VMs adicionales. Cuando ejecutas tu canalización en el servicio de Dataflow, el servicio usa esta cuenta de servicio.

A esta cuenta se le asigna la función de agente de servicio de Dataflow en el proyecto. Tiene los permisos necesarios para ejecutar un trabajo de Dataflow en el proyecto, incluido el inicio de los trabajadores de Compute Engine. Este servicio de Dataflow usa la cuenta de forma exclusiva, la cual es específica para el proyecto.

Puedes revisar los permisos de la cuenta de servicio de Dataflow en la consola de Google Cloud o Google Cloud CLI.

Consola

  1. Ir a la página Funciones

    Ir a Perfiles

  2. Si corresponde, selecciona tu proyecto.

  3. En la lista, haz clic en el título Agente de servicios de Cloud Dataflow. Se abrirá una página que enumera los permisos asignados a la cuenta de servicio de Dataflow.

gcloud CLI

Visualiza los permisos de la cuenta de servicio de Dataflow:

gcloud iam roles describe roles/dataflow.serviceAgent

Debido a que los servicios de Google Cloud esperan tener acceso de lectura y escritura al proyecto y a sus recursos, te recomendamos que no cambies los permisos predeterminados que se establecieron de manera automática en el proyecto. Si una cuenta de servicio de Dataflow pierde los permisos de un proyecto, no puede iniciar las VM ni realizar otras tareas de administración.

Si quitas los permisos para la cuenta de servicio de la política de Identity and Access Management (IAM), la cuenta seguirá presente porque es propiedad del servicio de Dataflow.

Cuenta de servicio de trabajador

Las instancias de Compute Engine ejecutan las operaciones del SDK de Apache Beam en la nube. Estos trabajadores usan la cuenta de servicio de trabajador de tu proyecto para acceder a los archivos y a otros recursos asociados con la canalización. La cuenta de servicio de trabajador se usa como identidad para todas las VMs de trabajador, y todas las solicitudes que se originan en la VM usan la cuenta de servicio de trabajador. Esta cuenta de servicio también se usa para interactuar con recursos como los buckets de Cloud Storage y los temas de Pub/Sub.

Para que la cuenta de servicio de trabajador pueda crear, ejecutar y examinar un trabajo, debe tener los siguientes roles:

  • roles/dataflow.admin
  • roles/dataflow.worker

Cuenta de servicio de trabajador predeterminada

De forma predeterminada, los trabajadores usan la cuenta de servicio predeterminada de Compute Engine de tu proyecto como la cuenta de servicio del trabajador. Esta cuenta de servicio tiene el siguiente correo electrónico:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Esta cuenta de servicio se crea de forma automática cuando habilitas la API de Compute Engine en el proyecto desde la biblioteca de APIs de la consola de Google Cloud.

La cuenta de servicio predeterminada de Compute Engine tiene un acceso amplio a los recursos de tu proyecto, lo que te ayuda a comenzar a usar Dataflow. Sin embargo, para las cargas de trabajo de producción, te recomendamos que crees una cuenta de servicio nueva solo con las funciones y los permisos que necesitas.

Especifica una cuenta de servicio de trabajador administrada por el usuario

Si deseas crear y usar recursos con un control de acceso detallado, puedes crear una cuenta de servicio administrada por el usuario. Usa esta cuenta como la cuenta de servicio de trabajador.

  1. Si no tienes una cuenta de servicio administrada por el usuario, primero crea una cuenta de servicio.

  2. Configura las funciones de IAM necesarias para tu cuenta de servicio.

    • Para que la cuenta de servicio pueda crear, ejecutar y examinar un trabajo, debe tener los roles roles/dataflow.admin y roles/dataflow.worker, o un rol de IAM personalizado con los permisos requeridos para esos roles. Para obtener una lista de los permisos necesarios, consulta Roles.
    • Además, es posible que esta cuenta de servicio necesite roles adicionales para usar los recursos de Google Cloud que solicita tu trabajo, como BigQuery, Pub/Sub o Cloud Storage. Por ejemplo, si un trabajo lee datos de BigQuery, la cuenta de servicio también debe tener por lo menos el rol roles/bigquery.dataViewer.
    • Además, asegúrate de que la cuenta de servicio administrada por el usuario tenga acceso de lectura y escritura a las ubicaciones de etapa de pruebas y temporales especificadas en el trabajo de Dataflow.
    • Para actuar como la cuenta de servicio, la cuenta de usuario debe tener el permiso iam.serviceAccounts.actAs.
  3. Otorga los siguientes roles a la cuenta de servicio de Dataflow (service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com) y al agente de servicio de Compute Engine (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com). Ambas son cuentas de servicio administradas por Google en la cuenta de servicio administrada por el usuario. Estas cuentas están en el mismo proyecto que la cuenta de servicio administrada por el usuario, incluso si el trabajo de Dataflow se ejecuta en un proyecto diferente.

    Para obtener instrucciones para otorgar roles a cuentas de servicio, consulta la sección Otorga un rol único en la página Administrar el acceso a las cuentas de servicio.

  4. Cuando ejecutes el trabajo de canalización, especifica tu cuenta de servicio.

    Java

    Usa la opción --serviceAccount y especifica tu cuenta de servicio cuando ejecutes el trabajo de canalización desde la línea de comandos: --serviceAccount=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Usa la opción --service-account-email y especifica tu cuenta de servicio cuando ejecutes el trabajo de canalización como una plantilla de Flex: --service-account-email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Python

    Usa la opción --service_account_email y especifica tu cuenta de servicio cuando ejecutes el trabajo de canalización: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Go

    Usa la opción --service_account_email y especifica tu cuenta de servicio cuando ejecutes el trabajo de canalización: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

Puedes obtener una lista de las cuentas de servicio asociadas a tu proyecto desde la página de permisos en la consola de Google Cloud.

La cuenta de servicio administrada por el usuario puede estar en el mismo proyecto que tu trabajo o en otro. Si la cuenta de servicio y el trabajo están en proyectos diferentes, debes configurar la cuenta de servicio antes de ejecutar el trabajo.

Accede a recursos de Google Cloud

Tus canalizaciones de Apache Beam pueden acceder a los recursos de Google Cloud, ya sea en el mismo proyecto de Google Cloud o en otros. Entre estos recursos, se incluyen los siguientes:

Para asegurarte de que la canalización de Apache Beam pueda acceder a estos recursos, es posible que debas usar los mecanismos respectivos de control de acceso de los recursos para otorgar acceso de forma explícita a la cuenta de servicio de trabajador de tu proyecto de Dataflow.

Si usas funciones de Assured Workloads con Dataflow, como regiones de la UE y compatibilidad con controles de soberanía, todos Cloud Storage, BigQuery, Pub/Sub, conectores E/S y otros recursos a los que accede la canalización deben estar ubicados en el proyecto o carpeta de Assured Workloads de tu organización.

Si usas una cuenta de servicio de trabajador administrada por el usuario o accedes a recursos en otros proyectos, es posible que se necesite una acción adicional. En los siguientes ejemplos, se supone que se usa la cuenta de servicio predeterminada de Compute Engine, pero también puedes usar una cuenta de servicio de trabajador administrada por el usuario.

Accede a los repositorios de Artifact Registry

Cuando usas contenedores personalizados con Dataflow, puedes subir artefactos a un repositorio de Artifact Registry.

Para usar Artifact Registry con Dataflow, debes otorgar al menos el acceso de escritor de Artifact Registry (role/artifactregistry.writer) a la cuenta de servicio de trabajador que ejecuta el trabajo de Dataflow.

Todo el contenido del repositorio se encripta con claves de encriptación administradas por Google o administradas por el cliente. Artifact Registry usa claves de encriptación administradas por Google de forma predeterminada y no se requiere ninguna configuración para esta opción.

Accede a buckets de Cloud Storage

Para que el proyecto de Dataflow tenga acceso a un bucket de Cloud Storage, haz que la cuenta de servicio de trabajador del proyecto de Dataflow tenga acceso al bucket. Como mínimo, tu cuenta de servicio necesita permisos de lectura y escritura para el bucket y su contenido. Puedes usar los permisos de IAM para Cloud Storage a fin de otorgar el acceso requerido.

Para otorgar a tu cuenta de servicio de trabajador los permisos necesarios para leer y escribir en un bucket, usa el comando gcloud storage buckets add-iam-policy-binding. Este comando agrega la cuenta de servicio del proyecto de Dataflow a una política a nivel del bucket.

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" --role=SERVICE_ACCOUNT_ROLE

Reemplaza lo siguiente:

  • BUCKET_NAME: Es el nombre de tu bucket de Cloud Storage.
  • PROJECT_NUMBER: el número de tu proyecto de Dataflow. Para encontrar el número de tu proyecto, consulta Identifica proyectos o usa el comando gcloud projects describe.
  • SERVICE_ACCOUNT_ROLE: el rol de IAM

Si tu cuenta de servicio necesita tener control total sobre los objetos de almacenamiento, lo que incluye enumerar, crear, visualizar y borrar objetos y carpetas administradas, otorga a tu cuenta de servicio el rol de Administrador de objetos de almacenamiento (roles/storage.objectAdmin).

Para recuperar una lista de los buckets de Cloud Storage en un proyecto de Google Cloud, usa el comando gcloud storage buckets list:

gcloud storage buckets list --project= PROJECT_ID

Reemplaza PROJECT_ID por el ID del proyecto.

A menos que estés restringido por políticas de la organización que limiten el uso compartido de recursos, puedes acceder a un bucket que resida en un proyecto diferente al de tu canalización de Dataflow. Para obtener más información sobre las restricciones de dominio, consulta Restringe identidades por dominio.

Si no tienes un bucket, crea uno nuevo. Luego, otórgale a tu cuenta de servicio de trabajador los permisos necesarios para leer y escribir en el bucket.

Sugerencia: También puedes configurar los permisos del bucket en la consola de Google Cloud. Para obtener más información, consulta Configura los permisos de bucket.

Cloud Storage ofrece dos sistemas para otorgar permiso a los usuarios a fin de acceder a tus buckets y objetos: IAM y las listas de control de acceso (LCA). En la mayoría de los casos, IAM es el método recomendado para controlar el acceso a los recursos.

  • IAM controla los permisos en todo Google Cloud y te permite otorgarlos a nivel de bucket y proyecto. Si deseas obtener una lista de los roles de IAM asociados con Cloud Storage y los permisos que contiene cada rol, consulta Roles de IAM para Cloud Storage. Si necesitas más control sobre los permisos, crea un rol personalizado.

  • Si usas las LCA para controlar el acceso, asegúrate de que los permisos de tu cuenta de servicio de trabajador sean coherentes con la configuración de IAM. Debido a la inconsistencia que hay entre las políticas de IAM y LCA, el bucket de Cloud Storage puede ser inaccesible para tus trabajos de Dataflow cuando el bucket de Cloud Storage se migra desde un acceso detallado hasta un nivel uniforme de bucket acceso Para obtener más información, consulta Guía de errores comunes.

Accede a los conjuntos de datos de BigQuery

Puedes usar la API de BigQueryIO para acceder a los conjuntos de datos de BigQuery en el mismo proyecto en el que usas Dataflow o en uno diferente. Para que la fuente y el receptor de BigQuery funcionen de forma correcta, las siguientes dos cuentas deben tener acceso a todos los conjuntos de datos de BigQuery en los que lee o escribe datos el trabajo de Dataflow:

Podrías necesitar configurar BigQuery para otorgar acceso explícito a estas cuentas. Obtén más información en Control de acceso a BigQuery para otorgar acceso a los conjuntos de datos de BigQuery con la página de BigQuery o la API de BigQuery.

Entre los permisos necesarios de BigQuery, la canalización requiere el permiso bigquery.datasets.get de IAM para acceder a un conjunto de datos de BigQuery. Por lo general, la mayoría de las funciones de IAM de BigQuery incluyen el permiso bigquery.datasets.get, pero la función roles/bigquery.jobUser es una excepción.

Por ejemplo, si tu cuenta de Google Cloud es cloudysanfrancisco@gmail.com y el número del proyecto en el que ejecutas el trabajo de Dataflow es 123456789, estas dos cuentas deben tener acceso a los conjuntos de datos de BigQuery utilizados: cloudysanfrancisco@gmail.com y 123456789-compute@developer.gserviceaccount.com.

Accede a las suscripciones y los temas de Pub/Sub

Si deseas acceder a un tema o una suscripción de Pub/Sub, usa las funciones de Identity and Access Management de Pub/Sub para configurar permisos para la cuenta de servicio de trabajador.

Se requieren los permisos de los siguientes roles de Pub/Sub:

  • roles/pubsub.subscriber es obligatorio para consumir datos.
  • roles/pubsub.editor es obligatorio para crear una suscripción a Pub/Sub.
  • roles/pubsub.viewer se recomienda para que Dataflow pueda consultar las configuraciones de los temas y las suscripciones. Esta configuración tiene dos beneficios:
    • Dataflow puede verificar la configuración no admitida en suscripciones que podrían no funcionar como se espera.
    • Si la suscripción no usa el plazo de confirmación predeterminado de 10 segundos, el rendimiento mejora. Dataflow extiende el plazo de confirmación de un mensaje de forma repetida mientras la canalización lo procesa. Sin los permisos pubsub.viewer, Dataflow no puede consultar el plazo de confirmación y, por lo tanto, debe suponer un plazo predeterminado. Esta configuración hace que Dataflow emita más solicitudes de modifyAckDeadline de las necesarias.
    • Si los Controles del servicio de VPC están habilitados en el proyecto que posee la suscripción o el tema, las reglas de entrada basadas en direcciones IP no permiten que Dataflow consulte las configuraciones. En este caso, se requiere una regla de entrada basada en la cuenta de servicio de trabajador.

Para obtener más información y algunos ejemplos de código que demuestran cómo usar las funciones de Identity and Access Management de Pub/Sub, consulta el caso de uso de muestra: comunicación entre proyectos.

Accede a Firestore

Para acceder a una base de datos de Firestore (en modo nativo o modo Datastore), agrega la cuenta de servicio de trabajador de Dataflow (por ejemplo, PROJECT_NUMBER-compute@developer.gserviceaccount.com) como editor del proyecto que posee la base de datos o usa un rol de Datastore más restrictivo, como roles/datastore.viewer. Además, habilita la API de Firestore en ambos proyectos desde la biblioteca de API en Google Cloud Console.

Accede a las imágenes de proyectos con una política de imágenes confiables

Si tienes una política de imágenes confiables configurada para tu proyecto y tu imagen de arranque se encuentra en otro proyecto, asegúrate de que la política de imágenes confiables esté configurada para tener acceso a la imagen. Por ejemplo, si ejecutas un trabajo de Dataflow con plantilla, asegúrate de que el archivo de políticas incluya acceso al proyecto dataflow-service-producer-prod. Este es un proyecto de Google Cloud que contiene las imágenes para los trabajos de plantilla.

Seguridad y acceso de datos

El servicio de Dataflow funciona con dos tipos de datos:

  • Datos del usuario final. Una canalización de Dataflow procesa estos datos. Una canalización típica lee datos de una o más fuentes, implementa transformaciones de estos y escribe los resultados en uno o más receptores. Todas las fuentes y receptores son servicios de almacenamiento que Dataflow no administra de forma directa.

  • Datos operativos. Estos datos incluyen todos los metadatos necesarios para administrar una canalización de Dataflow. Estos datos incluyen metadatos proporcionados por el usuario, como un nombre de trabajo u opciones de canalización, y metadatos generados por el sistema, como un ID de tarea.

Para mantener la seguridad y la privacidad de los datos, el servicio de Dataflow usa varios mecanismos de seguridad, que se aplican en las siguientes situaciones:

  • Envía una canalización al servicio
  • Evalúa una canalización
  • Solicitar acceso a telemetría y métricas durante y después de una ejecución de canalización
  • Usar un servicio de Dataflow como Shuffle o Streaming Engine

Localidad de datos

Todo el procesamiento de datos principal del servicio de Dataflow ocurre en la región que se especifica en el código de la canalización. Si no se especifica una región, se usa la región predeterminada us-central1. Si especificas esa opción en el código de la canalización, el trabajo de canalización puede leer y escribir de forma opcional desde fuentes y receptores en otras regiones. Sin embargo, el procesamiento de datos real ocurre solo en la región que se especifica para ejecutar las VM de Dataflow.

La lógica de canalización se evalúa en instancias de VM de trabajador individuales. Puedes especificar la zona donde se ubican esas instancias y las redes privadas a través de las cuales se comunican. Los cálculos complementarios de la plataforma dependen de metadatos como las ubicaciones de Cloud Storage o los tamaños de archivo.

Dataflow es un servicio regional. Para obtener más información sobre la localidad y las regiones de los datos, consulta Regiones de Dataflow.

Datos en un envío de canalización

Los permisos de IAM para el proyecto de Google Cloud controlan el acceso al servicio de Dataflow. Cualquier principal que tenga derechos de editor o propietario para tu proyecto puede enviar canalizaciones al servicio. Para enviar canalizaciones, debes autenticarte con Google Cloud CLI. Después de la autenticación, las canalizaciones se envían con el protocolo HTTPS. Consulta la guía de inicio rápido del lenguaje que usas para obtener instrucciones para autenticar con las credenciales de tu cuenta de Google Cloud.

Datos en una evaluación de canalización

Como parte de la evaluación de la canalización, los datos temporales se podrían generar y almacenar localmente en las instancias de VM de trabajador o en Cloud Storage. Los datos temporales se encriptan en reposo y no se conservan después de que termina una evaluación de canalización. Estos datos también se pueden almacenar en el servicio Shuffle o el servicio de Streaming Engine (si habilitaste el servicio) en la misma región que se especificó en la canalización de Dataflow.

Java

De forma predeterminada, se borran las VMs de Compute Engine cuando finaliza el trabajo de Dataflow, sin importar si se realizó de forma correcta o falló. En consecuencia, se borra el disco persistente asociado junto con todos los datos intermedios que podrían estar almacenados en él. Los datos intermedios almacenados en Cloud Storage se pueden encontrar en sububicaciones de la ruta de Cloud Storage que proporcionas como --stagingLocation o --tempLocation. Si escribes datos de salida en un archivo de Cloud Storage, se podrían crear archivos temporales en la ubicación de salida antes de que finalice la operación de escritura.

Python

De forma predeterminada, se borran las VMs de Compute Engine cuando finaliza el trabajo de Dataflow, sin importar si se realizó de forma correcta o falló. En consecuencia, se borra el disco persistente asociado junto con todos los datos intermedios que podrían estar almacenados en él. Los datos intermedios almacenados en Cloud Storage se pueden encontrar en sububicaciones de la ruta de Cloud Storage que proporcionas como --staging_location o --temp_location. Si escribes datos de salida en un archivo de Cloud Storage, se podrían crear archivos temporales en la ubicación de salida antes de que finalice la operación de escritura.

Go

De forma predeterminada, se borran las VMs de Compute Engine cuando finaliza el trabajo de Dataflow, sin importar si se realizó de forma correcta o falló. En consecuencia, se borra el disco persistente asociado junto con todos los datos intermedios que podrían estar almacenados en él. Los datos intermedios almacenados en Cloud Storage se pueden encontrar en sububicaciones de la ruta de Cloud Storage que proporcionas como --staging_location o --temp_location. Si escribes datos de salida en un archivo de Cloud Storage, se podrían crear archivos temporales en la ubicación de salida antes de que finalice la operación de escritura.

Datos en registros de canalización y telemetría

El código del programa de Dataflow genera casi toda la información que se almacena en Cloud Logging. El servicio de Dataflow también podría generar datos de advertencia y error en Cloud Logging. Sin embargo, estos son los únicos datos intermedios que agrega el servicio a los registros. Cloud Logging es un servicio global.

Los datos de telemetría y las métricas asociadas se encriptan en reposo, y el acceso a estos datos se controla con los permisos de lectura del proyecto de Google Cloud.

Datos en servicios de Dataflow

Si usas Dataflow Shuffle o Dataflow Streaming para la canalización, no especifiques las opciones de canalización de zona. En su lugar, especifica la región y establece el valor en una de las regiones en las que Shuffle o Streaming estén disponibles. Dataflow selecciona de forma automática la zona en la región que especifiques. Los datos del usuario final en tránsito permanecen dentro de las VM de trabajador y en la misma zona. Estos trabajos de Dataflow aún pueden leer y escribir en fuentes y receptores que están fuera de la zona de la VM. Los datos en tránsito también se pueden enviar a los servicios de Dataflow Shuffle o Dataflow Streaming. Sin embargo, los datos siempre permanecen en la región especificada en el código de la canalización.

Te recomendamos que uses los mecanismos de seguridad disponibles en los recursos subyacentes de la nube de la canalización. Estos mecanismos incluyen las capacidades de seguridad de los datos de las fuentes y los receptores de datos, como BigQuery y Cloud Storage. Además, te recomendamos que no mezcles niveles de confianza distintos en un solo proyecto.