data lake kerberizado en Dataproc

Last reviewed 2024-04-16 UTC

En este documento, se describen los conceptos, las prácticas recomendadas y la arquitectura de referencia para las herramientas de redes, la autenticación y la autorización de un data lake kerberizado en Google Cloud conDataproc centro de distribución de claves (KDC) en el clúster yApache Ranger. Dataproc es el servicio administrado de Hadoop y Spark de Google Cloud. Este documento está dirigido a los administradores de Apache Hadoop, los arquitectos de la nube y los equipos de macrodatos que migran sus clústeres tradicionales de Hadoop y Spark a un data lake moderno con tecnología de Dataproc.

Un data lake kerberizado en Google Cloud ayuda a las organizaciones con implementaciones de nubes híbridas y múltiples a extender y usar sus inversiones de TI existentes en la administración de identidades y controles de acceso.

En Google Cloud, las organizaciones pueden proporcionar a sus equipos tantos clústeres efímeros y dirigidos al trabajo como sea necesario. Este enfoque quita gran parte de la complejidad de mantener un solo clúster con interacciones de configuración de software y dependencias crecientes. Las organizaciones también pueden crear clústeres de mayor ejecución para que varios usuarios y servicios puedan acceder a estos. En este documento, se muestra cómo usar las herramientas estándar de la industria, como Kerberos y Apache Ranger, para garantizar la seguridad detallada del usuario (autenticación, autorización y auditoría) para ambos casos de clústeres en Dataproc.

Caso de uso de cliente

Las empresas migran sus data lakes locales basados en Hadoop a plataformas de nube pública para resolver los desafíos que enfrentan cuando administran sus clústeres tradicionales.

Una de estas organizaciones, un gran líder en tecnología de software y hardware empresarial, decidió migrar su sistema Hadoop local a Google Cloud. Su entorno local de Hadoop se encargaba de las necesidades de estadísticas de cientos de equipos y unidades de negocios, incluido su equipo de seguridad cibernética integrado por 200 miembros de equipo de análisis de datos. Cuando un miembro del equipo ejecutaba una consulta grande con su data lake heredado, experimentaban problemas debido a la naturaleza rígida de los recursos. La organización tenía problemas para mantenerse al día con las necesidades de estadísticas del equipo mediante su entorno local, por lo que se trasladaron a Google Cloud. Con la migración aGoogle Cloud, la organización pudo reducir en un 25% la cantidad de problemas que se informaban en su lago de datos local todos los meses.

La base del plan de migración de la organización a Google Cloud fue la decisión de redefinir y optimizar sus grandes clústeres monolíticos en función de las cargas de trabajo de los equipos, y cambiar el enfoque de la administración de clústeres para liberar valor empresarial. Los pocos clústeres grandes se dividieron en clústeres más pequeños y rentables de Dataproc, y las cargas de trabajo y los equipos se migraron a los siguientes tipos de modelos:

  • Clústeres efímeros con alcance definido trabajo: con solo unos minutos de inicio, el modelo efímero permite que un trabajo o un flujo de trabajo tenga un clúster dedicado que se cierra cuando se completa el trabajo. En este patrón, se separa el almacenamiento de los nodos de procesamiento mediante la sustitución del sistema de archivos distribuido de Hadoop (HDFS) con Cloud Storage mediante el conector de Cloud Storage para Hadoop integrado de Dataproc.
  • Clústeres de semilarga duración: cuando los clústeres efímeros y dirigidos al trabajo no pueden entregar el caso de uso, los clústeres de Dataproc pueden ser de larga duración. Cuando los datos con estado del clúster se descargan en Cloud Storage, el clúster se puede cerrar con facilidad y se considera de semilarga duración. El ajuste de escala automático inteligente del clúster también permite que estos clústeres comiencen en un nivel bajo y optimicen sus recursos de procesamiento para aplicaciones específicas. Este ajuste de escala automático reemplaza la administración de las colas de YARN.

El desafío de la seguridad híbrida

En la situación de cliente anterior, el cliente migró su sistema de administración de datos sustancial a la nube. Sin embargo, otras partes de la TI de la organización necesitaban permanecer en el entorno local (por ejemplo, algunos de los sistemas operativos heredados que alimentan el data lake).

