Seguridad y permisos de Dataflow

Puedes ejecutar las canalizaciones de Dataflow de forma local o en recursos gestionados de Google Cloud Platform mediante el ejecutor de Dataflow. Tanto si ejecutas las canalizaciones de forma local como en la nube, tu canalización y sus trabajadores utilizan un sistema de permisos para mantener un acceso seguro a los archivos y recursos de la canalización. Los permisos de Dataflow se asignan en función del rol que se utilice para acceder a los recursos de la canalización. En este documento se explican los siguientes conceptos:

  • Actualizar máquinas virtuales de Dataflow
  • Roles y permisos necesarios para ejecutar flujos de trabajo locales y de Google Cloud Platform
  • Roles y permisos necesarios para acceder a los recursos de la canalización
  • Tipos de datos que se usan en un servicio de Dataflow y en la seguridad de los datos

Antes de empezar

Consulta información sobre los identificadores de proyectos de Google Cloud Platform en la descripción general de Google Cloud Platform. Estos identificadores incluyen el nombre, el ID y el número del proyecto.

Actualizar y aplicar parches a las VMs de Dataflow

Dataflow usa Container-Optimized OS. Los procesos de seguridad de Container-Optimized OS también se aplican a Dataflow.

Los flujos de procesamiento por lotes tienen un plazo y no requieren mantenimiento. Cuando se inicia un nuevo flujo de procesamiento por lotes, se usa la imagen de Dataflow más reciente.

En el caso de las canalizaciones de streaming, si se necesita un parche de seguridad de inmediato, Google Cloud te avisa mediante boletines de seguridad. En el caso de las canalizaciones de streaming, te recomendamos que uses la opción --update para reiniciar tu trabajo con la imagen de Dataflow más reciente.

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

Entorno de ejecución

Para el entorno de ejecución del código de usuario de la canalización, Dataflow usa una imagen de Apache Beam prediseñada o un contenedor personalizado si se ha proporcionado uno.

El servicio Dataflow selecciona el usuario para la ejecución del contenedor. Los recursos de la canalización se asignan por tarea. No se comparten máquinas virtuales ni otros recursos entre canalizaciones.

El ciclo de vida del entorno de ejecución está vinculado al ciclo de vida de la canalización. Se inicia al principio del flujo de procesamiento y se detiene al finalizarlo. El entorno de tiempo de ejecución se puede reiniciar una o varias veces durante la ejecución del flujo de procesamiento.

Seguridad y permisos de las canalizaciones locales

Cuando ejecutas el flujo de procesamiento de Apache Beam de forma local, este se ejecuta como laGoogle Cloud cuenta que configuraste con el ejecutable de la CLI de Google Cloud. Las operaciones del SDK de Apache Beam que se ejecutan localmente y tu cuenta tienen acceso a los mismos archivos y recursos. Google Cloud

Para ver la cuenta de Google Cloud que has seleccionado como predeterminada, ejecuta el comando gcloud config list.

Las canalizaciones locales pueden enviar datos a destinos locales, como archivos locales, o a destinos en la nube, como Cloud Storage o BigQuery. Si tu pipeline ejecutado localmente escribe archivos en recursos basados en la nube, como Cloud Storage, utiliza las credenciales de tu cuenta de Google Cloud y el proyecto de Google Cloud que hayas configurado como predeterminado en la CLI de Google Cloud. Para obtener instrucciones sobre cómo autenticarte con tus credenciales de cuenta de Google Cloud , consulta el tutorial del lenguaje que estés usando: Java, Python o Go.

Seguridad y permisos de las canalizaciones en Google Cloud

