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 sobre 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 mediante 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 Google Cloud Console.

Seguridad y permisos para canalizaciones locales

Cuando ejecutas de forma local, la canalización de Apache Beam se ejecuta con la cuenta de Google Cloud que configuraste con el archivo ejecutable de la herramienta de línea de comandos de gcloud. 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) y durante la ejecución de trabajos con el fin de administrarlos.

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

Cuenta de servicio de Dataflow

Como parte de la ejecución de la canalización de Dataflow, este servicio manipula los recursos en tu nombre (por ejemplo, cuando crea VM adicionales). Cuando ejecutas la canalización en el servicio de Dataflow, se usa la cuenta de servicio de Dataflow (service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com). La cuenta de servicio de Dataflow se crea primero. el uso del recurso Dataflow Job. A esta cuenta se le asigna la función de agente de servicio de Dataflow en el proyecto y tiene los permisos necesarios para ejecutar un trabajo de Dataflow bajo el proyecto, incluido el inicio de los trabajadores de Compute Engine. El 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 Cloud Console o en la herramienta de línea de comandos de gcloud.

Console

  1. Ir a la página Funciones

    Ir a Funciones

  2. En la barra de herramientas de Cloud Console, selecciona el proyecto.

  3. Para ver los permisos de la cuenta de servicio de Dataflow, selecciona la casilla de verificación Incluir asignaciones de funciones proporcionadas por Google en la esquina superior derecha y selecciona la casilla de verificación Agente de servicios de Cloud Dataflow.

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 quitas los permisos para la cuenta de servicio de la política de administración de identidades y accesos (IAM), las cuentas siguen presentes debido a que son propiedad del servicio de Dataflow. 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.

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 de la canalización. La cuenta de servicio de trabajador se usa como la identidad de todas las VM de trabajador. 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, asegúrate de que tenga las funciones roles/dataflow.admin y roles/dataflow.worker. Además, se requiere el permiso iam.serviceAccounts.actAs en tu cuenta de usuario para actuar en nombre de la cuenta de servicio.

Cuenta de servicio de trabajador predeterminada

De forma predeterminada, los trabajadores usan la cuenta de servicio predeterminada de Compute Engine del proyecto como la cuenta de servicio del trabajador. Esta cuenta de servicio (<project-number>-compute@developer.gserviceaccount.com) se crea de forma automática cuando habilitas la API de Compute Engine en el proyecto desde la biblioteca de API en Cloud Console.

La cuenta de servicio predeterminada de Compute Engine tiene un acceso amplio a los recursos del proyecto, lo que facilita 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 y usarla como la cuenta de servicio de trabajador.

Si no tienes este tipo de cuenta, debes crear una y configurar las funciones de IAM necesarias de la cuenta. Como mínimo, esta debe tener la función de trabajador de Dataflow. Además, es posible que esta cuenta de servicio necesite funciones adicionales para usar los recursos de Google Cloud que solicita tu trabajo (como BigQuery, Pub/Sub o escribir en Cloud Storage). Por ejemplo, si un trabajo lee datos de BigQuery, la cuenta de servicio también debe tener por lo menos la función 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.

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. También debes otorgar la función de creador de tokens de cuenta de servicio a las siguientes cuentas de servicio administradas por Google en la cuenta de servicio administrada por el usuario:

  • Cuenta de servicio predeterminada de Compute Engine (<project-number>-compute@developer.gserviceaccount.com)
  • Agente de servicio de Dataflow (service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com)

Java

Usa la opción --serviceAccount y especifica tu cuenta de servicio cuando ejecutes el trabajo de canalización: --serviceAccount=my-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=my-service-account-name@<project-id>.iam.gserviceaccount.com

Puedes consultar una lista de las cuentas de servicio del proyecto en la página de permisos de Cloud Console.

Accede a los recursos de Google Cloud en varios proyectos de Google Cloud

Las canalizaciones de Apache Beam pueden acceder a los siguientes tipos de recursos de Google Cloud alojados en otros proyectos de Google Cloud:

Para asegurarse de que la canalización de Apache Beam pueda acceder a estos recursos en los proyectos, será necesario usar los mecanismos respectivos de control de acceso de los recursos para otorgar explícitamente acceso a la cuenta de servicio de trabajador de tu proyecto de Dataflow.

Accede a los buckets de Cloud Storage en los proyectos de Google Cloud

