Caso práctico: control de acceso a un clúster de Dataproc en otro proyecto

En esta página se describe cómo gestionar el control de acceso al implementar y ejecutar una canalización que usa clústeres de Dataproc en otro proyecto. Google Cloud

Situación

De forma predeterminada, cuando se inicia una instancia de Cloud Data Fusion en unGoogle Cloud proyecto, se implementan y ejecutan flujos de trabajo mediante clústeres de Dataproc en el mismo proyecto. Sin embargo, es posible que tu organización te exija que uses clústeres en otro proyecto. En este caso práctico, debes gestionar el acceso entre los proyectos. En la página siguiente se describe cómo puedes cambiar las configuraciones de referencia (predeterminadas) y aplicar los controles de acceso adecuados.

Antes de empezar

Para entender las soluciones de este caso práctico, debes tener en cuenta lo siguiente:

Supuestos y alcance

Este caso práctico tiene los siguientes requisitos:

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

Solución

Esta solución compara la arquitectura y la configuración de la línea de base con las de un caso práctico específico.

Arquitectura

En los siguientes diagramas se compara la arquitectura de proyectos para crear una instancia de Cloud Data Fusion y ejecutar flujos de procesamiento cuando se usan clústeres en el mismo proyecto (configuración de referencia) y en un proyecto diferente a través de la VPC del proyecto de inquilino.

Arquitectura de referencia

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

Arquitectura de proyectos de inquilinos, clientes y Dataproc en Cloud Data Fusion.

Para la configuración de referencia, crea una instancia privada de Cloud Data Fusion y ejecuta un flujo de procesamiento sin ninguna personalización adicional:

  • Usas uno de los perfiles de cálculo integrados
  • El origen y el receptor están en el mismo proyecto que la instancia
  • No se ha concedido ningún rol adicional a ninguna de las cuentas de servicio

Para obtener más información sobre los proyectos de propietario y de cliente, consulta Redes.

Arquitectura de caso práctico

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

Arquitectura de proyectos de inquilinos, clientes y Dataproc en Cloud Data Fusion.

Configuraciones

En las siguientes secciones se comparan las configuraciones de referencia con las configuraciones específicas de los casos prácticos para usar clústeres de Dataproc en otro proyecto a través de la VPC del proyecto de inquilino predeterminado.

En las siguientes descripciones de casos prácticos, el proyecto del cliente es donde 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 de inquilino

Valor de referencia Caso práctico
En el diagrama de arquitectura de referencia anterior, el proyecto de inquilino 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 es necesario configurar nada más para este caso práctico.

Proyecto de cliente

Valor de referencia Caso práctico
Tu Google Cloud proyecto es donde implementas y ejecutas las canalizaciones. De forma predeterminada, los clústeres de Dataproc se inician en este proyecto cuando ejecutas tus flujos de procesamiento. En este caso práctico, gestionas dos proyectos. En esta página, el proyecto del cliente hace referencia a la ubicación en la que se ejecuta la instancia de Cloud Data Fusion.
El proyecto de Dataproc hace referencia a donde se inician los clústeres de Dataproc.

VPC del cliente

Valor de referencia Caso práctico

Desde tu perspectiva (la del cliente), la VPC del cliente es donde se encuentra Cloud Data Fusion de forma lógica.


Información clave:
Puedes consultar los detalles de la VPC del cliente en la página de redes de VPC de tu proyecto.

Ve a Redes de VPC

 No es necesario configurar nada más para este caso práctico.

Subred de Cloud Data Fusion

Valor de referencia Caso práctico

Desde tu perspectiva (la del cliente), esta subred es donde se encuentra Cloud Data Fusion de forma lógica.


Información clave:
La región de esta subred es la misma que la ubicación de la instancia de Cloud Data Fusion en el proyecto de inquilino. 		No es necesario configurar nada más para este caso práctico.

Subred de Dataproc

Valor de referencia Caso práctico

La subred en la que se inician los clústeres de Dataproc cuando ejecutas un flujo de procesamiento.


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

Se trata de una nueva subred en la que se inician los clústeres de Dataproc cuando ejecutas un flujo de procesamiento.


Conclusiones principales:
  • En esta nueva subred, define el Acceso privado de Google como Activado.
  • No es necesario que la subred de Dataproc esté en la misma ubicación que la instancia de Cloud Data Fusion.

Fuentes y sumideros