La arquitectura de seguridad necesaria para garantizar que el proveedor de identidad (IdP) central basado en LDAP siga siendo la fuente autorizada para sus identidades corporativas mediante el data lake. La seguridad local de Hadoop se basa en Kerberos y LDAP para la autenticación (a menudo, como parte de Active Directory (AD) de Microsoft de la organización) y en varios otros productos de software de código abierto (OSS), como Apache Ranger. Este enfoque de seguridad permite una autorización y una auditoría detalladas de las actividades de los usuarios y de los equipos en los clústeres de data lakes. EnGoogle Cloud, la administración de identidades y accesos (IAM) se usa para administrar el acceso a recursos Google Cloud específicos, como Dataproc y Cloud Storage.

En este documento, se analiza un enfoque de seguridad en el que se usa lo mejor de la seguridad local y de OSS Hadoop (se enfoca en Kerberos, LDAP corporativo y Apache Ranger) junto con IAM para ayudar a proteger los datos y las cargas de trabajo dentro y fuera de los clústeres de Hadoop.

Arquitectura

En el siguiente diagrama, se muestra la arquitectura de alto nivel:

La arquitectura de alto nivel de un data lake kerberizado en Google Cloud con Dataproc.

En el diagrama anterior, los clientes ejecutan trabajos en clústeres de varios equipos o de un solo equipo. Los clústeres usan un almacén de metadatos central de Hive y la autenticación de Kerberos con un proveedor de identidad corporativa.

Componentes

La arquitectura propone una combinación de herramientas de código abierto estándar de la industria y de IAM para autenticar y autorizar las diferentes formas de enviar trabajos que se describen más adelante en este documento. Los siguientes son los componentes principales que trabajan en conjunto para proporcionar una seguridad detallada de las cargas de trabajo de los equipos y de los usuarios en los clústeres de Hadoop:

  • Kerberos: Kerberos es un protocolo de autenticación de red que usa criptografía de claves secretas a fin de proporcionar autenticación sólida para aplicaciones cliente/servidor. El servidor Kerberos se conoce como centro de distribución de claves (KDC).

    Kerberos se usa mucho en sistemas locales como AD para autenticar usuarios humanos, servicios y máquinas (las entidades de cliente se denotan como principales de usuario). La habilitación de Kerberos en Dataproc usa la distribución de MIT de Kerberos gratuita para crear un KDC en el clúster. El KDC en el clúster de Dataproc entrega solicitudes de los principales de usuario para acceder a los recursos dentro del clúster, como Apache Hadoop YARN, HDFS y Apache Spark (los recursos del servidor se denotan como principales de servicio). La confianza entre dominios de Kerberos te permite conectar los principales de usuario de un dominio a otro.

  • Apache Ranger: Apache Ranger proporciona autorización detallada para que los usuarios realicen acciones específicas en los servicios de Hadoop. También audita el acceso de los usuarios para implementar acciones administrativas. Ranger puede sincronizarse con un servidor LDAP local corporativo o con AD para obtener identidades de usuario y servicios.

  • Almacén de metadatos compartido de Hive: el almacén de metadatos de Hive es un servicio que almacena metadatos de Apache Hive y otras herramientas de Hadoop. Debido a que muchas de estas herramientas se compilan en torno a él, el almacén de metadatos de Hive se convirtió en un componente crítico de muchos data lakes. En la arquitectura propuesta, un almacén de metadatos de Hive centralizado y kerberizado permite que varios clústeres compartan metadatos de forma segura.

Si bien Kerberos, Ranger y un almacén de metadatos de Hive compartido trabajan juntos para permitir una seguridad detallada del usuario dentro de los clústeres de Hadoop, IAM controla el acceso a los recursos de Google Cloud . Por ejemplo, Dataproc usa la cuenta de servicio de Dataproc para realizar operaciones de lectura y escritura en buckets de Cloud Storage.

Dimensiones del clúster

Las siguientes dimensiones caracterizan a un clúster de Dataproc:

  • Instancia: un clúster es multiusuario si entrega las solicitudes de más de un usuario o servicio humano, o de un solo usuario si entrega solicitudes de un solo usuario o servicio.
  • Kerberos: Un clúster puede estar kerberizado si habilitas Kerberos en Dataproc o no kerberizado si no habilitas Kerberos en Dataproc.
  • Ciclo de vida: Un clúster es efímero si se crea solo durante la duración de un trabajo o flujo de trabajo específico, contiene solo los recursos necesarios para ejecutarlo y se cierra cuando finaliza el trabajo. De lo contrario, el clúster se considera de semilarga duración.