Cuando ejecutas tu flujo de procesamiento, Dataflow usa dos cuentas de servicio para gestionar la seguridad y los permisos:

  • La cuenta de servicio de Dataflow. El servicio Dataflow usa la cuenta de servicio de Dataflow como parte de la solicitud de creación de la tarea, por ejemplo, para comprobar la cuota del proyecto y crear instancias de trabajador en tu nombre. Dataflow también usa la cuenta de servicio de Dataflow durante la ejecución de la tarea para gestionarla. 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 enviar el trabajo. De forma predeterminada, los trabajadores usan la cuenta de servicio predeterminada de Compute Engine asociada a tu proyecto como cuenta de servicio de trabajador. Como práctica recomendada, te aconsejamos que especifiques una cuenta de servicio gestionada por el usuario en lugar de usar la cuenta de servicio de trabajador predeterminada.

Para suplantar la identidad de la cuenta de servicio, la cuenta que inicia la canalización debe tener el siguiente rol: iam.serviceAccounts.actAs.

En función de 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 incluye el rol roles/dataflow.developer.

Prácticas recomendadas

  • Cuando sea posible, en la cuenta de servicio de trabajador, especifica una cuenta de servicio gestionada por el usuario en lugar de usar la cuenta de servicio de trabajador predeterminada.
  • Cuando concedas permisos en los recursos, asigna el rol que contenga los permisos mínimos necesarios para la tarea. Puedes crear un rol personalizado que incluya solo los permisos necesarios.
  • Cuando concedas roles para acceder a los recursos, utiliza el nivel de recurso más bajo posible. Por ejemplo, en lugar de asignar el rol roles/bigquery.dataEditor a un proyecto o una carpeta, asigna el rol a la tabla de BigQuery.
  • Crea un bucket propiedad de tu proyecto para usarlo como bucket de almacenamiento provisional de Dataflow. Los permisos predeterminados del segmento permiten que Dataflow use el segmento para almacenar los archivos ejecutables del flujo de procesamiento.

Cuenta de servicio de Dataflow

Todos los proyectos que han usado 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:

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

Google crea y gestiona esta cuenta de servicio, que se asigna automáticamente a tu proyecto cuando usas por primera vez el recurso Dataflow Job.

Como parte de la ejecución de las canalizaciones de Dataflow, Dataflow manipula recursos en tu nombre. Por ejemplo, crea máquinas virtuales adicionales. Cuando ejecutas tu flujo de procesamiento con Dataflow, se usa esta cuenta de servicio.

A esta cuenta se le asigna el rol Agente de servicio de Dataflow en el proyecto. Tiene los permisos necesarios para ejecutar una tarea de Dataflow en el proyecto, incluido el inicio de los trabajadores de Compute Engine. Dataflow usa esta cuenta exclusivamente y es específica de tu proyecto.

Puedes consultar los roles asignados a la cuenta de servicio de Dataflow en laGoogle Cloud consola o en la CLI de Google Cloud.

Consola

  1. Ve a la página Roles.

    Ir a Roles

  2. Si procede, selecciona tu proyecto.

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

CLI de gcloud

Consulta los permisos de la cuenta de servicio de Dataflow:

gcloud iam roles describe roles/dataflow.serviceAgent

Como los Google Cloud servicios esperan tener acceso de lectura y escritura al proyecto y a sus recursos, te recomendamos que no cambies los permisos predeterminados que se han establecido automáticamente para tu proyecto. Si una cuenta de servicio de Dataflow pierde los permisos de un proyecto, Dataflow no podrá iniciar máquinas virtuales ni realizar otras tareas de gestión.

Si quitas los permisos de la cuenta de servicio de la política de Gestión de Identidades y Accesos (IAM), la cuenta seguirá presente, ya que es propiedad del servicio 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 otros recursos asociados a la canalización. La cuenta de servicio de trabajador se usa como identidad de todas las VMs de trabajador, y todas las solicitudes que proceden de la VM usan la cuenta de servicio de trabajador. Esta cuenta de servicio también se usa para interactuar con recursos como los contenedores 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 tus flujos de procesamiento de Apache Beam accedan a Google Cloud recursos, debes asignar los roles necesarios a la cuenta de servicio de trabajador de tu proyecto de Dataflow. La cuenta de servicio del trabajador debe poder acceder a los recursos mientras se ejecuta el trabajo de Dataflow. Por ejemplo, si tu trabajo escribe en BigQuery, tu cuenta de servicio también debe tener al menos el rol roles/bigquery.dataEditor en la tabla de BigQuery. Estos 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 cuenta de servicio de trabajador. Esta cuenta de servicio tiene el siguiente correo:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

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

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

