Guía de seguridad de migración de Hadoop

Dataproc y Google Cloud incluyen varias características que ayudan a proteger los datos. En esta guía, se explica cómo funciona la seguridad de Hadoop y cómo se traduce a Google Cloud, además de brindarse orientación sobre cómo diseñar la seguridad cuando se implementa en Google Cloud.

Descripción general

El modelo y mecanismo de seguridad típicos para una implementación local de Hadoop son diferentes de los que se proporcionan en la nube. Comprender la seguridad en Hadoop puede ayudarte a diseñar mejor la seguridad cuando implementas en Google Cloud.

Puedes implementar Hadoop en Google Cloud de dos maneras: como clústeres administrados por Google (Dataproc) o como clústeres administrados por el usuario (Hadoop en Compute Engine). La mayor parte del contenido y la orientación técnica que aparecen en esta guía se aplican a ambas formas de implementación. En esta guía, se usa el término Dataproc/Hadoop cuando se hace referencia a conceptos o procedimientos que se aplican a cualquier tipo de implementación. Asimismo, se mencionan algunos casos en que la implementación de Dataproc difiere de la implementación de Hadoop en Compute Engine.

Seguridad típica de Hadoop local

En el siguiente diagrama, se muestra una infraestructura de Hadoop local y cómo se protege. Observa cómo los componentes básicos de Hadoop interactúan entre sí y con los sistemas de administración de usuarios.

Infraestructura de Hadoop con distintos cuadros para el espacio de los usuarios, el perímetro de seguridad y Hadoop asegurado

En líneas generales, la seguridad de Hadoop se basa en estos cuatro pilares:

  • Autenticación: se proporciona a través de Kerberos integrado en LDAP o Active Directory
  • Autorización: se proporciona a través de HDFS y productos de seguridad, como Apache Sentry o Apache Ranger, que garantizan que los usuarios cuenten con el acceso adecuado a los recursos de Hadoop.
  • Encriptación: se proporciona mediante encriptación de red y encriptación de HDFS, que juntas protegen los datos, ya sea que estén en tránsito o en reposo.
  • Auditoría: la proporcionan productos suministrados por proveedores como Cloudera Navigator.

Desde la perspectiva de las cuentas de usuario, Hadoop dispone de su propia estructura de usuarios y grupos, con el fin de administrar identidades y ejecutar daemons. Por ejemplo, los daemons de HDFS y YARN de Hadoop se ejecutan como usuarios Unix hdfs y yarn, como se explica en Hadoop en modo seguro.

Los usuarios de Hadoop se suelen asignar a partir de usuarios de sistemas Linux o de Active Directory/LDAP. Los grupos y usuarios de Active Directory se sincronizan con herramientas como Centrify o el SSSD de Red Hat.

Autenticación de Hadoop local

Un sistema seguro requiere que los usuarios y servicios se identifiquen para reconocerlos. El modo seguro de Hadoop emplea Kerberos para la autenticación. La mayoría de los componentes de Hadoop están diseñados para el uso de Kerberos como medio de autenticación. Kerberos se suele implementar en sistemas de autenticación empresarial, como Active Directory, o sistemas que cumplen con LDAP.

Principales de Kerberos

Los usuarios en Kerberos se denominan principales. En una implementación de Hadoop, hay principales de usuario y principales de servicio. Los principales de usuario se suelen sincronizar desde Active Directory o desde otros sistemas de administración de usuarios con un centro de distribución de claves (KDC). Un principal de usuario representa a un usuario humano. Un principal de servicio corresponde a un servicio único por servidor. Cada servicio en cada servidor tiene un principal único que lo representa.

Archivos Keytab

El archivo keytab contiene los principales de Kerberos y sus claves. Los usuarios y los servicios pueden utilizar keytabs para autenticar los servicios de Hadoop sin emplear herramientas interactivas ni ingresar contraseñas. Hadoop crea un principal de servicio por cada servicio en cada nodo. Estos se almacenan en archivos keytab en nodos Hadoop.

SPNEGO

Si accedes a un clúster kerberizado mediante un navegador web, este debe saber cómo pasar las claves de Kerberos. Aquí entra en juego el mecanismo de negociación GSS-API simple y protegido (SPNEGO), que brinda una forma de usar Kerberos en aplicaciones web.

Integración