Las diferentes combinaciones de estas dimensiones determinan los casos de uso para los que un clúster específico es más adecuado. En este documento, se analizan los siguientes ejemplos representativos:

  1. Los clústeres de varios equipos de muestra que se muestran en la arquitectura son clústeres kerberizados, de multiusuarios y de semilarga duración. Estos clústeres son más adecuados para las cargas de trabajo interactivas de consultas, por ejemplo, que entregan análisis de datos a largo plazo y exploración de inteligencia empresarial (IE). En la arquitectura, los clústeres se encuentran en un proyecto de Google Cloud que comparten varios equipos y entrega las solicitudes de esos equipos, por eso se llama así.

    En este documento, el término equipo o equipo de aplicaciones describe un grupo de personas en una organización que trabajan en el mismo componente de software o que actúan como un equipo funcional. Por ejemplo, un equipo puede referirse a desarrolladores de backend de un microservicio, analistas de IE de una aplicación empresarial o incluso equipos multifuncionales, como equipos de infraestructura de macrodatos.

  2. Los clústeres de un solo equipo de muestra que se muestran en la arquitectura son clústeres de multiusuario (para los miembros del mismo equipo) o de usuarios únicos.

  • Como clústeres efímeros, los clústeres de un solo equipo pueden usarlos en trabajos, por ejemplo, los ingenieros de datos para ejecutar trabajos de procesamiento por lotes de Spark o científicos de datos para un trabajo de entrenamiento de modelos.
  • Como clústeres de larga duración, los clústeres de un solo equipo pueden entregar estadísticas de datos y cargas de trabajo de IE orientadas a un solo equipo o persona.

    Los clústeres de equipo único se encuentran en proyectos de Google Cloud que pertenecen a un solo equipo, lo que simplifica la auditoría de uso, la facturación y el aislamiento de recursos. Por ejemplo, solo los miembros del equipo único pueden acceder a los buckets de Cloud Storage que se usan para conservar los datos del clúster. En este enfoque, los equipos de aplicaciones tienen proyectos dedicados, por lo que los clústeres de un solo equipo no están kerberizados.

Te recomendamos que analices tus requisitos particulares y elijas las mejores combinaciones de dimensiones para tu situación.

Envía trabajos

Los usuarios pueden enviar trabajos a ambos tipos de clústeres mediante varias herramientas, incluidas las siguientes:

  • La API de Dataproc mediante llamadas de REST o bibliotecas cliente
  • La herramienta de línea de comandos de gcloud de Google Cloud CLI en una ventana de la terminal local o desde la consola de Google Cloud enCloud Shell abierta en un navegador local.
  • Una plantilla de flujo de trabajo de Dataproc, que es una configuración de flujo de trabajo reutilizable que define un grafo de trabajos con información sobre los lugares en que se deben ejecutar. Si el flujo de trabajo usa la opción de clúster administrado, usa un clúster efímero.
  • Cloud Composer con el Operador de Dataproc. Los grafos acíclicos dirigidos (DAG) de Composer también se pueden usar para organizar plantillas de flujos de trabajo de Dataproc.
  • Abrir una sesión SSH en el nodo principal del clúster y enviar un trabajo de forma directa o mediante herramientas como Apache Beeline Por lo general, esta herramienta está reservada solo para administradores y power users. Un ejemplo de un power user es un desarrollador que desea solucionar problemas de los parámetros de configuración para un servicio y verificarlos mediante la ejecución de trabajos de prueba directamente en el nodo principal.

Herramientas de redes

En el siguiente diagrama, se destacan los conceptos de herramientas de redes de la arquitectura:

Una arquitectura de herramientas de redes que usa un patrón de malla híbrida.

En el diagrama anterior, la arquitectura de red usa un patrón híbrido de malla, en el que algunos recursos se encuentran en Google Cloudy otros en el entorno local. El patrón híbrido de malla usa una VPC compartida, con un proyecto host común y proyectos separados para cada tipo y equipo de clúster de Dataproc. La arquitectura se describe en detalle en las siguientes secciones En Google Cloud y Local.

El Google Cloud

En Google Cloud, la arquitectura se estructura mediante una VPC compartida. Una VPC compartida permite que los recursos de varios proyectos se conecten a una red de VPC común. El uso de una red de VPC común permite que los recursos se comuniquen entre sí de manera segura y eficiente mediante las direcciones IP internas de esa red. Para configurar una VPC compartida, crea los siguientes proyectos:

  • Proyecto host: El proyecto host contiene una o más redes de VPC compartidas que usan todos los proyectos de servicio.
  • Proyectos de servicio: Un proyecto de servicio contiene recursos deGoogle Cloud relacionados. Un administrador de VPC compartida adjunta los proyectos de servicio al proyecto host para que puedan usar subredes y recursos en la red de VPC compartida. Este adjunto es esencial para que los clústeres de un solo equipo puedan acceder al almacén de metadatos centralizado de Hive.

    Como se muestra en el diagrama de herramientas de redes, recomendamos crear proyectos de servicios independientes para el clúster del almacén de metadatos de Hive, los clústeres de varios equipos y los clústeres de cada equipo individual. Los miembros de cada equipo de la organización pueden crear clústeres de un solo equipo dentro de los respectivos proyectos.