En función de la configuración de la política de tu organización, es posible que se conceda automáticamente el rol Editor a la cuenta de servicio predeterminada de tu proyecto. Te recomendamos que inhabilites la asignación automática de roles aplicando la restricción de la política de organización iam.automaticIamGrantsForDefaultServiceAccounts. Si has creado tu organización después del 3 de mayo del 2024, esta restricción se aplica de forma predeterminada.

Si inhabilitas la concesión automática de roles, debes decidir qué roles quieres conceder a las cuentas de servicio predeterminadas y, a continuación, concederlos tú mismo.

Si la cuenta de servicio predeterminada ya tiene el rol Editor, te recomendamos que lo sustituyas por roles con menos permisos.Para modificar los roles de la cuenta de servicio de forma segura, usa Simulador de políticas para ver el impacto del cambio y, a continuación, asigna y revoca los roles adecuados.

Especificar una cuenta de servicio de trabajador gestionada por el usuario

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

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

  2. Define los roles de gestión de identidades y accesos 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.
    • También puedes crear un rol de IAM personalizado con los permisos necesarios. Para ver una lista de los permisos necesarios, consulta Roles.
    • Es posible que tu cuenta de servicio necesite roles adicionales para usar los recursos de Google Cloud Platform que requiera tu trabajo, como BigQuery, Pub/Sub o Cloud Storage. Por ejemplo, si tu trabajo lee datos de BigQuery, tu cuenta de servicio también debe tener al menos el rol roles/bigquery.dataViewer en la tabla de BigQuery.
    • Asegúrate de que tu cuenta de servicio gestionada por el usuario tenga acceso de lectura y escritura a las ubicaciones de almacenamiento provisional y temporales especificadas en el trabajo de Dataflow.
    • Para suplantar la identidad de la cuenta de servicio, tu cuenta de usuario debe tener el permiso iam.serviceAccounts.actAs.

  3. En el proyecto que contiene la cuenta de servicio de trabajador gestionada 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.

    Supongamos que el trabajo de Dataflow se está ejecutando en el proyecto A y que la cuenta de servicio de trabajador está alojada en el proyecto B. Asegúrate de que los agentes de servicio del proyecto A tengan los roles iam.serviceAccountTokenCreator y iam.serviceAccountUser en el proyecto B. En el proyecto en el que se ejecuta tu trabajo de Dataflow, las cuentas tienen estos roles de forma predeterminada. Para conceder estos roles, sigue los pasos que se indican en la sección Conceder un solo rol de la página Gestionar el acceso a cuentas de servicio.

  4. Si la cuenta de servicio de trabajador gestionada 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 propietario de la cuenta de servicio gestionada por el usuario. Para obtener más información, consulta el artículo Habilitar la vinculación de cuentas de servicio entre proyectos.

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

    Java

    Usa la opción --serviceAccount y especifica tu cuenta de servicio cuando ejecutes el trabajo de la 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 la canalización como plantilla flexible: --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 al ejecutar el trabajo de la 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 al ejecutar el trabajo de la canalización: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

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

Añadir roles

Para añadir roles a tu proyecto, sigue estos pasos.