Para que el proyecto de Dataflow tenga acceso a un bucket de Cloud Storage al que pertenece un proyecto de Google Cloud diferente, haz que el depósito sea accesible para la cuenta de servicio de trabajador del proyecto de Dataflow. Puedes usar los controles de acceso de Cloud Storage para otorgar el acceso necesario.

Para obtener una lista de las cuentas de servicio del proyecto de Dataflow, revisa la página de IAM y administración de Cloud Console. Una vez que tengas los nombres de las cuentas, puedes ejecutar comandos de gsutil para otorgar la propiedad de las cuentas de servicio del proyecto (permisos de lectura y escritura) al bucket y sus contenidos.

Ingresa el siguiente comando en la ventana del shell o la terminal para otorgar a las cuentas de servicio del proyecto de Dataflow acceso a un depósito de Cloud Storage ubicado en otro proyecto: gsutil acl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Ingresa el siguiente comando en la ventana del shell o la terminal para otorgar a las cuentas de servicio del proyecto de Dataflow acceso a los contenidos existentes de un depósito de Cloud Storage ubicado en otro proyecto: gsutil -m acl ch -r -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

El comando anterior otorga acceso solo a los recursos existentes. Si otorgas a las cuentas de servicio del proyecto de Dataflow permiso predeterminado al bucket, estas podrán acceder a los recursos futuros que se agreguen al bucket: gsutil defacl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Accede a los conjuntos de datos de BigQuery en los proyectos de Google Cloud

Puedes usar la API de BigQueryIO para acceder a los conjuntos de datos de BigQuery que son propiedad de otro proyecto de Google Cloud (es decir, que no pertenecen al proyecto en el que usas Dataflow). Para que la fuente y el receptor de BigQuery funcionen correctamente, 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 mediante 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 abcde@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: abcde@gmail.com y 123456789-compute@developer.gserviceaccount.com.

Accede a las suscripciones y los temas de Pub/Sub en los proyectos de Google Cloud

Si deseas acceder a un tema o una suscripción de Pub/Sub que pertenece a otro proyecto de Google Cloud, usa las funciones de administración de identidades y accesos de Pub/Sub a fin de configurar permisos para varios proyectos. Dataflow usa la cuenta de servicio de trabajador para ejecutar tus trabajos y otorgar a esta cuenta de servicio acceso a los recursos de Pub/Sub en el otro proyecto.

Se requieren los permisos de las siguientes funciones de Pub/Sub:

  • roles/pubsub.subscriber: para consumir datos y crear suscripciones
  • roles/pubsub.viewer para consultar la configuración de temas y suscripciones Para extender los plazos de forma adecuada, Dataflow necesita acceder a los plazos de confirmación de recepción de suscripciones. Además, este permiso permite que Dataflow verifique la configuración no compatible en las suscripciones y los temas que podrían causar problemas.

Consulta el Caso de uso de muestra: Comunicación entre proyectos para obtener más información y ver algunos ejemplos de código en los que se demuestra cómo usar las funciones de administración de identidades y accesos de Pub/Sub.

Accede a Firestore en los proyectos de Google Cloud

Para acceder a una base de datos de Firestore (en modo nativo o modo Datastore) que pertenece a otro proyecto de Google Cloud, agrega la cuenta de servicio de Compute Engine (<project-number>-compute@developer.gserviceaccount.com) del proyecto de Dataflow como editor del proyecto al que pertenezca la instancia de Firestore. , o usa una función de Datastore más restrictiva, 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 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. Estos son los datos que procesa una canalización de Dataflow. 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 directamente.

  • 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. De forma opcional, un trabajo de canalización puede leer y escribir desde fuentes y receptores en otras regiones si especificas esa opción en el código de la canalización. 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 de los datos y los extremos regionales, consulta Extremos regionales.

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 la herramienta de línea de comandos de gcloud. Después de la autenticación, las canalizaciones se envían mediante el protocolo HTTPS. Consulta la guía de inicio rápido del lenguaje que usas a fin de 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 VM de Compute Engine cuando finaliza el trabajo de Dataflow, sin importar si se realizó correctamente o falló. Esto significa que se borró el Persistent Disk asociado y todos los datos intermedios que podrían estar almacenados. 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 VM de Compute Engine cuando finaliza el trabajo de Dataflow, sin importar si se realizó correctamente o falló. Esto significa que se borró el Persistent Disk asociado y todos los datos intermedios que podrían estar almacenados. 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 mediante 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 actualmente. Dataflow selecciona de forma automática la zona en la región especificada. 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.