Hadoop se integra en Kerberos, no solo para la autenticación de usuarios, sino también para la autenticación de servicios. Cualquier servicio Hadoop de un nodo tiene su propio principal de Kerberos y lo utiliza para la autenticación. Los servicios suelen tener archivos de tabla de claves almacenados en el servidor, que contienen una contraseña aleatoria.

Para poder interactuar con los servicios, los usuarios humanos suelen necesitar obtener su ticket de Kerberos a través del comando kinit, mediante Centrify o con SSSD.

Autorización de Hadoop local

Una vez validada una identidad, el sistema de autorización verifica el tipo de acceso que tiene ese usuario o servicio. En Hadoop, se utilizan algunos proyectos de código abierto, como Apache Sentry y Apache Ranger, para brindar autorización.

Apache Sentry y Apache Ranger

Apache Sentry y Apache Ranger son mecanismos de autorización comunes que se utilizan en clústeres Hadoop. Los componentes de Hadoop implementan sus propios complementos en Sentry o Ranger para especificar cuál debe ser el comportamiento cuando Sentry o Ranger confirman o rechazan el acceso a una identidad. Sentry y Ranger emplean sistemas de autenticación como Kerberos, LDAP o AD. El mecanismo de asignación de grupos en Hadoop se asegura de que Sentry o Ranger vean la misma asignación de grupos que los demás componentes del ecosistema de Hadoop.

Permisos de HDFS y LCA

HDFS utiliza un sistema de permisos tipo POSIX con una Lista de control de acceso (LCA) para determinar si los usuarios tienen acceso a los archivos. Cada archivo y directorio se asocia a un propietario y un grupo. La estructura tiene una carpeta raíz que pertenece a un superusuario. Los distintos niveles de la estructura pueden contar con diferentes tipos de encriptación, así como otras propiedades y permisos, y una LCA extendida (facl).

Como se muestra en el siguiente diagrama, los permisos se suelen conceder en el nivel del directorio a grupos específicos sobre la base de sus necesidades de acceso. Los patrones de acceso se identifican como distintas funciones y se asignan a grupos de Active Directory. Los objetos que pertenecen a un único conjunto de datos suelen residir en una capa que tiene permisos para un grupo específico, con distintos directorios para diferentes categorías de datos.

Estructura de carpetas tipo POSIX de HDFS

Por ejemplo, el directorio stg es el área de etapa de pruebas para los datos financieros. La carpeta stg tiene permisos de lectura y escritura para el grupo fin-loader. Desde esta área de etapa de pruebas, fin-etl, otro grupo de cuentas de aplicación que representa las canalizaciones ETL, tiene acceso de solo lectura a este directorio. Las canalizaciones ETL procesan los datos y los guardan en el directorio app para su entrega. Con el fin de habilitar este patrón de acceso, el directorio app tiene acceso de lectura/escritura para el grupo fin-etl, que es la identidad que se usa a fin de escribir los datos ETL, y acceso de solo lectura al grupo fin-reader, que consume los datos resultantes.

Encriptación de Hadoop local

Hadoop proporciona maneras de encriptar los datos en reposo y en tránsito. En el caso de los datos en reposo, puedes encriptar HDFS mediante la encriptación de claves basada en Java o soluciones de encriptación suministradas por el proveedor. HDFS admite zonas de encriptación, con el fin de permitir la encriptación de diferentes archivos mediante distintas claves. Cada zona de encriptación se encuentra asociada con una única clave, que se especifica en el momento de crear la zona.

Cada archivo dentro de una zona de encriptación tiene una clave de encriptación de datos (DEK) única. HDFS nunca administra directamente las DEK. En cambio, solo administra una clave de encriptación de datos encriptados (EDEK). Los clientes desencriptan una EDEK y, luego, usan la DEK subyacente para leer y escribir datos. Los nodos de datos HDFS solo ven un flujo de bytes encriptados.

El tránsito de datos entre nodos Hadoop se puede encriptar mediante la seguridad de la capa de transporte (TLS). La TLS proporciona encriptación y autenticación a la comunicación entre dos componentes cualesquiera de Hadoop. Por lo general, Hadoop utiliza certificados de CA firmados para la TLS entre los componentes.

Auditoría de Hadoop local