Consola

  1. En la consola, ve a la página Gestión de identidades y accesos. Google Cloud

    Ir a IAM

  2. Selecciona el proyecto.

  3. En la fila que contiene tu cuenta de usuario, haz clic en Editar principal y, a continuación, en Añadir 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, a continuación, en Añadir otro rol.

  6. En la lista desplegable, selecciona el rol Dataflow Worker.

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

  8. Repite el proceso con todos los roles que necesiten los recursos que se usen en tu trabajo y, a continuación, haz clic en Guardar.

    Para obtener más información sobre cómo conceder roles, consulta Conceder un rol de gestión de identidades y accesos mediante la consola.

CLI de gcloud

  1. Asigna el rol roles/iam.serviceAccountUser a tu cuenta de usuario. Ejecuta el siguiente comando:

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS --role=roles/iam.serviceAccountUser
    • Sustituye PROJECT_ID por el ID del proyecto.
    • Sustituye EMAIL_ADDRESS por la dirección de correo de la cuenta de usuario.

  2. Concede roles a tu cuenta de servicio de trabajador. Ejecuta el siguiente comando para el rol de gestión de identidades y accesos roles/dataflow.worker y para cualquier rol que necesiten los recursos que se usen en tu trabajo. Si tu cuenta de servicio de trabajador necesita el rol Administrador de Dataflow, repite el proceso para el rol de gestión de identidades y accesos roles/dataflow.admin. En este ejemplo se usa la cuenta de servicio predeterminada de Compute Engine, pero te recomendamos que uses una cuenta de servicio gestionada por el usuario.

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

Acceder a los Google Cloud recursos

Tus flujos de procesamiento de Apache Beam pueden acceder a Google Cloud recursos, ya sea en el mismo proyecto Google Cloud o en otros proyectos. Estos son algunos de los recursos que ponemos a tu disposición:

Para asegurarte de que tu flujo de procesamiento de Apache Beam pueda acceder a estos recursos, debes usar los mecanismos de control de acceso correspondientes para conceder acceso explícito a la cuenta de servicio de los workers de tu proyecto de Dataflow.

Si usas funciones de Assured Workloads con Dataflow, como regiones de la UE y asistencia con controles de soberanía, todos los conectores de Cloud Storage, BigQuery, Pub/Sub y E/S, así como otros recursos a los que acceda tu 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 gestionada por el usuario o accedes a recursos de otros proyectos, es posible que tengas que realizar alguna acción adicional. En los siguientes ejemplos se da por supuesto que se usa la cuenta de servicio predeterminada de Compute Engine, pero también puedes usar una cuenta de servicio de trabajador gestionada por el usuario.

Acceder a repositorios de Artifact Registry

Cuando utiliza contenedores personalizados con Dataflow, puede subir artefactos a un repositorio de Artifact Registry.

Para usar Artifact Registry con Dataflow, debes conceder al menos acceso de escritura a Artifact Registry (role/artifactregistry.writer) a la cuenta de servicio de trabajador que ejecuta la tarea de Dataflow.

Todo el contenido del repositorio se cifra con claves de cifrado gestionadas por el cliente o con Google-owned and Google-managed encryption keys . Artifact Registry usaGoogle-owned and Google-managed encryption keys de forma predeterminada y no es necesario configurar nada para usar esta opción.

Acceder a segmentos de Cloud Storage

Para conceder acceso a tu proyecto de Dataflow a un segmento de Cloud Storage, haz que el segmento sea accesible para la cuenta de servicio de trabajador de tu proyecto de Dataflow. Como mínimo, tu cuenta de servicio necesita permisos de lectura y escritura en el segmento y en su contenido. Puedes usar los permisos de gestión de identidades y accesos para Cloud Storage para conceder el acceso necesario.

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

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

Haz los cambios siguientes:

  • BUCKET_NAME: el nombre de tu segmento de Cloud Storage
  • PROJECT_NUMBER: el número de tu proyecto de Dataflow. Para encontrar el número de tu proyecto, consulta el artículo Identificar proyectos o usa el comando gcloud projects describe.
  • SERVICE_ACCOUNT_ROLE: el rol de gestión de identidades y accesos, por ejemplo storage.objectViewer

