Caso de uso: Control de acceso para un clúster de Dataproc en otro proyecto

En esta página, se describe cómo administrar el control de acceso cuando implementas y ejecutas una canalización. que usa clústeres de Dataproc en otro proyecto de Google Cloud.

Situación

De forma predeterminada, cuando una instancia de Cloud Data Fusion se inicia en un proyecto de Google Cloud, implementa y ejecuta canalizaciones con Clústeres de Dataproc dentro del mismo proyecto. Sin embargo, tu organización puede requerir que uses clústeres en otro proyecto. Para este caso de uso, debes administrar el acceso entre proyectos. La siguiente página se describe cómo cambiar los parámetros de configuración del modelo de referencia (predeterminado) y aplicarlos. los controles de acceso apropiados.

Antes de comenzar

Para comprender las soluciones de este caso de uso, necesitas el siguiente contexto:

Suposiciones y alcance

Este caso de uso tiene los siguientes requisitos:

  • Una instancia privada de Cloud Data Fusion. Por motivos de seguridad, es posible que una organización requiera que uses este tipo de instancia.
  • Una fuente y un receptor de BigQuery
  • Control de acceso con IAM, no basado en roles (RBAC).

Solución

Esta solución compara la arquitectura específica del caso de uso con el modelo de referencia configuración.

Arquitectura

En los siguientes diagramas, se compara la arquitectura del proyecto para crear una una instancia de Cloud Data Fusion y la ejecución de canalizaciones el mismo proyecto (modelo de referencia) y en un proyecto diferente a través del usuario la VPC del proyecto.

Arquitectura de referencia

En este diagrama, se muestra la arquitectura de referencia de los proyectos:

Arquitectura de proyecto, usuario y cliente de Dataproc en Cloud Data Fusion.

Para la configuración del modelo de referencia, debes crear una instancia privada de Cloud Data Fusion y ejecutar una canalización sin personalización adicional:

  • Usas uno de los perfiles de procesamiento integrados
  • La fuente y el receptor están en el mismo proyecto que la instancia
  • No se otorgaron roles adicionales a ninguna de las cuentas de servicio

Para obtener más información sobre los proyectos de usuario y cliente, consulta Herramientas de redes.

Arquitectura de casos de uso

En este diagrama, se muestra la arquitectura del proyecto cuando usas clústeres en otro proyecto:

Arquitectura de proyecto, usuario y cliente de Dataproc en Cloud Data Fusion.

Configuraciones

En las siguientes secciones, se comparan las configuraciones de referencia con las configuraciones específicas del caso de uso para usar clústeres de Dataproc en un proyecto diferente a través de la VPC predeterminada del proyecto del inquilino.

En las siguientes descripciones de casos de uso, el proyecto del cliente es donde se Se ejecuta la instancia de Cloud Data Fusion y el proyecto de Dataproc. es donde se inicia el clúster de Dataproc.

VPC e instancia del proyecto del usuario

Modelo de referencia Caso de uso
En el diagrama de arquitectura de referencia anterior, el proyecto de usuario contiene los siguientes componentes:
  • La VPC predeterminada, que se crea automáticamente.
  • La implementación física de la instancia de Cloud Data Fusion.
 No se necesita ninguna configuración adicional para este caso de uso.

Proyecto del cliente

Modelo de referencia Caso de uso
Tu proyecto de Google Cloud es donde implementas y ejecutas canalizaciones. De forma predeterminada, los clústeres de Dataproc se inician en este proyecto cuando ejecutas tus canalizaciones. En este caso de uso, administras dos proyectos. En esta página, proyecto del cliente se refiere a dónde Cloud Data Fusion se ejecutan las instancias de VM.
El proyecto de Dataproc se refiere a donde se inician los clústeres de Dataproc.

VPC del cliente

Modelo de referencia Caso de uso

Desde tu perspectiva (del cliente), la VPC del cliente es Cloud Data Fusion está ubicado de forma lógica.