Para permitir que los componentes dentro de la red híbrida se comuniquen, debes configurar las reglas de firewall a fin de permitir el siguiente tráfico:

  • Tráfico del clúster interno para que los servicios de Hadoop, incluido HDFS NameNode, se comuniquen con HDFS DataNodes y para que ResourceManager de YARN se comunique con NodeManagers de YARN. Te recomendamos usar el filtrado con la cuenta de servicio del clúster para estas reglas.
  • Tráfico del clúster externo en puertos específicos para comunicarse con el almacén de metadatos de Hive (puerto tcp:9083,8020), KDC local (puerto tcp:88) y LDAP (puerto 636) y otros servicios externos centralizados que usas en tu situación particular, por ejemplo, Kafka en Google Kubernetes Engine (GKE).

Todos los clústeres de Dataproc en esta arquitectura se crean solo con direcciones IP internas. Para permitir que los nodos del clúster accedan a las APIs y a los servicios de Google, debes habilitar el Acceso privado a Google para las subredes del clúster. Para permitir que los administradores y los power users accedan a las instancias de VM de direcciones IP privadas, usa el reenvío de TCP de IAP para reenviar SSH, RDP y otro tráfico a través de un túnel encriptado.

Se accede de forma segura a las interfaces web de clústeres de las aplicaciones de clústeres y los componentes opcionales (por ejemplo, Spark, Hadoop, Jupyter y Zeppelin) mediante la Puerta de enlace de componentes de Dataproc. La Puerta de enlace de componentes de Dataproc es una HTTP, un proxy de inversión basado en Apache Knox.

Local

En este documento, se supone que los recursos ubicados de manera local son el servicio corporativo del directorio LDAP y el centro de distribución de claves (KDC) corporativo de Kerberos en el que se definen los principales de servicio de equipo y usuario. Si no necesitas usar un proveedor de identidad local, puedes simplificar la configuración con Cloud Identity y un KDC en un clúster de Dataproc o en una máquina virtual.

Para comunicarte con LDAP y KDC locales, usa Cloud Interconnect o Cloud VPN. Esta configuración ayuda a garantizar que la comunicación entre entornos use direcciones IP privadas si las subredes de la dirección IP RFC 1918 no se superponen. Para obtener más información sobre las diferentes opciones de conexión, consulta Elige un producto de conectividad de red.

En un entorno híbrido, tus solicitudes de autenticación deben manejarse con latencia mínima. Para lograr este objetivo, puedes usar las siguientes técnicas:

  • Entrega todas las solicitudes de autenticación para identidades de servicio desde el KDC en el clúster y solo usa un proveedor de identidad externo al clúster para las identidades de usuario. Se espera que la mayor parte del tráfico de autenticación sean solicitudes de identidades de servicio.
  • Si usas AD como tu proveedor de identidad, los nombres principales de usuario (UPN) representan a los usuarios humanos y las cuentas de servicio de AD. Te recomendamos que repliques los UPN de tu AD local en una Google Cloud región que esté cerca de los clústeres de tu data lake. Esta réplica de AD controla las solicitudes de autenticación de UPN, por lo que las solicitudes nunca se trasladan a tu AD local. Cada KDC en el clúster controla los nombres principales de servicio (SPN) mediante la primera técnica.

En el siguiente diagrama, se muestra una arquitectura que usa ambas técnicas:

Un AD local sincroniza los UPN con una réplica de AD, mientras que un KDC en el clúster autentica los UPN y SPN.

En el diagrama anterior, un AD local sincroniza los UPN con una réplica de AD en una región de Google Cloud . La réplica de AD autentica los UPN, y un KDC en el clúster autentica los SPN.

Para obtener información sobre la implementación de AD en Google Cloud, consulta Implementa un entorno de Microsoft Active Directory tolerante a errores. Para obtener información sobre cómo dimensionar la cantidad de instancias de controladores de dominio, consulta Integra Kerberos MIT y Active Directory.