Valor de referencia Caso práctico

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


Conclusión principal:
  • Las tareas que obtienen y cargan datos deben procesarse en la misma ubicación que el conjunto de datos. De lo contrario, se producirá un error.
 Las configuraciones de control de acceso específicas de los casos prácticos de esta página son para fuentes y receptores de BigQuery.

Cloud Storage

Valor de referencia Caso práctico

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


Conclusiones principales:
  • Puedes especificar este bucket a través de la interfaz web de Cloud Data Fusion en la configuración de Perfil de computación de los clústeres efímeros.
  • En el caso de los flujos de procesamiento por lotes y en tiempo real, o de las tareas de replicación, si no especificas un bucket en el perfil de cálculo, Cloud Data Fusion creará un bucket en el mismo proyecto que la instancia para este fin.
  • Incluso en el caso de los clústeres de Dataproc estáticos, en esta configuración de referencia, Cloud Data Fusion crea el segmento, que es diferente de los segmentos de staging y temporales 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 es necesario configurar nada más para este caso práctico.

Contenedores temporales usados por la fuente y el receptor

Valor de referencia Caso práctico

Los contenedores temporales creados por los complementos de tus fuentes y receptores, como las tareas de carga iniciadas por el complemento BigQuery Sink.


Conclusiones principales:
  • Puedes definir estos contenedores al configurar las propiedades del complemento de origen y de receptor.
  • Si no defines un segmento, se creará uno en el mismo proyecto en el que se ejecute Dataproc.
  • Si el conjunto de datos es multirregional, el segmento se crea en el mismo ámbito.
  • Si defines un segmento en la configuración del complemento, la región del segmento debe coincidir con la del conjunto de datos.
  • Si no defines ningún contenedor en las configuraciones del complemento, el que se crea automáticamente se elimina cuando finaliza la canalización.
 En este caso, el contenedor se puede crear en cualquier proyecto.

Contenedores que son fuentes o receptores de datos para complementos

Valor de referencia Caso práctico
Los segmentos de cliente, que se especifican en las configuraciones de los complementos, como el complemento Cloud Storage y el complemento FTP a Cloud Storage. No es necesario configurar nada más para este caso práctico.

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

Valor de referencia Caso práctico

Cuando se habilita la API de Cloud Data Fusion, el rol Agente de servicio de la API de Cloud Data Fusion (roles/datafusion.serviceAgent) se asigna automáticamente a la cuenta de servicio de Cloud Data Fusion, que es el agente de servicio principal.


Conclusiones principales:
  • El rol contiene permisos para servicios del mismo proyecto que la instancia, como BigQuery y Dataproc. Para ver todos los servicios admitidos, consulta los detalles de los roles.
  • La cuenta de servicio de Cloud Data Fusion hace lo siguiente:
    • Comunicación del plano de datos (diseño y ejecución de la canalización) con otros servicios (por ejemplo, comunicación con Cloud Storage, BigQuery y Datastream en tiempo de diseño).
    • Provisiona clústeres de Dataproc.
  • Si vas a replicar datos desde una fuente de Oracle, también debes asignar a esta cuenta de servicio los roles Administrador de Datastream y Administrador de almacenamiento en el proyecto en el que se realiza el trabajo. En esta página no se aborda ningún caso práctico de replicación.

En este caso, asigna el rol Agente de servicio de la API Cloud Data Fusion a la cuenta de servicio del proyecto de Dataproc. A continuación, concede los siguientes roles en ese proyecto:

  • Rol Usuario de red de Compute
  • Rol Editor de Dataproc

Gestión de identidades y accesos: cuenta de servicio de Dataproc

Valor de referencia Caso práctico

La cuenta de servicio que se usa para ejecutar el flujo de procesamiento como una tarea en el clúster de Dataproc. De forma predeterminada, es la cuenta de servicio de Compute Engine.


Opcional: En la configuración de referencia, puedes cambiar la cuenta de servicio predeterminada por otra cuenta de servicio del mismo proyecto. Asigna los siguientes roles de gestión de identidades y accesos a la nueva cuenta de servicio:

  • Rol Ejecutor de Cloud Data Fusion. Este rol permite que Dataproc se comunique con la API de Cloud Data Fusion.
  • Rol Trabajador de Dataproc. Este rol permite que las tareas se ejecuten en clústeres de Dataproc.