Conclusión clave:
Puedes encontrar los detalles de la VPC del cliente en la página Redes de VPC de tu proyecto.

Ir a Redes de VPC

 No se necesita ninguna configuración adicional para este caso de uso.

Subred de Cloud Data Fusion

Modelo de referencia Caso de uso

Desde tu perspectiva (del cliente), esta subred es donde Cloud Data Fusion está ubicado de forma lógica.


Conclusión clave:
La región de esta subred es la misma como la ubicación de la instancia de Cloud Data Fusion en el usuario en un proyecto final. 		No se necesita configuración adicional para este caso de uso.

Subred de Dataproc

Modelo de referencia Caso de uso

La subred en la que se inician los clústeres de Dataproc cuando cuando ejecutes una canalización.


Conclusiones clave:
  • Para esta configuración de referencia, Dataproc se ejecuta en en la misma subred que la instancia de Cloud Data Fusion.
  • Cloud Data Fusion ubica una subred en la misma región que ambas la instancia y la subred de Cloud Data Fusion. Si solo hay una en esta región, las subredes son las mismas.
  • La subred de Dataproc debe tener Acceso privado a Google.

Esta es una subred nueva en la que los clústeres de Dataproc que se inician cuando ejecutas una canalización.


Conclusiones clave:
  • Para esta subred nueva, establece el Acceso privado a Google en Activado.
  • No es necesario que la subred de Dataproc esté en la misma que la instancia de Cloud Data Fusion.

Fuentes y receptores

Modelo de referencia Caso de uso

Las fuentes de las que se extraen los datos y los receptores donde se cargan los datos como fuentes y receptores de BigQuery.


Conclusión clave:
  • Las tareas que recuperan y cargan datos deben procesarse en la misma ubicación que el conjunto de datos, o se producirá un error.
 Las configuraciones de control de acceso específicas del caso de uso en esta página son para fuentes y receptores de BigQuery.

Cloud Storage

Modelo de referencia Caso de uso

El bucket de almacenamiento en el proyecto del cliente que ayuda a transferir archivos entre Cloud Data Fusion y Dataproc.


Conclusiones clave:
  • Puedes especificar este bucket a través de la Web de Cloud Data Fusion en la configuración del perfil de Compute de en clústeres efímeros.
  • Para canalizaciones por lotes y en tiempo real, o trabajos de replicación: si no especificas un bucket en el perfil de procesamiento, Cloud Data Fusion crea un bucket en el mismo proyecto que instancia con este propósito.
  • Incluso para los clústeres estáticos de Dataproc, en esta configuración de referencia, Cloud Data Fusion crea el bucket y difiere de los buckets temporales y de etapa de pruebas de Dataproc.
  • El agente de servicio de la API de Cloud Data Fusion tiene permisos integrados para crear este bucket en el proyecto que contiene la instancia de Cloud Data Fusion.
 No se necesita configuración adicional para este caso de uso.

Buckets temporales usados por fuente y receptor

Modelo de referencia Caso de uso

Los buckets temporales creados por los complementos para tus fuentes y receptores como los trabajos de carga que inicia el complemento del receptor de BigQuery.


Conclusiones clave:
  • Puedes definir estos buckets cuando configures las propiedades del plugin de fuente y destino.
  • Si no defines un bucket, se creará uno en el mismo proyecto en el que se ejecuta Dataproc.
  • Si el conjunto de datos es multirregional, el bucket se crea en el mismo del proyecto.
  • Si defines un bucket en la configuración del complemento, la región del bucket debe coincidir con la región del conjunto de datos.
  • Si no defines un bucket en los parámetros de configuración del complemento, que se crea para ti se borra cuando finaliza la canalización.
 Para este caso de uso, el bucket se puede crear en cualquier proyecto.

Buckets que son fuentes o receptores de datos para complementos

Modelo de referencia Caso de uso
Los buckets de clientes, que especificas en la configuración de complementos como el complemento de Cloud Storage y el FTP Complemento de Cloud Storage. No se necesita ninguna configuración adicional para este caso de uso.