Autenticación

En el siguiente diagrama, se muestran los componentes que se usan para autenticar usuarios en los diferentes clústeres de Hadoop. La autenticación permite a los usuarios usar servicios como Apache Hive o Apache Spark.

Los componentes autentican a los usuarios en diferentes clústeres de Hadoop.

En el diagrama anterior, los clústeres de los dominios de Kerberos pueden configurar la confianza entre dominios para usar servicios en otros clústeres, como el almacén de metadatos de Hive. Los clústeres no kerberizados pueden usar un cliente de Kerberos y un keytab de cuenta para usar servicios en otros clústeres.

Almacén de metadatos compartido y seguro de Hive

El almacén de metadatos centralizado de Hive permite que varios clústeres que ejecutan diferentes motores de consultas de código abierto, como Apache Spark, Apache Hive/Beeline y Presto, compartan metadatos.

Implementas el servidor del almacén de metadatos de Hive en un clúster de Dataproc kerberizado y, luego, implementas la base de datos del almacén de metadatos de Hive en un RDBMS remoto, como una instancia de MySQL en Cloud SQL. Como servicio compartido, un clúster del almacén de metadatos de Hive solo entrega solicitudes autenticadas. Para obtener más información sobre la configuración del almacén de metadatos de Hive, consulta Usa Apache Hive en Dataproc.

En lugar del almacén de metadatos de Hive, puedes usar Dataproc Metastore, un almacén de metadatos de Apache Hive sin servidores de reparación automática y de alta disponiblidad (dentro de una región). También puedes habilitar Kerberos para el servicio de Dataproc Metastore, como se explica en Configura Kerberos para un servicio.

Kerberos

En esta arquitectura, los clústeres de varios equipos se usan para fines estadísticos y se kerberizan mediante la guía para la configuración de seguridad de Dataproc. El modo seguro de Dataproc crea un KDC en el clúster y administra los principales de servicio y los archivos keytab del clúster, como lo requiere la especificación del modo seguro de Hadoop.

Un keytab es un archivo que contiene uno o más pares de principales de Kerberos y una copia encriptada de la clave de ese principal. Un keytab permite la autenticación programática de Kerberos cuando no se puede acceder mediante el comando kinit interactivo.

El acceso a un archivo keytab significa la capacidad de robar la identidad de los principales que están contenidos en él. Por lo tanto, un archivo keytab es un archivo altamente sensible que debe transferirse y almacenarse de forma segura. Recomendamos usar Secret Manager para almacenar el contenido de los archivos keytab antes de que se transfieran a sus clústeres respectivos. Para obtener un ejemplo de cómo almacenar el contenido de archivo keytab, consulta Configura Kerberos para un servicio. Después de descargar un archivo keytab en el nodo de la instancia principal del clúster, el archivo debe tener permisos de acceso a archivos restringidos.

El KDC en el clúster controla las solicitudes de autenticación de todos los servicios dentro de ese clúster. Se espera que la mayoría de las solicitudes de autenticación sean de este tipo. A fin de minimizar la latencia, es importante que KDC resuelva esas solicitudes sin que salgan del clúster.

Las solicitudes restantes provienen de usuarios humanos y cuentas de servicio de AD. La réplica de AD en Google Cloud o el proveedor de ID central local controla estas solicitudes, como se explicó en la sección Local anterior.

En esta arquitectura, los clústeres de un solo equipo no están kerberizados, por lo que el KDC no está presente. Para permitir que estos clústeres accedan al almacén de metadatos compartido de Hive, solo debes instalar un cliente de Kerberos. Para automatizar el acceso, puedes usar el archivo keytab del equipo. Para obtener más información, consulta la sección Asignación de identidad más adelante en este documento.

Confianza entre dominios de Kerberos en clústeres de varios equipos

La confianza entre dominios es muy relevante cuando las cargas de trabajo son híbridas o de múltiples nubes. La confianza entre dominios te permite integrar identidades corporativas centrales en servicios compartidos disponibles en tu Google Cloud data lake.

En Kerberos, un dominio define un grupo de sistemas en un KDC común. La autenticación entre dominios permite que un usuario principal de un dominio se autentique en otro dominio y use sus servicios. Esta configuración requiere que establezcas confianza entre dominios.