Una parte importante de la seguridad es la auditoría. La auditoría ayuda a detectar actividad sospechosa y proporciona un registro de quién tuvo acceso a los recursos. Cloudera Navigator y otras herramientas de terceros se suelen utilizar para fines de administración de datos, como el seguimiento de auditorías en Hadoop. Estas herramientas proporcionan visibilidad y control sobre los datos en los almacenes de datos de Hadoop y los cálculos realizados con los datos. La auditoría de datos puede capturar un registro inmutable y completo de toda la actividad dentro de un sistema.

Hadoop en Google Cloud

En un entorno de Hadoop local tradicional, la integración y administración de los cuatro pilares de la seguridad de Hadoop (autenticación, autorización, encriptación y auditoría) dependen de diferentes componentes. En Google Cloud, dependen de diferentes componentes de Google Cloud externos a Dataproc y Hadoop en Compute Engine.

Puedes administrar los recursos de Google Cloud mediante Google Cloud Console , que es una interfaz basada en la Web. También puedes usar la herramienta de línea de comandos de gcloud, que es posible que sea más rápida y conveniente si te sientes cómodo trabajando con la línea de comandos. Si quieres ejecutar comandos de gcloud, instala el SDK de Cloud en tu computadora local o usa una instancia de Cloud Shell.

Autenticación en GCP con Hadoop

Hay dos tipos de identidades de Google dentro de Google Cloud: cuentas de servicio y cuentas de usuario. La mayoría de las API de Google requiere autenticación con una identidad de Google. Un número limitado de API de Google Cloud funcionará sin autenticación (con las claves de API ), pero recomendamos usar todas las API con autenticación de cuenta de servicio.

Las cuentas de servicio usan claves privadas para establecer la identidad. Las cuentas de usuario utilizan el protocolo OAUTH 2.0 a fin de autenticar a los usuarios finales. Para obtener más información, consulta Descripción general de la autenticación.

Autorización en GCP con Hadoop

Google Cloud proporciona varias formas de especificar qué permisos tiene una identidad autenticada para un conjunto de recursos.

IAM

Google Cloud ofrece administración de identidades y accesos (IAM), que te permite administrar el control de acceso al definir qué usuarios (miembros) tienen qué acceso (función) para cada recurso.

Con IAM, puedes otorgar acceso a los recursos de Google Cloud y evitar el acceso no deseado a otros recursos. IAM te permite implementar el principio de seguridad del menor privilegio. Es decir, se brinda solo el mínimo nivel de acceso necesario a los recursos.

Cuentas de servicio

Una cuenta de servicio es un tipo especial de Cuenta de Google que pertenece a tu aplicación o a una máquina virtual (VM) en lugar de a un usuario final individual. Las aplicaciones pueden usar credenciales de cuentas de servicio para autenticarse con otras API de Cloud. Asimismo, puedes crear reglas de firewall que permitan o prohíban el tráfico desde y hacia determinadas instancias según la cuenta de servicio asignada a cada una.

Los clústeres de Dataproc se compilan en instancias de VM de Compute Engine. Cuando crees un clúster de Dataproc y asignes una cuenta de servicio personalizada, esta se asignará a todas las VM de tu clúster. Esto brinda al clúster un control y un acceso detallados a los recursos de Google Cloud. Si no especificas una cuenta de servicio, las VM de Dataproc usan la cuenta de servicio de Compute Engine predeterminada administrada por Google. Esta cuenta tiene la función de editor del proyecto amplia de forma predeterminada, por lo que cuenta con una gran variedad de permisos. Recomendamos no usar la cuenta de servicio predeterminada para crear un clúster de Dataproc en un entorno de producción.

Permisos de cuenta de servicio

Cuando asignas una cuenta de servicio personalizada a un clúster de Dataproc/Hadoop, el nivel de acceso de esa cuenta de servicio se determina mediante la combinación de alcances de acceso otorgados a las instancias de VM del clúster y las funciones de IAM otorgadas a tu cuenta de servicio. Para configurar una instancia con tu cuenta de servicio personalizada, debes configurar los niveles de acceso y las funciones de IAM. En esencia, estos mecanismos interactúan de la siguiente manera:

  • Los alcances de acceso determinan a qué puede acceder una instancia.
  • IAM restringe ese acceso a las funciones otorgadas a la cuenta de servicio que usa la instancia.
  • Los permisos que se encuentran en la intersección entre los niveles de acceso y las funciones de IAM son los permisos finales que tiene la instancia.

Cuando crees un clúster de Dataproc o una instancia de Compute Engine en Google Cloud Console, selecciona el nivel de acceso de la instancia:

Captura de pantalla con opciones para configurar el permiso en GCP Console

Un clúster de Dataproc o una instancia de Compute Engine tiene un conjunto de niveles de acceso definidos para usar con la configuración Allow default access (Permitir el acceso predeterminado):

Lista de niveles de acceso definidos

Puedes elegir entre numerosos niveles de acceso. Recomendamos que cuando crees una instancia de VM o clúster nuevo, establezcas Permitir acceso total a todas las API de Cloud (en Console) o el nivel de acceso https://www.googleapis.com/auth/cloud-platform (si usas la herramienta de línea de comandos de gcloud). Estos alcances autorizan el acceso a todos los servicios de Google Cloud. Una vez que hayas configurado el alcance, recomendamos que limites ese acceso mediante la asignación de funciones de IAM a la cuenta de servicio del clúster.

La cuenta no puede realizar ninguna acción fuera de estas funciones, a pesar del nivel de acceso de Google Cloud. Para obtener más información, consulta la documentación de permisos de cuenta de servicio.

Compara IAM con Apache Sentry y Apache Ranger

IAM cumple una función similar a Apache Sentry y Apache Ranger. IAM define el acceso a través de funciones. El acceso a otros componentes de Google Cloud se define en estas funciones y se asocia con las cuentas de servicio. Esto significa que todas las instancias que usan la misma cuenta de servicio tienen el mismo acceso a otros recursos de Google Cloud. Cualquiera que tenga acceso a estas instancias también tiene el mismo acceso a estos recursos de Google Cloud que la cuenta de servicio.

Los clústeres de Dataproc y las instancias de Compute Engine no tienen un mecanismo para asignar usuarios y grupos de Google a usuarios y grupos de Linux. Sin embargo, puedes crear grupos y usuarios de Linux. Dentro del clúster de Dataproc o dentro de las VM de Compute Engine, los permisos de HDFS y la asignación de usuarios y grupos de Hadoop seguirán funcionando. Esta correlación se puede usar para restringir el acceso a HDFS o hacer cumplir la asignación de recursos mediante una cola de YARN.

Cuando las aplicaciones en un clúster de Dataproc o una VM de Compute Engine necesitan acceder a recursos externos como Cloud Storage o BigQuery, esas aplicaciones se autentican como la identidad de la cuenta de servicio que asignaste a las VM en el clúster. Luego, usas IAM para otorgar a la cuenta de servicio personalizada de tu clúster el nivel mínimo de acceso que necesita tu aplicación.

Permisos de Cloud Storage

Dataproc usa Cloud Storage para su sistema de almacenamiento. Dataproc también proporciona un sistema HDFS local, pero este no estará disponible si se borra el clúster de Dataproc. Si la aplicación no depende de forma rigurosa de HDFS, es mejor usar Cloud Storage para aprovechar al máximo Google Cloud.

Cloud Storage no tiene jerarquías de almacenamiento. La estructura de directorios simula la estructura de un sistema de archivos. Tampoco tiene permisos tipo POSIX. El control de acceso de las cuentas de usuario y de servicio de IAM se puede configurar a nivel de depósito. No ejecuta permisos sobre la base de usuarios de Linux.

Encriptación de Hadoop en GCP

Con algunas excepciones, los servicios de Google Cloud encriptan el contenido de los clientes en reposo y en tránsito mediante diversos métodos de encriptación. La encriptación es automática y no requiere ninguna acción por parte de los clientes.

Por ejemplo, cuando se almacenan datos nuevos en los discos persistentes, se los encripta conforme al Estándar de encriptación avanzada de 256 bits (AES-256) y cada clave de encriptación se encripta, a su vez, con un conjunto de claves maestras que se rotan con regularidad. Google Cloud usa las mismas políticas de administración de claves y encriptación, bibliotecas criptográficas y raíz de confianza que se usan para muchos de los servicios de producción de Google, incluidos Gmail y los propios datos corporativos de Google.

Debido a que la encriptación es una característica predeterminada de Google Cloud (a diferencia de la mayoría de las implementaciones locales de Hadoop), no necesitas preocuparte por implementar la encriptación, a menos que quieras usar tu propia clave de encriptación. Google Cloud también proporciona una solución de claves de encriptación administrada por el cliente y una solución de claves de encriptación proporcionada por el cliente. Si necesitas administrar claves de encriptación tú mismo o almacenarlas de forma local, puedes hacerlo.

