Seguridad y permisos de Cloud Dataflow

Las canalizaciones de Cloud Dataflow se pueden ejecutar de forma local (para hacer pruebas en conjuntos de datos pequeños) o en recursos administrados de Google Cloud Platform (GCP) con el servicio administrado de Cloud 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 Cloud Dataflow se asignan de acuerdo con la función que se usó para acceder a los recursos de la canalización. En las siguientes secciones, se explican las funciones y los permisos que se asocian con las canalizaciones locales y en la nube, la configuración predeterminada y cómo verificar los permisos del proyecto.

Antes de comenzar

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

Seguridad y permisos para canalizaciones locales

Cuenta de Google Cloud Platform

De forma local, la canalización de Apache Beam se ejecuta como la cuenta de GCP que configuraste con la herramienta ejecutable de la línea de comandos de gcloud. Por lo tanto, las operaciones del SDK de Apache Beam que se ejecuta de forma local tienen acceso a los mismos archivos y recursos que tu cuenta de GCP.

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

Nota: Las canalizaciones locales pueden enviar datos a destinos locales, como archivos locales o destinos de la nube, por ejemplo, Cloud Storage o BigQuery. Si la canalización ejecutada de forma local escribe archivos en los recursos basados en la nube, como Cloud Storage, esta usa las credenciales de tu cuenta y el proyecto de GCP que configuraste como el predeterminado para la herramienta de línea de comandos de gcloud. Consulta la guía de inicio rápido del lenguaje que usas para obtener instrucciones sobre cómo autenticar con las credenciales de tu cuenta de GCP.

Seguridad y permisos para canalizaciones en Google Cloud Platform

Cuando ejecutas la canalización, Cloud Dataflow usa dos cuentas de servicio para administrar la seguridad y los permisos: la cuenta de servicio de Cloud Dataflow y la del controlador. El servicio de Cloud 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. Las instancias de trabajador usan la cuenta de servicio del controlador para acceder a los recursos de entrada y salida después de que envías el trabajo.

Nota: A partir del 4 de octubre de 2017, Cloud Dataflow usa la cuenta de servicio del controlador para las operaciones de metadatos. Cloud Dataflow ya no usa la cuenta cloudservices para las operaciones de metadatos.

Cuenta de servicio de Cloud Dataflow

Como parte de la ejecución de la canalización de Cloud Dataflow, este servicio manipula los recursos en tu nombre (por ejemplo, cuando crea VM adicionales). Cuando ejecutas la canalización en el servicio de Cloud Dataflow, usa una cuenta de servicio (service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com). Esta cuenta se crea automáticamente cuando se crea un proyecto de Cloud Dataflow, cuando se le asigna la función de agente de servicio de Cloud Dataflow en el proyecto y cuando tiene los permisos necesarios para ejecutar el trabajo bajo el proyecto de Cloud Dataflow, incluidos los trabajadores de inicio de Compute Engine. El servicio de Cloud Dataflow usa la cuenta de forma exclusiva. Esta cuenta es específica para el proyecto.

Puedes revisar los permisos de las cuentas de servicio de Cloud Dataflow en Cloud Console en la página IAM y administración > IAM.

Debido a que los servicios de GCP esperan tener acceso de lectura/escritura al proyecto y a sus recursos, se recomienda no cambiar los permisos predeterminados que el proyecto establece automáticamente. Si quitas los permisos para la cuenta de servicio de la política de IAM, las cuentas seguirán presentes debido a que son propiedad del servicio de Cloud Dataflow. Si una cuenta de servicio de Cloud Dataflow pierde los permisos de un proyecto, no podrá iniciar las VM y realizar otras tareas de administración.

Recomendación: Crea un depósito para tu proyecto con el fin de usarlo como el depósito de staging para Cloud Dataflow. Esto garantizará que los permisos se configuren automáticamente y de forma correcta para la etapa de prueba de los archivos ejecutables de la canalización.

Cuenta de servicio del controlador

Las instancias de Compute Engine ejecutan las operaciones del SDK de Apache Beam en la nube. Estos trabajadores usan la cuenta de servicio del controlador de tu proyecto para acceder a los archivos y a otros recursos de la canalización. Cloud Dataflow también usa la cuenta de servicio del controlador para realizar operaciones de "metadatos", las cuales no se ejecutan en clientes locales ni en trabajadores de Compute Engine. Estas operaciones realizan tareas como determinar los tamaños de las entradas y acceder a los archivos de Cloud Storage.

Cuenta de servicio del controlador predeterminada