En la arquitectura, hay tres dominios:

  • EXAMPLE.COM: es el dominio corporativo, en el que se definen todos los principales de usuario de Kerberos para usuarios, equipos y servicios (UPN).
  • MULTI.EXAMPLE.COM: es el dominio que contiene los clústeres de varios equipos. El clúster está preconfigurado con principales de servicio (SPN) para los servicios de Hadoop, como Apache Spark y Apache Hive.
  • METASTORE.EXAMPLE.COM: Es un dominio para el almacén de metadatos de Hive.

Los clústeres de un solo equipo no están kerberizados, por lo que no pertenecen a un dominio.

Para poder usar los principales de usuario corporativo en todos los clústeres, establece las siguientes relaciones de confianza entre dominios unidireccionales:

  • Configura el dominio de varios equipos y el dominio del almacén de metadatos para confiar en el dominio corporativo. Con esta configuración, los principales que se definen en el dominio corporativo pueden acceder a los clústeres de varios equipos y al almacén de metadatos.

    Aunque la confianza puede ser transitiva, recomendamos que configures el dominio del almacén de metadatos para que tenga una confianza directa en el dominio corporativo. Esta configuración evita depender de la disponibilidad del dominio de varios equipos.

  • Configura el dominio del almacén de metadatos a fin de que confíe en el dominio de varios equipos para que los clústeres de varios equipos puedan acceder al almacén de metadatos. Esta configuración es necesaria para permitir el acceso principal de HiveServer2 al almacén de metadatos.

Para obtener más información, consulta Comienza a usar clústeres de Dataproc kerberizados con confianza entre dominios y sus archivos de configuración de Terraform correspondientes en el repositorio de GitHub.

Si prefieres un enfoque de IAM integrado o nativo de la nube para clústeres de varios equipos y, si no necesitas una administración de identidad híbrida, considera usar instancias multiusuario seguras y basadas en cuentas de servicio de Dataproc. En estos clústeres, varias identidades de IAM pueden acceder a Cloud Storage y a otros recursos de Google como diferentes cuentas de servicio.

Asignación de identidad en clústeres de un solo equipo

En las secciones anteriores, se describió la configuración del lado kerberizado de la arquitectura. Sin embargo, los clústeres de un solo equipo no están kerberizados, por lo que requieren una técnica especial para permitirles participar en este ecosistema. Esta técnica usa la propiedad de separación de proyectos de Google Cloud y las cuentas de servicio de IAM para aislar y ayudar a proteger las cargas de trabajo de Hadoop de los equipos de aplicaciones.

Como se describió en la sección anterior Herramientas de redes, cada equipo tiene un proyecto de Google Cloud correspondiente en el que puede crear clústeres de un solo equipo. Dentro de los clústeres de un solo equipo, uno o más miembros del equipo son los usuarios del clúster. Este método de segregación por proyectos también restringe el acceso a los buckets de Cloud Storage (que usan estos clústeres) a los equipos respectivos.

Un administrador crea el proyecto de servicio y aprovisiona la cuenta de servicio del equipo en ese proyecto. Cuando creas un clúster, esta cuenta de servicio se especifica como la cuenta de servicio del clúster.

El administrador también crea una principal de Kerberos para el equipo en el dominio corporativo y crea el archivo keytab correspondiente. El archivo keytab se almacena de forma segura en el Secret Manager y el administrador copia el archivo keytab en el nodo de la instancia principal del clúster. La principal de Kerberos permite el acceso desde el clúster de un solo equipo al almacén de metadatos de Hive.

Para facilitar el aprovisionamiento automatizado y reconocer con facilidad estos pares de identidades relacionadas, las identidades deben seguir una convención de asignación de nombres común, como la siguiente:

  • Cuenta de servicio del equipo: revenue-reporting-app@proj-A.iam.gserviceaccount.com
  • Principal del equipo de Kerberos: revenue_reporting/app@EXAMPLE.COM

Esta técnica de asignación de identidad ofrece un enfoque único para asignar una identidad de Kerberos a una cuenta de servicio, ambas pertenecen al mismo equipo.

Estas identidades se usan de diferentes maneras:

  • La identidad de Kerberos le otorga al clúster acceso a los recursos compartidos de Hadoop, como el almacén de metadatos de Hive.
  • La cuenta de servicio le otorga al clúster acceso a los recursos compartidos deGoogle Cloud , como Cloud Storage.

Con esta técnica, se evita la necesidad de crear una asignación similar para cada miembro del equipo. Sin embargo, debido a que esta técnica utiliza una cuenta de servicio o una principal de Kerberos para todo el equipo, no se puede realizar un seguimiento de las acciones en el clúster de Hadoop a los miembros individuales del equipo.