IAM: Agente de servicio de la API de Cloud Data Fusion

Modelo de referencia Caso de uso

Cuando la API de Cloud Data Fusion está habilitada, el Nube Rol de agente de servicio de la API de Data Fusion (roles/datafusion.serviceAgent) se otorga automáticamente a el Cuenta de servicio de Cloud Data Fusion, el agente de servicio principal


Conclusiones clave:
  • El rol contiene permisos para los servicios del mismo proyecto que la instancia, como BigQuery y Dataproc. Para conocer todos los servicios admitidos, consulta la función detalles.
  • La cuenta de servicio de Cloud Data Fusion realiza las siguientes acciones:
    • Comunicación del plano de datos (diseño y ejecución de la canalización) con otros servicios (por ejemplo, comunicarse con Cloud Storage, BigQuery y Datastream en el momento del diseño).
    • Aprovisiona clústeres de Dataproc.
  • Si replicarás desde una fuente de Oracle, a esta cuenta de servicio también se le deben otorgar los roles de administrador de Datastream y de administrador de almacenamiento en el proyecto en el que se realiza la tarea. En esta página, no se aborda un para tu caso de uso de replicación de datos.

Para este caso de uso, otorga el rol de agente de servicio de la API de Cloud Data Fusion a la cuenta de servicio en el proyecto de Dataproc. Luego, otorga los siguientes roles en ese proyecto:

  • Función de usuario de red de Compute
  • Rol de editor de Dataproc

IAM: Cuenta de servicio de Dataproc

Modelo de referencia Caso de uso

La cuenta de servicio que se usa para ejecutar la canalización como un trabajo en el clúster de Dataproc. De forma predeterminada, es el Cuenta de servicio de Compute Engine.


Opcional: En la configuración del modelo de referencia, puedes cambiar el valor predeterminado a otra cuenta de servicio del mismo proyecto. Otorgar los siguientes roles de IAM a la nueva cuenta de servicio:

  • La función de ejecutor de Cloud Data Fusion. Este rol te permite Dataproc se comunica con la API de Cloud Data Fusion.
  • La función de trabajador de Dataproc Este rol permite que los trabajos se ejecuten clústeres de Dataproc.
Conclusiones clave:
  • Se debe otorgar la cuenta de servicio del agente de API para el servicio nuevo. el rol Usuario de cuenta de servicio en el servicio de Dataproc de manera que el agente de API de servicio pueda usarla para iniciar clústeres de Dataproc.

En este ejemplo de caso de uso, se supone que usas Cuenta de servicio de Compute Engine (PROJECT_NUMBER-compute@developer.gserviceaccount.com) del proyecto de Dataproc.


Otorga los siguientes roles al servicio predeterminado de Compute Engine en el proyecto de Dataproc.

  • La función de trabajador de Dataproc
  • El rol Administrador de almacenamiento (o, como mínimo, “storage.buckets.create”) para permitir que Dataproc crear buckets temporales para BigQuery.
  • Rol de usuario del trabajo de BigQuery. Este rol permite que Dataproc cree trabajos de carga. Los trabajos se crean en Dataproc proyecto de forma predeterminada.
  • Rol de editor de conjuntos de datos de BigQuery Este rol te permite Dataproc crea conjuntos de datos mientras se cargan los datos.

Otorga el rol Usuario de cuenta de servicio a Cloud Data Fusion Cuenta de servicio en la cuenta de servicio predeterminada de Compute Engine de el proyecto de Dataproc. Esta acción debe realizarse proyecto de Dataproc.

Agrega la cuenta de servicio predeterminada de Compute Engine de la del proyecto de Dataproc al proyecto de Cloud Data Fusion. También otorga los siguientes roles:

  • El rol Visualizador de objetos de Storage para recuperar trabajos de canalización relacionados artefactos del bucket de consumidor de Cloud Data Fusion.
  • rol de ejecutor de Cloud Data Fusion, por lo que clúster puede comunicarse con Cloud Data Fusion mientras está en ejecución.