De forma predeterminada, los trabajadores usan la cuenta de servicio de Compute Engine del proyecto como la cuenta de servicio del controlador. Esta cuenta de servicio (<project-number>-compute@developer.gserviceaccount.com) se crea automáticamente cuando habilitas la API de Compute Engine para tu proyecto desde la página de API en Google Cloud Platform Console.

Además, la cuenta de servicio de Compute Engine asociada con un proyecto tiene acceso a los depósitos y recursos de Cloud Storage que son propiedad del proyecto de forma predeterminada. Debido a que la mayoría de los trabajadores de Compute Engine esperan tener acceso de lectura/escritura a los recursos del proyecto, se recomienda no cambiar los permisos predeterminados que se establecen automáticamente para el proyecto.

Puedes obtener una lista de las cuentas de servicio de tu proyecto en la página de permisos de GCP Console.

Especificaciones de la cuenta de servicio del controlador administrada por el usuario

Si quieres crear y usar recursos con acceso y control precisos, puedes usar una cuenta de servicio del proyecto de tu trabajo como la cuenta de servicio del controlador administrada por el usuario.

Si no tienes este tipo de cuenta, debes crear una que esté en el mismo proyecto que tu trabajo 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, la cuenta de servicio podría necesitar funciones adicionales para usar los recursos de Cloud Platform que solicita tu trabajo (como BigQuery, Cloud Pub/Sub o escribir en Cloud Storage). Por ejemplo, si el trabajo lee de BigQuery, la cuenta de servicio debe tener al menos la función bigquery.dataViewer.

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

Cómo acceder a los recursos de Google Cloud Platform en distintos proyectos de Google Cloud Platform

Las canalizaciones de Apache Beam pueden acceder a los recursos de GCP en otros proyectos de GCP. Estos incluyen:

Java

  • Depósitos de Cloud Storage
  • Conjuntos de datos de BigQuery
  • Suscripciones y temas de Cloud Pub/Sub
  • Conjuntos de datos de Cloud Datastore

Python

  • Depósitos de Cloud Storage
  • Conjuntos de datos de BigQuery
  • Conjuntos de datos de Cloud Datastore

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 acceso de forma explícita a la cuenta de servicio del controlador de tu proyecto de Cloud Dataflow.

Cómo acceder a los depósitos de Cloud Storage en los proyectos de Google Cloud Platform

Para que tu proyecto de Cloud Dataflow tenga acceso a un depósito de Cloud Storage que es propiedad de un proyecto de GCP diferente, tu cuenta de servicio del controlador del proyecto de Cloud Dataflow deberá tener acceso al depósito. Puedes usar los Controles de acceso de Cloud Storage para otorgar el acceso solicitado.

Nota: Si no estás usando las cuentas de servicio predeterminadas, asegúrate de que los permisos sean consistentes con la configuración de IAM.

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

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

Para que tus cuentas de servicio del proyecto de Cloud Dataflow tengan acceso a los contenidos existentes de un depósito de Cloud Storage en otro proyecto, usa el siguiente comando en tu shell o ventana de terminal: gsutil -m acl ch -r -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Nota: La opción -m ejecuta el comando en paralelo para un procesamiento más rápido; y la opción -r ejecuta el comando de manera recurrente en los recursos del depósito.

Ten en cuenta que el comando anterior solo otorga acceso a recursos existentes. * Otorgar a las cuentas de servicio del proyecto de Cloud Dataflow un permiso predeterminado al depósito les permitirá acceder a los futuros recursos que se agreguen al depósito: gsutil defacl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Cómo acceder a los conjuntos de datos de BigQuery en los proyectos de Google Cloud Platform

Puedes usar la API de BigQueryIO para acceder a los conjuntos de datos de BigQuery que son propiedad de un proyecto de GCP diferente (es decir, no es el proyecto en el que usas Cloud Dataflow). Para que la fuente y el receptor de BigQuery operen correctamente, las siguientes dos cuentas deben tener acceso a todos los conjuntos de datos de BigQuery desde los que tu trabajo de Cloud Dataflow lee o en los cuales escribe:

Podrías necesitar configurar BigQuery para otorgar acceso explícito a estas cuentas. Consulta Control de acceso a BigQuery para obtener más información sobre cómo otorgar acceso a los conjuntos de datos de BigQuery con la IU web de BigQuery o la API de BigQuery.