Para administrar el acceso a los recursos de la nube en el proyecto del equipo que están fuera del alcance de los clústeres de Hadoop (como buckets de Cloud Storage, servicios administrados y VM), un administrador agrega a los miembros del equipo a un Grupo de Google. El administrador puede usar el Grupo de Google para administrar los permisos de IAM de todo el equipo a fin de acceder a los recursos en la nube.

Cuando otorgas permisos de IAM a un grupo y no a miembros individuales del equipo, simplificas la administración del acceso de los usuarios cuando los miembros se unen al equipo de aplicaciones o lo abandonan. Si otorgas permisos directos de IAM al grupo de Google del equipo, puedes inhabilitar el robo de identidad para la cuenta de servicio, lo que ayuda a simplificar la trazabilidad de las acciones en los Registros de auditoría de Cloud. Cuando definas a los miembros de tu equipo, te recomendamos que balancees el nivel de detalle que necesitas para la administración de accesos, el uso de recursos, y la auditoría en función de los esfuerzos administrativos derivados de esas tareas.

Si un clúster entrega estrictamente a un usuario humano (un clúster de un solo usuario), en lugar de a un equipo, considera usar la autenticación de clúster personal de Dataproc. Los clústeres que tienen habilitada la autenticación de clúster personal están diseñados solo para que las cargas de trabajo interactivas a corto plazo se ejecuten de forma segura como una identidad de usuario final. Estos clústeres usan las credenciales de usuario final de IAM para interactuar con otros recursos deGoogle Cloud , como Cloud Storage. El clúster se autentica como el usuario final, en lugar de autenticarse como la cuenta de servicio del clúster. En este tipo de clúster, Kerberos se habilita y configura automáticamente para una comunicación segura dentro del clúster personal.

Flujo de autenticación

Para ejecutar un trabajo en un clúster de Dataproc, los usuarios tienen muchas opciones, como se describió en la sección anterior, Envía trabajos. En todos los casos, la cuenta de usuario o la cuenta de servicio debe tener acceso al clúster.

Cuando un usuario ejecuta un trabajo en un clúster de varios equipos, hay dos opciones para una principal de Kerberos, como se muestra en el siguiente diagrama:

Kerberos y las identidades en la nube se usan con clústeres de varios equipos.

En el diagrama anterior, se muestran las siguientes opciones:

  1. Si el usuario usa una Google Cloud herramienta, como la API de Dataproc, Cloud Composer o la herramienta de línea de comandos de gcloud, para enviar la solicitud de trabajo, el clúster usa elprincipal de Kerberos de Dataproc para autenticarse con el KDC y acceder al almacén de metadatos de Hive.
  2. Si el usuario ejecuta un trabajo desde una sesión SSH, puede enviar trabajos directamente en esa sesión con su propio principal de Kerberos del usuario.

Cuando un usuario ejecuta un trabajo en un clúster de un solo equipo, solo hay una principal de Kerberos posible, la principal de Kerberos del equipo, como se muestra en el siguiente diagrama:

Kerberos y las identidades en la nube se usan con clústeres de un solo equipo.

En el diagrama anterior, un trabajo usa la principal de Kerberos del equipo cuando el trabajo necesita acceso al almacén de metadatos compartido de Hive. De lo contrario, debido a que los clústeres de un solo equipo no están kerberizados, los usuarios pueden iniciar trabajos con su propia cuenta de usuario.

En el caso de los clústeres de un solo equipo, se recomienda ejecutar kinit para la principal del equipo como parte de una acción de inicialización en el momento de la creación del clúster. Después de crear el clúster, usa un programa de cron de acuerdo con la vida útil definida del ticket, con la opción de comando del ciclo de vida del cliente (-l). Para ejecutar kinit, la acción de inicialización primero descarga el archivo keytab en el nodo de la instancia principal del clúster.

Por motivos de seguridad, es fundamental que restrinjas el acceso al archivo keytab. Otorga permisos de lectura de POSIX solo a la cuenta que ejecuta kinit. Si es posible, borra el archivo keytab y renueva el token con kinit -R para extender su ciclo de vida con un trabajo cron hasta que haya alcanzado el máximo de vida útil del ticket. En ese momento, el trabajo cron puede volver a descargar el archivo keytab, volver a ejecutar kinit y reiniciar el ciclo de renovación.

Los tipos de clústeres de varios equipos y de un solo equipo usan cuentas de servicio para acceder a otros recursos Google Cloud , como Cloud Storage. Los clústeres de un solo equipo usan la cuenta de servicio del equipo como la cuenta de servicio del clúster personalizado.