Para obtener una lista de los segmentos de Cloud Storage de unGoogle Cloud proyecto, usa el comando gcloud storage buckets list:

gcloud storage buckets list --project= PROJECT_ID

Sustituye PROJECT_ID con el ID del proyecto.

A menos que las políticas de la organización restrinjan el uso compartido de recursos, puedes acceder a un contenedor que se encuentre en un proyecto diferente al de tu canalización de Dataflow. Para obtener más información sobre las restricciones de dominio, consulta el artículo Restringir identidades por dominio.

Si no tienes ninguno, crea uno. A continuación, concede a la cuenta de servicio de tu trabajador los permisos necesarios para leer y escribir en el segmento.

También puedes definir permisos de los contenedores desde la Google Cloud consola. Para obtener más información, consulta Configurar permisos de segmentos.

Cloud Storage ofrece dos sistemas para conceder acceso a los usuarios a tus segmentos y objetos: Gestión de Identidades y Accesos (IAM) y listas de control de acceso (LCAs). En la mayoría de los casos, la gestión de identidades y accesos es el método recomendado para controlar el acceso a los recursos.

  • IAM controla los permisos en todo Google Cloud y te permite conceder permisos a nivel de segmento y de proyecto. Para ver una lista de los roles de gestión de identidades y accesos asociados a Cloud Storage y los permisos que contiene cada rol, consulta Roles de gestión de identidades y accesos de Cloud Storage. Si necesitas tener más control sobre los permisos, crea un rol personalizado.

  • Si usas listas de control de acceso para controlar el acceso, asegúrate de que los permisos de tu cuenta de servicio de trabajador sean coherentes con tu configuración de gestión de identidades y accesos. Debido a la incoherencia entre las políticas de gestión de identidades y accesos y las políticas de LCA, es posible que tus tareas de Dataflow no puedan acceder al segmento de Cloud Storage cuando se migre de un acceso detallado a un acceso uniforme a nivel de segmento. Para obtener más información, consulta la guía sobre errores habituales.

Acceder a conjuntos de datos de BigQuery

Puedes usar la API BigQueryIO para acceder a conjuntos de datos de BigQuery, ya sea en el mismo proyecto en el que usas Dataflow o en otro proyecto. Para que la fuente y el receptor de BigQuery funcionen correctamente, las dos cuentas siguientes deben tener acceso a los conjuntos de datos de BigQuery que lea o en los que escriba tu trabajo de Dataflow:

Puede que tengas que configurar BigQuery para conceder acceso explícitamente a estas cuentas. Consulta la información sobre el control de acceso en BigQuery para obtener más información sobre cómo conceder acceso a conjuntos de datos de BigQuery mediante la página de BigQuery o la API BigQuery.

Entre los permisos de BigQuery necesarios, el flujo de procesamiento necesita el permiso de bigquery.datasets.get de gestión de identidades y accesos para acceder a un conjunto de datos de BigQuery. Por lo general, la mayoría de los roles de gestión de identidades y accesos de BigQuery incluyen el permiso bigquery.datasets.get, pero el rol roles/bigquery.jobUser es una excepción.

Acceder a temas y suscripciones de Pub/Sub

Para acceder a un tema o una suscripción de Pub/Sub, usa las funciones de Gestión de Identidades y Accesos de Pub/Sub para configurar los permisos de la cuenta de servicio de trabajador.