Para obtener más detalles, consulta encriptación en reposo y encriptación en tránsito.

Auditoría de Hadoop en GCP

Cloud Audit Logs puede mantener algunos tipos de registros para cada proyecto y organización. Los servicios de Google Cloud escriben entradas de registro de auditoría en estos para ayudarte a responder las preguntas “¿Quién hizo qué, dónde y cuándo?” dentro de tus proyectos de Google Cloud.

Para obtener más información sobre los registros de auditoría y los servicios que escriben registros de auditoría, consulta la documentación de Registros de auditoría de Cloud.

Proceso de migración

Para facilitar la ejecución de una operación segura y eficiente de Hadoop en Google Cloud, sigue el proceso establecido en esta sección.

En esta sección, se da por sentado que configuraste tu entorno de Google Cloud. Esto incluye la creación de grupos y usuarios en G Suite. Estos usuarios y grupos se administran de forma manual o se sincronizan con Active Directory. También se da por hecho que configuraste todo para que Google Cloud sea funcional por completo en términos de autenticación de usuarios.

Determina quién administrará las identidades

La mayoría de los clientes de Google usan Cloud Identity para administrar identidades. Sin embargo, algunos administran sus identidades corporativas de manera independiente de las identidades de Google Cloud. En ese caso, sus permisos de POSIX y SSH determinan los accesos de los usuarios finales a los recursos en la nube.

Si tienes un sistema de identidad independiente, primero debes crear claves de cuenta de servicio de Google Cloud y descargarlas. Luego, puedes vincular tu modelo de seguridad SSH y POSIX local con el modelo de Google Cloud si otorgas permisos de acceso al estilo POSIX apropiados a los archivos de claves de la cuenta de servicio descargados. Puedes permitir o denegar el acceso de tus identidades locales a estos archivos de claves.

Si usas este método, la capacidad de auditar dependerá de tus propios sistemas de administración de identidades. A fin de proporcionar un rastro de auditoría, puedes usar los registros SSH (que contienen los archivos de claves de la cuenta de servicio) de los accesos de los usuarios en nodos perimetrales, o puedes optar por un mecanismo de almacenamiento de claves más explícito y robusto para obtener las credenciales de las cuentas de servicio de los usuarios. En ese caso, el registro de auditoría del "robo de identidad de cuentas de servicio" se realiza en la capa del almacenamiento de claves.

Determina si utilizarás uno o varios proyectos de datos

Si tu organización cuenta con una gran cantidad de datos, esto implica dividirlos en diferentes depósitos de Cloud Storage. También tienes que pensar en cómo distribuir estos depósitos de datos entre tus proyectos. Es posible que quieras mover una pequeña cantidad de datos cuando te inicias en Google Cloud y mover más datos a medida que se mueven las cargas de trabajo y las aplicaciones.

Puede parecer conveniente dejar todos los depósitos de datos bajo un proyecto, pero hacerlo no suele ser un enfoque adecuado. Para administrar el acceso a los datos, se utiliza una estructura de directorios plana con funciones de IAM para los depósitos. Esto puede volverse más difícil de manejar a medida que aumenta la cantidad de depósitos.

Una alternativa es almacenar los datos en varios proyectos dedicados a diferentes organizaciones: un proyecto para el departamento de finanzas, otro para el equipo legal, etcétera. En este caso, cada grupo administra sus propios permisos de manera independiente.

Durante el procesamiento de datos, podría ser necesario crear depósitos ad hoc o acceder a ellos. El procesamiento puede dividirse de forma transversal a los límites de confianza, de modo que los científicos de datos puedan acceder a datos que se producen con un proceso que no les pertenece.

En el siguiente diagrama, se muestra una organización típica de los datos en Cloud Storage bajo un único proyecto de datos y bajo varios proyectos de datos.

Opciones de almacenamiento típicas: en un solo proyecto y en varios proyectos

A continuación, se indican los puntos principales que debes considerar a la hora de decidir qué enfoque es mejor para tu organización.

Con un único proyecto de datos:

  • Es fácil administrar todos los depósitos, siempre que la cantidad de depósitos sea baja.
  • El otorgamiento de permisos suele estar a cargo, principalmente, de los miembros del grupo administrador.