Autorización

En esta sección, se describen los mecanismos de autorización generales y detallados para cada clúster, como se muestra en el siguiente diagrama:

Una arquitectura de autorización usa IAM para una autorización general y Apache Ranger para una autorización detallada.

En la arquitectura del diagrama anterior, se usa IAM para la autorización general y Apache Ranger para la autorización detallada. Estos métodos de autorización se describen en las siguientes secciones: Autorización general y Autorización detallada.

Autorización general

IAM te permite controlar el acceso de usuarios y grupos a los recursos de tu proyecto. IAM define los permisos y las funciones que otorgan esos permisos.

Hay cuatro funciones de Dataproc predefinidas: administrador, editor, visualizador y trabajador. Estos roles otorgan permisos de Dataproc que permiten a los usuarios y a las cuentas de servicio realizar acciones específicas en clústeres, trabajos, operaciones y plantillas de flujo de trabajo. Los roles otorgan acceso a los recursos deGoogle Cloud que necesitan para realizar sus tareas. Uno de estos recursos es Cloud Storage, que recomendamos usar como capa de almacenamiento de clústeres, en lugar de HDFS.

El nivel de detalle de los permisos de IAM de Dataproc no se extiende al nivel de los servicios que se ejecutan en cada clúster, como Apache Hive o Apache Spark. Por ejemplo, puedes autorizar a una cuenta determinada para que acceda a los datos de un bucket de Cloud Storage o ejecute trabajos. Sin embargo, no puedes especificar a qué columnas de Hive pueden acceder esas cuentas con ese trabajo. En la siguiente sección, se describe cómo implementar ese tipo de autorización detallada en los clústeres.

Autorización detallada

Para autorizar el acceso detallado, usa el componente opcional de Ranger de Dataproc en la arquitectura que se describe en Prácticas recomendadas para usar Apache Ranger en Dataproc. En esa arquitectura, se instala Apache Ranger en cada uno de los clústeres, tanto de un solo equipo como de varios equipos. Apache Ranger proporciona un control de acceso detallado para tus aplicaciones de Hadoop (autorización y auditoría) a nivel de servicio, tabla o columna.

Apache Ranger usa identidades proporcionadas por el repositorio de LDAP corporativo y definidas como principales de Kerberos. En los clústeres de varios equipos, el daemon de UserSync de Ranger actualiza de forma periódica las identidades kerberizadas del servidor LDAP corporativo. En los clústeres de un solo equipo, solo se requiere la identidad del equipo.

Los clústeres efímeros presentan un desafío porque se cierran después de que se completan los trabajos, pero no deben perder las políticas de Ranger ni los registros de administración. Para abordar este desafío, externaliza las políticas a una base de datos central de Cloud SQL y externaliza los registros de auditoría a las carpetas de Cloud Storage. Si deseas obtener más información, consulta Prácticas recomendadas para usar Apache Ranger en Dataproc.

Flujo de autorización

Cuando un usuario desea acceder a uno o más de los servicios del clúster para procesar datos, la solicitud pasa por el siguiente flujo:

  1. El usuario se autentica mediante una de las opciones descritas en la sección Flujo de autenticación.
  2. El servicio de destino recibe la solicitud del usuario y llama al complemento Apache Ranger correspondiente.
  3. El complemento recupera las políticas del Servidor de políticas de Ranger de forma periódica. Estas políticas determinan si la identidad del usuario puede realizar la acción solicitada en el servicio específico. Si la identidad del usuario puede realizar la acción, el complemento permite que el servicio procese la solicitud y el usuario obtenga los resultados.
  4. El servidor de auditoría de Ranger escribe cada interacción de usuario con un servicio Hadoop, permitido o denegado. Cada clúster tiene su propia carpeta de registros en Cloud Storage. Dataproc también escribe registros de trabajos y clústeres que puedes ver, buscar, filtrar y archivar en Cloud Logging.

En este documento, las arquitecturas de referencia usaron dos tipos de clústeres de Dataproc: clústeres de varios equipos y clústeres de un solo equipo. Mediante el uso de varios clústeres de Dataproc que se pueden aprovisionar y proteger con facilidad, una organización puede usar un trabajo, un producto o un enfoque centrado en el dominio en lugar de los clústeres tradicionales y centralizados. Este enfoque funciona bien con la arquitectura general de Data Mesh, que permite a los equipos poseer y proteger por completo su data lake y sus cargas de trabajo, y ofrecer datos como servicio.

¿Qué sigue?