Los permisos de los siguientes roles de Pub/Sub son relevantes:

  • roles/pubsub.subscriber es obligatorio para consumir datos.
  • roles/pubsub.editor es obligatorio para crear una suscripción de Pub/Sub.
  • Se recomienda roles/pubsub.viewer para que Dataflow pueda consultar las configuraciones de temas y suscripciones. Esta configuración tiene dos ventajas:
    • Dataflow puede comprobar si hay ajustes no compatibles en las suscripciones que no funcionen correctamente.
    • Si la suscripción no usa el plazo de confirmación predeterminado de 10 segundos, el rendimiento mejora. Dataflow amplía repetidamente el plazo de confirmación de un mensaje mientras la canalización lo procesa. Sin los permisos de pubsub.viewer, Dataflow no puede consultar el plazo de confirmación y, por lo tanto, debe asumir un plazo predeterminado. Esta configuración hace que Dataflow envíe más solicitudes modifyAckDeadline de las necesarias.
    • Si Controles de Servicio de VPC está habilitado en el proyecto propietario de 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 necesita una regla de entrada basada en la cuenta de servicio del trabajador.

Para obtener más información y algunos ejemplos de código que muestran cómo usar las funciones de gestión de identidades y accesos de Pub/Sub, consulta Ejemplo de caso práctico: comunicación entre proyectos.

Acceder a Firestore

Para acceder a una base de datos de Firestore (en modo nativo o en modo Datastore), añade tu cuenta de servicio de trabajador de Dataflow (por ejemplo, PROJECT_NUMBER-compute@developer.gserviceaccount.com) como editor del proyecto propietario de 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 APIs de la consola Google Cloud .

Acceder a imágenes de proyectos con una política de imágenes de confianza

Si has configurado una política de imágenes de confianza para tu proyecto y tu imagen de arranque se encuentra en otro proyecto, asegúrate de que la política de imágenes de confianza esté configurada para tener acceso a la imagen. Por ejemplo, si estás ejecutando un trabajo de Dataflow basado en una plantilla, asegúrate de que el archivo de política incluya acceso al proyecto dataflow-service-producer-prod. Este Google Cloud proyecto contiene las imágenes de las tareas de plantilla.

Acceso a datos y seguridad

El servicio Dataflow funciona con dos tipos de datos:

  • Datos de usuario final. Estos datos se procesan mediante una canalización de Dataflow. Una pipeline típica lee datos de una o varias fuentes, implementa transformaciones de los datos y escribe los resultados en uno o varios receptores. Todas las fuentes y los receptores son servicios de almacenamiento que no gestiona directamente Dataflow.

  • Datos operativos. Estos datos incluyen todos los metadatos necesarios para gestionar una canalización de Dataflow. Estos datos incluyen tanto metadatos proporcionados por el usuario, como el nombre de un trabajo o las opciones de una canalización, como metadatos generados por el sistema, como un ID de trabajo.

El servicio Dataflow usa varios mecanismos de seguridad para proteger tus datos y mantener su privacidad. Estos mecanismos se aplican en los siguientes casos:

  • Enviar una canalización al servicio
  • Evaluar un flujo de procesamiento
  • Solicitar acceso a la telemetría y las métricas durante y después de la ejecución de una canalización
  • Usar un servicio de Dataflow, como Shuffle o Streaming Engine

Localidad de los datos

Todo el procesamiento de datos principal de Dataflow se lleva a cabo en la región especificada en el código del flujo de procesamiento. Si no se especifica ninguna 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 la canalización podrá leer y escribir opcionalmente desde fuentes y receptores de otras regiones. Sin embargo, el procesamiento de datos real solo se produce en la región especificada para ejecutar las VMs de Dataflow.

La lógica de la canalización se evalúa en instancias de VM de trabajador individuales. Puedes especificar la zona en la que se encuentran estas instancias y la red privada a través de la que se comunican. Los cálculos auxiliares de la plataforma dependen de metadatos como las ubicaciones de Cloud Storage o los tamaños de los archivos.

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 de un envío de una canalización

Los permisos de gestión de identidades y accesos de tu proyecto de Google Cloud controlan el acceso al servicio Dataflow. Cualquier principal que tenga derechos de editor o propietario en tu proyecto puede enviar canalizaciones al servicio. Para enviar flujos de trabajo, debe autenticarse mediante la CLI de Google Cloud. Una vez que te autentiques, tus canalizaciones se enviarán mediante el protocolo HTTPS. Para obtener instrucciones sobre cómo autenticarte con las credenciales de tu cuenta de Google Cloud , consulta la guía de inicio rápido del lenguaje que estés usando.