Conclusiones principales:
  • Se debe conceder a la cuenta de servicio del agente de la API del nuevo servicio el rol Usuario de cuenta de servicio en la cuenta de servicio de Dataproc para que el agente de la API de servicio pueda usarla para iniciar clústeres de Dataproc.

En este ejemplo de caso práctico, se presupone que usas la cuenta de servicio predeterminada de Compute Engine (PROJECT_NUMBER-compute@developer.gserviceaccount.com) del proyecto de Dataproc.


Concede los siguientes roles a la cuenta de servicio predeterminada de Compute Engine en el proyecto de Dataproc.

  • Rol Trabajador de Dataproc
  • El rol Administrador de Storage (o, como mínimo, el permiso `storage.buckets.create`) para permitir que Dataproc cree segmentos temporales para BigQuery.
  • Rol Usuario de tareas de BigQuery. Este rol permite a Dataproc crear tareas de carga. Las tareas se crean de forma predeterminada en el proyecto de Dataproc.
  • Rol Editor de conjuntos de datos de BigQuery. Este rol permite que Dataproc cree conjuntos de datos al cargar datos.

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

Añada la cuenta de servicio predeterminada de Compute Engine del proyecto de Dataproc al proyecto de Cloud Data Fusion. También debe conceder los siguientes roles:

  • El rol Lector de objetos de Storage para recuperar artefactos relacionados con las tareas de la canalización del segmento de Cloud Data Fusion Consumer.
  • Rol Ejecutor de Cloud Data Fusion para que el clúster de Dataproc pueda comunicarse con Cloud Data Fusion mientras se está ejecutando.

APIs

Valor de referencia Caso práctico
Cuando habilitas la API Cloud Data Fusion, también se habilitan las siguientes APIs. Para obtener más información sobre estas APIs, vaya a la página APIs y servicios de su proyecto.

Ir a APIs y servicios

  • API Cloud Autoscaling
  • API de Dataproc
  • API Cloud Dataproc Control
  • Cloud DNS API
  • API de Cloud OS Login
  • Pub/Sub API
  • API de Compute Engine
  • API Container Filesystem
  • API de Container Registry
  • API Service Account Credentials
  • API de gestión de identidades y accesos
  • API de Google Kubernetes Engine

Cuando habilitas la API de Cloud Data Fusion, las siguientes cuentas de servicio se añaden automáticamente a tu proyecto:

  • Agente de servicios de APIs 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
 En este caso práctico, habilita las siguientes APIs en el proyecto que contiene el proyecto de Dataproc:
  • API de Compute Engine
  • API de Dataproc (es probable que ya esté habilitada en este proyecto). La API Control de Dataproc se habilita automáticamente cuando habilitas la API de Dataproc.
  • API de Resource Manager.

Claves de encriptado

Valor de referencia Caso práctico

En la configuración de referencia, las claves de cifrado pueden ser gestionadas por Google o CMEK


Conclusiones principales:

Si utilizas CMEK, tu configuración de referencia debe cumplir los siguientes requisitos:

  • La clave debe ser regional y crearse en la misma región que la instancia de Cloud Data Fusion.
  • Asigna el rol Encargado del encriptado y desencriptado de la clave criptográfica Cloud KMS a las siguientes cuentas de servicio a nivel de clave (no en la página IAM de la consola de Google Cloud ) en el proyecto en el que se haya creado:
    • Cuenta de servicio de la API de Cloud Data Fusion
    • Cuenta de servicio de Dataproc, que es el agente de servicio de Compute 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)

En función de los servicios que se utilicen en tu canalización, como BigQuery o Cloud Storage, también se debe conceder a las cuentas de servicio el rol Encargado del encriptado y desencriptado de la clave criptográfica 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 tienes que hacer ningún cambio adicional para este caso práctico.

Si usas CMEK, debes asignar el rol Encargado del encriptado y desencriptado de la clave criptográfica Cloud KMS a la siguiente cuenta de servicio a nivel de clave en el proyecto en el que se cree:

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

En función de los servicios que se utilicen en tu canalización, como BigQuery o Cloud Storage, también se debe asignar el rol de encargado de cifrar o descifrar claves de CryptoKey de Cloud KMS a otras cuentas de servicio a nivel de 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)

Una vez que hayas realizado estas configuraciones específicas para tu caso práctico, tu flujo de datos podrá empezar a ejecutarse en clústeres de otro proyecto.

Siguientes pasos