Con varios proyectos de datos:

  • Es más fácil delegar responsabilidades de administración a los propietarios del proyecto.
  • Este enfoque es útil para las organizaciones que tienen procesos diferentes de otorgamiento de permisos. Por ejemplo, esos procesos podrían ser diferentes en los proyectos del departamento de marketing que en los proyectos del departamento legal.

Identifica aplicaciones y crea cuentas de servicio

Cuando los clústeres de Dataproc/Hadoop interactúan con otros recursos de Google Cloud, como Cloud Storage, debes identificar todas las aplicaciones que se ejecutarán en Dataproc/Hadoop y el acceso que necesitarán. Por ejemplo, supón que hay un trabajo de ETL que propaga los datos financieros de California al depósito financial-ca. Este trabajo de ETL requerirá acceso de lectura y escritura al depósito. Una vez que hayas identificado las aplicaciones que usarán Hadoop, puedes crear cuentas de servicio para cada una de ellas.

Recuerda que este acceso no afecta a los usuarios de Linux dentro del clúster de Cloud Dataproc o en Hadoop en Compute Engine.

Para obtener más información sobre las cuentas de servicio, consulta la página sobre cómo crear y administrar cuentas de servicio.

Otorga permisos a las cuentas de servicio

Una vez que sepas qué acceso debería tener cada aplicación a los distintos depósitos de Cloud Storage, puedes establecer esos permisos en las cuentas de servicio de la aplicación correspondiente. Si tus aplicaciones también necesitan acceder a otros componentes de Google Cloud, como BigQuery o Cloud Bigtable, puedes otorgarles permiso a ellos mediante cuentas de servicio.

Por ejemplo, podrías especificar operation-ca-etl como una aplicación de ETL para que genere informes de operaciones con datos de marketing y ventas de California, y otorgarle permiso para que escriba los informes en el depósito de datos del departamento financiero. Luego, podrías configurar las aplicaciones marketing-report-ca y sales-report-ca para que cada una tenga acceso de lectura y escritura a sus propios departamentos. En el siguiente diagrama, se ilustra esta configuración.

Configuración de permisos para cuentas de servicio

Debes seguir el principio del mínimo privilegio. Este principio implica otorgar a cada cuenta de servicio o de usuario solo los permisos mínimos que necesita para realizar sus tareas. Los permisos predeterminados en Google Cloud están optimizados para facilitar el uso y reducir el tiempo de preparación. Para crear infraestructuras de Hadoop con mayores posibilidades de pasar las revisiones de seguridad y cumplimiento, deberás diseñar permisos más restrictivos. Si dedicas tu atención a esto desde un principio y documentas tus estrategias, no solo tendrás una canalización segura que cumpla con las normas pertinentes, sino que también será más fácil realizar revisiones de la arquitectura con los equipos de seguridad y cumplimiento.

Crea clústeres

Después de haber planificado y configurado el acceso, puedes crear clústeres de Dataproc o Hadoop en Compute Engine con las cuentas de servicio que creaste. Cada clúster tendrá acceso a otros componentes de Google Cloud según los permisos que hayas otorgado a esa cuenta de servicio. Asegúrate de otorgar el alcance o los niveles de acceso correctos para acceder a Google Cloud y, luego, realizar los ajustes necesarios con el acceso a la cuenta de servicio. Si alguna vez surge un problema de acceso, en particular con Hadoop en Compute Engine, recuerda revisar estos permisos.

Para crear un clúster de Dataproc con una cuenta de servicio específica, usa este comando gcloud:

gcloud dataproc clusters create [CLUSTER_NAME] \
    --service-account=[SERVICE_ACCOUNT_NAME]@[PROJECT+_ID].iam.gserviceaccount.comn \
    --scopes=scope[, ...]

Por los siguientes motivos, se recomienda evitar el uso de la cuenta de servicio de Compute Engine predeterminada:

  • Si varios clústeres y VM de Compute Engine utilizan la cuenta de servicio de Compute Engine predeterminada, se dificulta la auditoría.
  • La configuración del proyecto para la cuenta de servicio de Compute Engine predeterminada puede variar, lo que significa que podría tener más privilegios que las necesarios para el clúster.
  • Los cambios en la cuenta de servicio de Compute Engine predeterminada podrían afectar o incluso romper, de manera accidental, los clústeres y las aplicaciones que se ejecutan en ellos.

Considera configurar los permisos de IAM para cada clúster