Datos de una evaluación de una canalización

Como parte de la evaluación de una canalización, se pueden generar datos temporales y almacenarse localmente en las instancias de VM de los trabajadores o en Cloud Storage. Los datos temporales se cifran en reposo y no se conservan una vez que finaliza la evaluación de una canalización. Estos datos también se pueden almacenar en el servicio Shuffle o en el servicio Streaming Engine (si has habilitado el servicio) en la misma región especificada en la canalización de Dataflow.

Java

De forma predeterminada, las VMs de Compute Engine se eliminan cuando se completa el trabajo de Dataflow, independientemente de si se realiza correctamente o no. Por lo tanto, se elimina el disco persistente asociado y cualquier dato intermedio que pueda estar almacenado en él. Los datos intermedios almacenados en Cloud Storage se pueden encontrar en sububicaciones de la ruta de Cloud Storage que proporcione como --stagingLocation o --tempLocation. Si escribes la salida en un archivo de Cloud Storage, es posible que se creen archivos temporales en la ubicación de salida antes de que se finalice la operación `write`.

Python

De forma predeterminada, las VMs de Compute Engine se eliminan cuando se completa el trabajo de Dataflow, independientemente de si se realiza correctamente o no. Por lo tanto, se elimina el disco persistente asociado y cualquier dato intermedio que pueda estar almacenado en él. Los datos intermedios almacenados en Cloud Storage se pueden encontrar en sububicaciones de la ruta de Cloud Storage que proporcione como --staging_location o --temp_location. Si escribes la salida en un archivo de Cloud Storage, es posible que se creen archivos temporales en la ubicación de salida antes de que se finalice la operación `write`.

Go

De forma predeterminada, las VMs de Compute Engine se eliminan cuando se completa el trabajo de Dataflow, independientemente de si se realiza correctamente o no. Por lo tanto, se elimina el disco persistente asociado y cualquier dato intermedio que pueda estar almacenado en él. Los datos intermedios almacenados en Cloud Storage se pueden encontrar en sububicaciones de la ruta de Cloud Storage que proporcione como --staging_location o --temp_location. Si escribes la salida en un archivo de Cloud Storage, es posible que se creen archivos temporales en la ubicación de salida antes de que se finalice la operación `write`.

Datos en los registros y la telemetría de la canalización

La información almacenada en Cloud Logging se genera principalmente a partir del código de tu programa de Dataflow. El servicio Dataflow también puede generar datos de advertencia y de error en Cloud Logging, pero estos datos son los únicos datos intermedios que el servicio añade a los registros. Cloud Logging es un servicio global.

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

Datos en los servicios de Dataflow

Si usas Dataflow Shuffle o Dataflow Streaming en tu flujo de procesamiento, no especifiques las opciones de zona del flujo de procesamiento. En su lugar, especifica la región y asigna el valor a una de las regiones en las que estén disponibles las funciones Aleatorio o Streaming. Dataflow selecciona automáticamente la zona de la región que especifiques. Los datos de los usuarios finales en tránsito permanecen en las VMs de trabajador y en la misma zona. Estos trabajos de Dataflow pueden seguir leyendo y escribiendo 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 Shuffle de Dataflow o Streaming de Dataflow, pero siempre permanecen en la región especificada en el código de la canalización.

Te recomendamos que utilices los mecanismos de seguridad disponibles en los recursos de nube subyacentes de tu canalización. Estos mecanismos incluyen las funciones de seguridad de datos de las fuentes y los sumideros de datos, como BigQuery y Cloud Storage. Tampoco es recomendable mezclar diferentes niveles de confianza en un mismo proyecto.