API

Modelo de referencia Caso de uso
Cuando habilitas la API de Cloud Data Fusion, se usan las siguientes APIs: también está habilitada. Para obtener más información sobre estas APIs, visita la APIs y de Google Cloud en tu proyecto.

Ir a APIs y servicios

  • API de Cloud Autoscaling
  • API de Dataproc
  • API de control de Cloud Dataproc
  • Cloud DNS API
  • API de Cloud OS Login
  • API de Pub/Sub
  • API de Compute Engine
  • API de Container Filesystem
  • API de Container Registry
  • API de Service Account Credentials
  • API de Identity and Access Management
  • API de Google Kubernetes Engine

Cuando habilitas la API de Cloud Data Fusion, los siguientes servicios automáticamente se agregan cuentas a tu proyecto:

  • Agente de servicios de las API de Google
  • Agente de servicio de Compute Engine
  • Agente de servicios de Kubernetes Engine
  • Agente de servicio de Google Container Registry
  • Agente de servicio de Google Cloud Dataproc
  • Agente de servicio de Cloud KMS
  • Cuenta de servicio de Cloud Pub/Sub
 Para este caso de uso, habilita las siguientes APIs en el proyecto que Contiene el proyecto de Dataproc:
  • API de Compute Engine
  • la API de Dataproc (probablemente ya esté habilitada en este proyecto). La API de control de Dataproc se habilita automáticamente cuando habilitar la API de Dataproc.
  • API de Resource Manager.

Claves de encriptación

Modelo de referencia Caso de uso

En la configuración del modelo de referencia, las claves de encriptación pueden ser administradas por Google o CMEK.


Conclusiones clave:

Si usas CMEK, la configuración de tu modelo de referencia requiere lo siguiente:

  • La clave debe ser regional y crearse en la misma región que el instancia de Cloud Data Fusion.
  • Otórgale el rol de Encriptador/Desencriptador de CryptoKey de Cloud KMS al siguientes cuentas de servicio a nivel de clave (no en el página de IAM de la consola de Google Cloud) en el proyecto donde se crea:
    • Cuenta de servicio de la API de Cloud Data Fusion
    • de Dataproc, que es la cuenta de servicio Agente de servicio de Engine (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com) De forma predeterminada,
    • Agente de servicio de Google Cloud Dataproc (service-PROJECT_NUMBER@dataproc-accounts.iam.gserviceaccount.com)
    • Agente de servicio de Cloud Storage (service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com)

Según los servicios que se usen en tu canalización, como BigQuery o Cloud Storage, las cuentas de servicio también deben tener el rol de Encriptador o Desencriptador de CryptoKey de Cloud KMS:

  • La cuenta de servicio de BigQuery (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com)
  • La cuenta de servicio de Pub/Sub (service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com)
  • La cuenta de servicio de Spanner (service-PROJECT_NUMBER@gcp-sa-spanner.iam.gserviceaccount.com)

Si no usas CMEK, no es necesario realizar cambios adicionales para este caso de uso.

Si usas CMEK, la función de Encriptador/Desencriptador de CryptoKey de Cloud KMS debe a la siguiente cuenta de servicio a nivel de clave en el proyecto en el que se crea:

  • Agente de servicio de Cloud Storage (service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com)

Según los servicios que se usen en tu canalización, como BigQuery o Cloud Storage, a otras cuentas de servicio también se les debe otorgar el rol de encriptador/desencriptador de CryptoKey de Cloud KMS a nivel de la clave. Por ejemplo:

  • La cuenta de servicio de BigQuery (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com)
  • La cuenta de servicio de Pub/Sub (service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com)
  • La cuenta de servicio de Spanner (service-PROJECT_NUMBER@gcp-sa-spanner.iam.gserviceaccount.com)

Luego de hacer estos parámetros de configuración específicos para casos de uso, comiencen a ejecutarse en clústeres de otro proyecto.

¿Qué sigue?