Seguridad y permisos de Dataflow

Puedes ejecutar canalizaciones de Dataflow de forma local 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 VMs de Dataflow
  • Roles y permisos necesarios para ejecutar canalizaciones locales y de Google Cloud
  • Roles y permisos obligatorios para acceder a los recursos de canalización
  • 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 Google Cloud. 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.

Las canalizaciones locales pueden enviar datos a destinos locales, como archivos locales, o a destinos de la nube, como Cloud Storage o BigQuery. Si una canalización ejecutada de forma local escribe archivos en recursos basados en la nube, como Cloud Storage, esta utiliza las credenciales de tu cuenta de Google Cloud y el proyecto de Google Cloud que configuraste como opción predeterminada Google Cloud CLI. Para obtener instrucciones sobre cómo autenticar con las credenciales de tu cuenta de Google Cloud, consulta la guía de inicio rápido del lenguaje que usas: Guía de inicio rápido de Java, Guía de inicio rápido de Python o Guía de inicio rápido de Go.

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. Como práctica recomendada, te sugerimos que especifiques una cuenta de servicio administrada por el usuario en lugar de usar la cuenta de servicio de trabajador predeterminada.

Para actuar como la cuenta de servicio, la cuenta que inicia la canalización 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. Si eres propietario o editor de un proyecto, ya tienes los permisos que contiene el rol roles/dataflow.developer.

Prácticas recomendadas

  • Cuando sea posible, para la cuenta de servicio de trabajador, especifica una cuenta de servicio administrada por el usuario en lugar de usar la cuenta de servicio de trabajador predeterminada.
  • Cuando otorgues permisos sobre los recursos, otorga el rol que contiene los permisos mínimos necesarios para la tarea. Puedes crear un rol personalizado que incluya solo los permisos necesarios.
  • Cuando otorgues roles para acceder a los recursos, usa el nivel de recurso más bajo posible. Por ejemplo, en lugar de otorgar el rol roles/bigquery.dataEditor en un proyecto o carpeta, otorga el rol en la tabla de BigQuery.
  • Crea un bucket que sea propiedad del proyecto para usarlo como bucket de etapa de pruebas de Dataflow. Los permisos predeterminados del bucket permiten que Dataflow use el bucket para almacenar en etapa intermedia los archivos ejecutables de la canalización.

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.

Console

  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.

CLI de gcloud

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 automáticamente 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 ejecutar un trabajo, debe tener el rol roles/dataflow.worker.
  • Para que la cuenta de servicio de trabajador pueda crear o examinar un trabajo, debe tener el rol roles/dataflow.admin.

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 en la tabla de BigQuery. Los siguientes son algunos ejemplos de recursos:

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.

Aunque puedes usar la cuenta de servicio predeterminada de Compute Engine como la cuenta de servicio de trabajador de Dataflow, te recomendamos que crees una cuenta de servicio de trabajador dedicada de Dataflow que solo tenga los roles y los permisos que necesitas.

Según la configuración de la política de la organización, es posible que a la cuenta de servicio predeterminada se le otorgue automáticamente el rol de editor en tu proyecto. Te recomendamos inhabilitar la concesión automática de roles; para ello, aplica la restricción de la política de la organización iam.automaticIamGrantsForDefaultServiceAccounts. Si creaste tu organización después del 3 de mayo de 2024, esta restricción se aplica de forma predeterminada.

Si inhabilitas la concesión automática de roles, debes decidir qué roles se deben otorgar a las cuentas de servicio predeterminadas y, luego, otorgar estos roles a ti mismo.

Si la cuenta de servicio predeterminada ya tiene el rol de editor, te recomendamos que reemplaces el rol de editor por roles menos permisivos. Para modificar de forma segura los roles de la cuenta de servicio, usa Policy Simulator para ver el impacto del cambio y, luego, otorga y revoca los roles adecuados.

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 los roles de IAM necesarios para tu cuenta de servicio.

    • Para que la cuenta de servicio de trabajador pueda ejecutar un trabajo, debe tener el rol roles/dataflow.worker.
    • Para que la cuenta de servicio de trabajador pueda crear o examinar un trabajo, debe tener el rol roles/dataflow.admin.
    • Como alternativa, crea un rol de IAM personalizada con los permisos necesarios. Para obtener una lista de los permisos necesarios, consulta Roles.
    • 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 desde BigQuery, la cuenta de servicio también debe tener por lo menos el rol roles/bigquery.dataViewer en la tabla de BigQuery.
    • 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. En el proyecto que contiene la cuenta de servicio del trabajador administrada por el usuario, la cuenta de servicio de Dataflow (service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com) y el agente de servicio de Compute Engine (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com) deben tener los siguientes roles. PROJECT_NUMBER es el ID del proyecto en el que se ejecuta tu trabajo de Dataflow. Ambas cuentas son agentes de servicio.

    En el proyecto en el que se ejecuta tu trabajo de Dataflow, las cuentas tienen estos roles de forma predeterminada. Si la cuenta de servicio de trabajador administrada por el usuario y el trabajo están en proyectos diferentes, también otorga estos roles a las cuentas de servicio administradas por Google que usa la cuenta de servicio de trabajador administrada por el usuario. Para otorgar estos roles, sigue los pasos de la sección Otorga un rol único en la página Administrar el acceso a las cuentas de servicio.

  4. Cuando la cuenta de servicio de trabajador administrada por el usuario y el trabajo estén en proyectos diferentes, asegúrate de que la restricción booleana iam.disableCrossProjectServiceAccountUsage no se aplique al proyecto que posee la cuenta de servicio administrada por el usuario. Si deseas obtener más información, consulta Habilita cuentas de servicio para conectarlas entre proyectos.

  5. 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.

Agregar roles

Para agregar roles en tu proyecto, sigue estos pasos.

Console

  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 tu cuenta de servicio de trabajador, haz clic en Editar principal y, luego, en Agregar otro rol.

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

  7. Si tu cuenta de servicio de trabajador necesita el rol de administrador de Dataflow, repite el proceso para el administrador de Dataflow.

  8. Repite los pasos para 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.

CLI de gcloud

  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 de trabajador. Ejecuta el siguiente comando para el rol roles/dataflow.worker de IAM y cualquier rol que requieran los recursos usados en tu trabajo. Si tu cuenta de servicio de trabajador necesita el rol de administrador de Dataflow, repite el proceso para el rol de IAM roles/dataflow.admin. En este ejemplo, se usa la cuenta de servicio predeterminada de Compute Engine, pero recomendamos usar una cuenta de servicio administrada por el usuario.

    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.

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 Google y administradas por Google o con claves de encriptación administradas por el cliente. Artifact Registry usa claves de Google y 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: Es el rol de IAM, por ejemplo, storage.objectViewer.

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, ya sea 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 los roles de IAM de BigQuery incluyen el permiso bigquery.datasets.get, pero la función roles/bigquery.jobUser es una excepción.

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 la consola de Google Cloud.

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.