Colocar varios clústeres en un mismo proyecto puede simplificar su administración, pero quizá no sea la mejor manera de proteger el acceso a ellos. Por ejemplo, supongamos que tenemos los clústeres 1 y 2 en el proyecto A; algunos usuarios podrían tener los privilegios correctos para trabajar en el clúster 1, pero podrían tener demasiados permisos para el clúster 2. O, lo que sería peor, podrían tener acceso al clúster 2 solo porque se encuentra en el proyecto, a pesar de que no deberían poder acceder a él.

Cuando los proyectos contienen muchos clústeres, el acceso a estos se puede complicar, como se muestra en la siguiente figura.

Accede a clústeres individuales en un proyecto

Si, en cambio, agrupas los clústeres como si fueran proyectos más pequeños y, luego, configuras IAM por separado para cada clúster, tendrás un mayor grado de control sobre el acceso. De esta forma, los usuarios tienen acceso a los clústeres que les corresponden, pero no pueden acceder a los demás.

Accede a clústeres agrupados en proyectos separados

Restringe el acceso a clústeres

Cuando se configura el acceso mediante cuentas de servicio, se protegen las interacciones entre Dataproc/Hadoop y otros componentes de Google Cloud. Sin embargo, no es posible controlar en su totalidad quién puede acceder a Dataproc/Hadoop. Por ejemplo, un usuario en el clúster que tiene la dirección IP de los nodos del clúster de Dataproc/Hadoop aún puede usar SSH para conectarse a él (en algunos casos) o enviarle trabajos. En los entornos locales, el administrador del sistema suele tener subredes, reglas de firewall, autenticación de Linux y otras estrategias destinadas a restringir el acceso a los clústeres de Hadoop.

Hay muchas maneras de restringir el acceso al nivel de la autenticación de G Suite o Google Cloud cuando ejecutas Dataproc/Hadoop en Compute Engine. Sin embargo, esta guía se centra en el acceso al nivel de los componentes de Google Cloud.

Restringe el acceso a SSH con el acceso al SO

En el entorno local, para impedir que los usuarios se conecten a un nodo de Hadoop, es necesario configurar un control de acceso del perímetro, un acceso SSH al nivel de Linux y archivos sudoer.

En Google Cloud, puedes configurar las restricciones de SSH a nivel del usuario para conectarte a las instancias de Compute Engine mediante el siguiente proceso:

  1. Habilita las características de acceso al SO en tu proyecto o en instancias individuales.
  2. Otorga las funciones de IAM necesarias a los miembros de tu proyecto, a los miembros de tu organización o a ti mismo.
  3. Otra opción es agregar Llaves SSH personalizadas a las cuentas de usuarios a los miembros de tu proyecto, a los miembros de tu organización o a ti mismo. Por otro lado, Compute Engine puede generar estas claves de manera automática cuando te conectas a instancias.

Después de habilitar el Acceso al SO en una o más instancias del proyecto, esas instancias aceptarán conexiones solo de cuentas de usuario que tengan las funciones de IAM necesarias en la organización o el proyecto:

Por ejemplo, podrías otorgar acceso a instancias a tus usuarios mediante el siguiente proceso:

  1. Otorga al usuario las funciones de acceso a instancias necesarias. Los usuarios deben tener las siguientes funciones:

    • La función iam.serviceAccountUser
    • Una de las siguientes funciones de acceso:

      • La función compute.osLogin, que no otorga permisos de administrador
      • La función compute.osAdminLogin, que otorga permisos de administrador
  2. Si eres administrador de la organización y deseas permitir que las identidades de Google externas a la organización accedan a tus instancias, otorga a esas identidades externas la función compute.osLoginExternalUser a nivel de la organización. Luego, debes otorgar a esas entidades externas la función compute.osLogin o compute.osAdminLogin a nivel del proyecto o de la organización.

Después de configurar las funciones necesarias, conéctate a una instancia con herramientas de Compute Engine. Compute Engine genera de manera automática Llaves SSH y las asocia a tu cuenta de usuario.

Para obtener más información sobre la característica de acceso al SO, consulta la página sobre cómo administrar el acceso a instancias con acceso al SO.

Restringe el acceso a la red mediante reglas de firewall

