Seguridad y permisos de Google 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 el 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 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 en el idioma que usas para obtener instrucciones sobre cómo autenticar con las credenciales de tu cuenta de GCP.

Seguridad y permisos para canalizaciones en 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 y 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 hacer 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 se configuren automáticamente y de forma correcta los permisos para el staging 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 (<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 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 la cuenta de servicio cuando ejecutes el trabajo de canalización:

  --serviceAccount=my-service-account-name@my-project.iam.gserviceaccount.com

Acceso 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 asegurar 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 del controlador de tu proyecto de Cloud Dataflow.

Acceso a los depósitos de Cloud Storage en los proyectos de Google Cloud Platform

Para darle a tu proyecto de Dataflow acceso al depósito de Cloud Storage que es propiedad de un proyecto diferente de Cloud Platform, necesitarás que el depósito sea accesible para la cuenta de servicio del controlador de tu proyecto de Dataflow. 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.

Usa el siguiente comando en la ventana terminal o shell para otorgar a las cuentas de servicio del proyecto de Cloud Dataflow acceso al depósito de Cloud Storage en otro proyecto:

gsutil acl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Usa el siguiente comando en la ventana terminal o shell para otorgar a las cuentas de servicio del proyecto de Cloud Dataflow acceso a los contenidos existentes de un depósito de Cloud Storage en otro proyecto:

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 recursiva 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 permiso predeterminado al depósito permitirá acceder a los recursos a futuro que se agreguen al depósito:

gsutil defacl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Acceso a los conjuntos de datos de BigQuery en los proyectos de Google Cloud Platform

Puedes usar la API 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 que lean o escriban en el trabajo de Cloud 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 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, se debe otorgar a los conjuntos de datos usados de BigQuery acceso a las cuentas siguientes: abcde@gmail.com y 123456789-compute@developer.gserviceaccount.com.

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

Acceso 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 los datos seguros y privados, el servicio de Cloud Dataflow usa varios mecanismos de seguridad. Estos mecanismos se aplican en las siguientes situaciones:

  • Cuando envías una canalización al servicio
  • Cuando el servicio evalúa tu canalización
  • Cuando solicitas acceso a métricas y telemetría 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 al que se le diera derechos de propiedad o para editar puede enviar canalizaciones al servicio. Para enviar canalizaciones, debes autenticar 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 idioma que usas para obtener instrucciones sobre cómo autenticar 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 termina una evaluación de canalización.

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.

Nota: Puedes controlar si se borran las VM cuando finalice el trabajo con la opción de canalización --teardownPolicy. Las siguientes opciones son válidas: TEARDOWN_ALWAYS, la predeterminada, que siempre borra todas las VM; TEARDOWN_NEVER, que mantiene en ejecución todas las VM sin importar si fallan o si funcionan correctamente; y TEARDOWN_ON_SUCCESS, que mantiene en ejecución todas las VM solo cuando falla el trabajo. TEARDOWN_ON_SUCCESS podría ser particularmente útil para depurar.

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.

Nota: Puedes controlar si se borran las VM cuando finalice el trabajo con la opción de canalización --teardown_policy. Las siguientes opciones son válidas: TEARDOWN_ALWAYS, la predeterminada, que siempre borra todas las VM; TEARDOWN_NEVER, que mantiene en ejecución todas las VM sin importar si fallan o si funcionan correctamente; y TEARDOWN_ON_SUCCESS, que mantiene en ejecución todas las VM solo cuando falla el trabajo. TEARDOWN_ON_SUCCESS podría ser particularmente útil para depurar.

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 en los que se transmiten datos durante la evaluación de canalización: cuando se lee/escribe de las fuentes y receptores, y entre las instancias del trabajador mientras se procesan los datos en la canalización. Se encripta toda la comunicación con las fuentes y receptores de Cloud y se pasan 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 donde 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 los límites de tu 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.

Recomendaciones

Te recomendamos que uses los mecanismos 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, es mejor 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.