Por ejemplo, si tu cuenta de GCP es abcde@gmail.com y el número del proyecto en el que ejecutas el trabajo de Cloud Dataflow es 123456789, a las siguientes cuentas se les debe otorgar acceso a los conjuntos de datos usados de BigQuery: abcde@gmail.com y 123456789-compute@developer.gserviceaccount.com.

Cómo acceder a las suscripciones y temas de Cloud Pub/Sub en los proyectos de Google Cloud Platform

Java

Para acceder a un tema o suscripción de Cloud Pub/Sub que es propiedad de un proyecto de GCP diferente (es decir, no es el proyecto en el que usas Cloud Dataflow), necesitarás usar las funciones de la administración de identidades y accesos para configurar los permisos de proyectos cruzados. Cloud Dataflow usa la cuenta de servicio del controlador con el fin de ejecutar los trabajos. Para ello, necesitas otorgar a esta cuenta acceso a los recursos de Cloud Pub/Sub en el otro proyecto.

Consulta Muestra de caso práctico: comunicación de proyectos cruzados para obtener más información, además de conocer algunos ejemplos de código que demuestran cómo usar las funciones de la administración de identidades y accesos de Cloud Pub/Sub.

Python

Esta función aún no está disponible en el SDK de Apache Beam para Python.

Cómo acceder a Cloud Datastore en los proyectos de Google Cloud Platform

Para acceder a una instancia de Cloud Datastore perteneciente a otro proyecto de GCP, deberás agregar la cuenta de servicio de Compute Engine (<project-number>-compute@developer.gserviceaccount.com) del proyecto de Cloud Dataflow como editor del proyecto al que pertenezca la instancia de Cloud Datastore. También necesitarás habilitar la API de Cloud Datastore en ambos proyectos en https://console.cloud.google.com/project/<project-id>/apiui/apiview/datastore/overview.

Seguridad y acceso de datos

Para mantener la seguridad y la privacidad de los datos, el servicio de Cloud Dataflow usa varios mecanismos de seguridad. Estos mecanismos se aplican a las siguientes situaciones: * Cuando envías una canalización al servicio. * Cuando el servicio evalúa tu canalización. * Cuando solicitas acceso a telemetría y métricas durante y después de la ejecución de la canalización.

Envío de la canalización

Los permisos de proyecto de Google Cloud controlan el acceso al servicio de Cloud Dataflow. Cualquier miembro de tu proyecto con derechos de propiedad o edición puede enviar canalizaciones al servicio. Para enviar canalizaciones, debes realizar una autenticación con la herramienta de línea de comandos de gcloud. Una vez que se autentique, la canalización se envía con el protocolo de HTTPS. Consulta la guía de inicio rápido del lenguaje que usas para obtener instrucciones sobre cómo realizar autenticaciones con las credenciales de tu cuenta de GCP.

Evaluación de canalización

Datos temporales

Como parte de la evaluación de la canalización, los datos temporales se podrían generar y almacenar localmente en los trabajadores o en Cloud Storage. Los datos temporales se encriptan en reposo y no se conservan después de que la evaluación de una canalización concluye.

Java

De forma predeterminada, se borran las VM de Compute Engine cuando se finaliza el trabajo de Cloud Dataflow, sin importar si se realizó correctamente o si falló el trabajo. 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 acceso de Cloud Storage que proporcionaste 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 se finaliza el trabajo de Cloud Dataflow, sin importar si se realizó correctamente o si falló el trabajo. 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 acceso de Cloud Storage que proporcionaste 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 registrados

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

Datos en tránsito

Existen dos modos para transmitir los datos durante una evaluación de la canalización:

  • Cuando se lee/escribe desde fuentes y receptores.
  • Entre instancias de trabajadores mientras los datos se procesan dentro de la misma canalización.

Se encripta toda la comunicación con las fuentes y receptores de GCP y se transfiere a HTTPS. Toda la comunicación entre trabajadores se produce en redes privadas y está sujeta a los permisos y reglas de firewall de tu proyecto.

Localidad de datos

La lógica de una canalización se evalúa en instancias individuales de Compute Engine. 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 que tienen lugar en la infraestructura de Google se basan en los metadatos (como las ubicaciones de Cloud Storage o los tamaños del archivo). Los datos nunca dejan la zona o traspasan tus límites de seguridad.

Métricas y telemetría

Los datos de telemetría y las métricas asociadas se encriptan en reposo, y los permisos de lectura de tu proyecto de GCP controlan el acceso a estos datos.

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, se recomienda no mezclar los distintos niveles de confianza en un solo proyecto.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Si necesitas ayuda, visita nuestra página de asistencia.