En Google Cloud, también puedes crear reglas de firewall que usan cuentas de servicio para filtrar el tráfico de entrada o salida. Este enfoque puede ser útil, sobre todo, en las siguientes circunstancias:

  • Si tienes una gran variedad de usuarios o aplicaciones que necesitan acceso a Hadoop, lo cual dificulta crear reglas basadas en la IP.
  • Si ejecutas VM de cliente o clústeres de Hadoop efímeros, por lo que las direcciones IP cambian con frecuencia.

Cuando usas las reglas del firewall en combinación con las cuentas de servicio, puedes configurar el acceso a un clúster de Dataproc/Hadoop en particular para permitir solo una cuenta de servicio determinada. De esta manera, solo las VM que se ejecuten con esa cuenta de servicio tendrán acceso al clúster en el nivel especificado.

En el siguiente diagrama, se ilustra el proceso en el que se usan cuentas de servicio para restringir el acceso. dataproc-app-1, dataproc-1, dataproc-2 y app-1-client son todas las cuentas de servicio. Las reglas de firewall permiten que dataproc-app-1 acceda a dataproc-1 y dataproc-2, además de permitir a los clientes que usan app-1-client acceder a dataproc-1. Con respecto al almacenamiento, los accesos y permisos de Cloud Storage están restringidos según los permisos para Cloud Storage de las cuentas de servicio y no se basan en reglas de firewall.

Usa cuentas de servicio y reglas de firewall para restringir el acceso a los recursos

Para esta configuración, se establecieron las siguientes reglas de firewall:

Nombre de la regla Configuración
dp1 Destino: dataproc-1
Fuente: [Rango de IP]
Fuente de SA: dataproc-app-1
Permitir [puertos]
dp2 Destino: dataproc-2
Fuente: [Rango de IP]
Fuente de SA: dataproc-app-2
Permitir [puertos]
dp2-2 Destino: dataproc-2
Fuente: [Rango de IP]
Fuente de SA: dataproc-app-1
Permitir [puertos]
app-1-client Destino: dataproc-1
Fuente: [Rango de IP]
Fuente de SA: app-1-client
Permitir [puertos]

Para obtener más información sobre el uso de reglas de firewall con cuentas de servicio, consulta la sección sobre cómo filtrar fuente y objetivo por cuenta de servicio.

Verifica puertos de firewall abiertos por descuido

Contar con reglas de firewall adecuadas también es importante para exponer interfaces de usuario basadas en la Web que se ejecutan en el clúster. Asegúrate de no tener puertos de firewall abiertos de Internet que se conecten a estas interfaces. Los puertos abiertos y las reglas de firewall configuradas de manera inadecuada pueden brindarle a un usuario no autorizado la oportunidad de ejecutar código arbitrario.

Por ejemplo, Apache Hadoop YARN proporciona las API de REST que comparten los mismos puertos que las interfaces web de YARN. De forma predeterminada, los usuarios que pueden acceder a la interfaz web de YARN pueden crear aplicaciones, enviar trabajos y, en algunos casos, realizar operaciones de Cloud Storage.

Revisa las configuraciones de red de Dataproc y cómo crear un túnel de SSH para establecer una conexión segura con la instancia principal de tu clúster. Para obtener más información sobre el uso de reglas de firewall con cuentas de servicio, consulta la sección sobre cómo filtrar fuente y objetivo por cuenta de servicio.

¿Qué sucede con los clústeres multiusuario?

Por lo general, ejecutar clústeres independientes de Dataproc/Hadoop para diferentes aplicaciones es una práctica recomendada. Sin embargo, si tienes que usar un clúster de múltiples instancias y no quieres infringir los requisitos de seguridad, puedes crear usuarios y grupos de Linux dentro de los clústeres de Dataproc/Hadoop para proporcionar autorización y asignación de recursos a través de una cola de YARN. Tú debes implementar la autenticación, ya que no hay una correlación directa entre los usuarios de Google y los de Linux. La habilitación de Kerberos en el clúster puede reforzar el nivel de autenticación dentro del alcance del clúster.

A veces, los usuarios humanos, como grupos de científicos de datos, usan el clúster de Hadoop para descubrir datos y crear modelos. En casos como este, puede ser muy conveniente agrupar a los usuarios que comparten el mismo acceso a los datos y crear un clúster de Dataproc/Hadoop dedicado. De esta manera, puedes agregar usuarios al grupo que cuenta con permiso para acceder a los datos. Los recursos del clúster también se pueden asignar según los usuarios de Linux.