Guía de seguridad de migración de Hadoop

Cloud Dataproc y Google Cloud Platform (GCP) contienen varias funciones que pueden ayudar a proteger tus datos. En esta guía se explica cómo funciona la seguridad de Hadoop y cómo se aplica a GCP. Además, se ofrece información sobre cómo diseñar la seguridad cuando se despliega en GCP.

Descripción general

El modelo y el mecanismo de seguridad típicos de un despliegue de Hadoop in situ son diferentes de los proporcionados por la nube. Comprender cómo funciona la seguridad de Hadoop puede ayudarte a diseñar mejor la seguridad cuando realices despliegues en GCP.

Puedes desplegar Hadoop en GCP de dos maneras: como clústeres gestionados por Google (Cloud Dataproc) o como clústeres gestionados por usuarios (Hadoop en Compute Engine). La mayor parte del contenido y de la información técnica de esta guía se aplican a ambos métodos de despliegue. En esta guía, el término Cloud Dataproc/Hadoop hace referencia a conceptos o procedimientos que se aplican a cualquier tipo de despliegue. También se indican los pocos casos en que el despliegue en Cloud Dataproc es diferente del despliegue en Hadoop en Compute Engine.

Seguridad típica de Hadoop in situ

En el siguiente diagrama se muestran una infraestructura típica de Hadoop in situ y su protección. Observa cómo los componentes básicos de Hadoop interactúan entre sí y con los sistemas de gestión de usuarios.

Infraestructura de Hadoop que muestra cuadros separados para el espacio de usuario, el perímetro de seguridad y Hadoop protegido

En general, la seguridad de Hadoop se basa en estos cuatro pilares:

  • La autenticación se proporciona a través de Kerberos integrado con LDAP o Active Directory.
  • La autorización se proporciona a través de HDFS y productos de seguridad como Apache Sentry o Apache Ranger, que permiten que los usuarios cuenten con el acceso necesario a los recursos de Hadoop.
  • El encriptado se proporciona mediante el encriptado de red y de HDFS, que en conjunto protegen los datos tanto en tránsito como en reposo.
  • La auditoría se proporciona a través de productos suministrados por proveedores, como Cloudera Navigator.

Desde la perspectiva de la cuenta de usuario, Hadoop tiene su propia estructura de usuarios y grupos para gestionar identidades y ejecutar daemons. Por ejemplo, los daemons de HDFS y YARN de Hadoop se ejecutan como usuarios hdfs y yarn de Unix, tal y como se explica en esta página sobre Hadoop en modo seguro.

Por lo general, los usuarios de Hadoop se asignan desde usuarios del sistema Linux, o desde usuarios de Active Directory o LDAP. Los usuarios y grupos de Active Directory se sincronizan mediante herramientas como Centrify o el SSSD de RedHat.

Autenticación de Hadoop in situ

Un sistema seguro requiere que los usuarios y servicios se identifiquen en el sistema. El modo seguro de Hadoop utiliza Kerberos para la autenticación y la mayoría de los componentes de Hadoop están diseñados para usar dicha autenticación. Kerberos se implementa normalmente en sistemas de autenticación empresarial como los sistemas compatibles con LDAP o Active Directory.

Principales de Kerberos

Un usuario en Kerberos se denomina principal. En un despliegue de Hadoop, existen principales de usuarios y principales de servicios. Generalmente los principales de usuarios se sincronizan con un centro de distribución de claves (KDC) desde Active Directory u otros sistemas de gestión de usuarios. Un principal de usuario representa a un usuario humano. Un principal de servicio es exclusivo de un servicio por servidor, de modo que cada servicio tiene un solo principal que lo representa en cada servidor.

Archivos de tablas de claves

Un archivo de tabla de claves contiene los principales de Kerberos y sus claves. Los usuarios y servicios pueden usar tablas de claves para autenticarse en los servicios de Hadoop sin utilizar herramientas interactivas ni introducir contraseñas. Hadoop crea principales de servicios para cada servicio en cada nodo, que se almacenan en archivos de tablas de claves en los nodos de Hadoop.

SPNEGO

Si accedes a un clúster protegido con Kerberos a través de un navegador web, el navegador debe saber cómo transferir las claves de Kerberos. Aquí es donde entra en juego el mecanismo de negociación GSS-API simple y protegido (SPNEGO), que ofrece una manera de utilizar Kerberos en aplicaciones web.

Integración

Hadoop se integra con Kerberos no solo para la autenticación de usuarios, sino también para la autenticación de servicios. Los servicios de Hadoop en todos los nodos tendrán su propio principal de Kerberos, que se utiliza para la autenticación. Normalmente los servicios tienen almacenados en el servidor archivos de tabla de claves que contienen una contraseña aleatoria.

Por lo general, para poder interactuar con los servicios, los usuarios humanos necesitan obtener su vale de Kerberos a través del comando kinit o mediante Centrify o el SSSD.

Autorización de Hadoop in situ

Una vez que se ha validado una identidad, el sistema de autorización verifica qué tipo de acceso tienen el usuario o el servicio. En Hadoop, se utilizan algunos proyectos de código abierto, como Apache Sentry y Apache Ranger, para proporcionar la autorización.

Apache Sentry y Apache Ranger

Apache Sentry y Apache Ranger son mecanismos de autorización comunes que se utilizan en los clústeres de Hadoop. Los componentes de Hadoop implementan sus propios complementos en Sentry o Ranger para especificar su comportamiento cuando Sentry o Ranger confirman o rechazan el acceso a una identidad. Sentry y Ranger dependen de sistemas de autenticación como Kerberos, LDAP o AD. El mecanismo de asignación de grupos en Hadoop asegura que Sentry o Ranger vean la misma asignación de grupo 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 están asociados a un propietario y a un grupo. La estructura cuenta con una carpeta raíz propiedad de un superusuario. Los diferentes niveles de la estructura pueden tener distintos encriptados, propiedades, permisos y LCA ampliadas (facl).

Como se muestra en el siguiente diagrama, los permisos suelen concederse a nivel de directorio a grupos específicos según sus necesidades de acceso. Los patrones de acceso se identifican como roles diferentes y se asignan a grupos de Active Directory. Los objetos que pertenecen a un único conjunto de datos generalmente se encuentran en la capa que tiene permisos para un grupo específico, con directorios diferentes para las distintas categorías de datos.

Estructura de carpetas tipo POSIX de HDFS

Por ejemplo, el directorio stg es el área de stage de datos financieros. La carpeta stg tiene permisos de lectura y escritura en el grupo fin-loader. Desde esta área de stage, tiene acceso de solo lectura a este directorio otro grupo de cuentas de aplicaciones (fin-etl), que representa los flujos de procesamiento de ETL. Los flujos de procesamiento de ETL procesan los datos y los guardan en el directorio app que se va a servir. Para habilitar este patrón de acceso, el directorio app tiene acceso de lectura y escritura en el grupo fin-etl, que es la identidad que se utiliza para escribir los datos de ETL, y el acceso de solo lectura en el grupo fin-reader, que consume los datos resultantes.

Encriptado de Hadoop in situ

Hadoop permite encriptar datos en reposo y en tránsito. Para encriptar los datos en reposo, puedes encriptar HDFS con soluciones de encriptado de claves basadas en Java o suministradas por proveedores. HDFS es compatible con las zonas de encriptado para permitir el encriptado de diferentes archivos con distintas claves. Cada zona de encriptado se asocia a una única clave de zona de encriptado que se especifica cuando se crea la zona.

Cada archivo de una zona de encriptado tiene una clave de encriptado de datos (DEK) única. Las DEK nunca se gestionan directamente mediante HDFS. En su lugar, HDFS solamente gestiona una clave de encriptado de datos encriptados (EDEK). Los clientes desencriptan una EDEK y, a continuación, usan la DEK resultante para leer y escribir datos. Los nodos de datos de HDFS simplemente perciben un flujo de bytes encriptados.

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

Auditoría de Hadoop in situ

Una parte importante de la seguridad es la auditoría. La auditoría te ayuda a encontrar actividades sospechosas y proporciona un registro de quién ha tenido acceso a los recursos. Normalmente se utilizan Cloudera Navigator y otras herramientas de terceros para fines de gestión de datos, como el seguimiento de auditorías en Hadoop. Estas herramientas proporcionan visibilidad y control sobre los almacenes de datos de Hadoop y sobre las operaciones informáticas realizadas en esos datos. La auditoría de datos puede capturar un registro completo e inalterable de toda la actividad de un sistema.

Hadoop en GCP

En un entorno tradicional de Hadoop in situ, los cuatro pilares de la seguridad de Hadoop (autenticación, autorización, encriptado y auditoría) se integran y gestionan mediante diferentes componentes. En GCP, se gestionan mediante distintos componentes de GCP externos a Cloud Dataproc y a Hadoop en Compute Engine.

Puedes gestionar los recursos de GCP con la consola de GCP, que es una interfaz web. También está disponible la herramienta de línea de comandos gcloud, que puede ser más rápida y práctica si te encuentras a gusto trabajando en la línea de comandos. Para ejecutar los comandos de gcloud, instala el SDK de Google Cloud en tu ordenador local o usa una instancia de Cloud Shell.

Autenticación de GCP de Hadoop

Existen dos tipos de identidades de Google en GCP: cuentas de servicio y cuentas de usuario. La mayoría de las API de Google necesitan autenticarse con una identidad de Google. Un número limitado de APIs de GCP funcionarán sin autenticación (a través de claves de API), pero recomendamos usar todas las API con autenticación de cuenta de servicio.

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

Autorización de GCP de Hadoop

GCP ofrece varias formas de especificar qué permisos tiene una identidad autenticada en un conjunto de recursos.

Cloud IAM

GCP ofrece Gestión de Identidades y Accesos de Cloud (Cloud IAM), que te permite gestionar el control de acceso mediante la definición de los usuarios (miembros) que tienen qué acceso (rol) a cada recurso.

Con Cloud IAM, puedes conceder acceso a los recursos de GCP y evitar el acceso no deseado a otros recursos. Cloud IAM te permite implementar el principio de seguridad de privilegio mínimo para que solamente concedas el acceso mínimo necesario a tus recursos.

Cuentas de servicio

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

Los clústeres de Cloud Dataproc se crean sobre las VM de Compute Engine. Si asignas una cuenta de servicio personalizada al crear un clúster de Cloud Dataproc, se asignará esa cuenta de servicio a todas las VM del clúster. Esto proporciona al clúster acceso y control pormenorizados a los recursos de GCP. Si no especificas ninguna cuenta de servicio, las VM de Cloud Dataproc usarán la cuenta de servicio de Compute Engine predeterminada gestionada por Google. Esta cuenta tiene de forma predeterminada el rol de editor de proyectos, lo que le otorga un gran conjunto de permisos. Recomendamos no usar la cuenta de servicio predeterminada para crear un clúster de Cloud Dataproc en un entorno de producción.

Permisos de cuenta de servicio

Cuando asignas una cuenta de servicio personalizada a un clúster de Cloud Dataproc/Hadoop, el nivel de acceso de esa cuenta de servicio lo determina la combinación de los permisos de acceso otorgados a las instancias de VM del clúster y los roles de Cloud IAM concedidos a tu cuenta de servicio. Para configurar una instancia con tu cuenta de servicio personalizada, debes configurar los permisos de acceso y los roles de Cloud IAM. Básicamente, estos mecanismos interactúan de la siguiente manera:

  • Los permisos de acceso autorizan el acceso que tiene una instancia.
  • Cloud IAM restringe ese acceso a los roles otorgados a la cuenta de servicio que utiliza la instancia.
  • Los permisos que se encuentran en la intersección de los permisos de acceso y los roles de Cloud IAM son los permisos finales que tiene la instancia.

Cuando creas un clúster de Cloud Dataproc o una instancia de Compute Engine en la consola de GCP, seleccionas el permiso de acceso de la instancia:

Captura de pantalla de opciones para configurar el permiso en la consola de GCP

Un clúster de Cloud Dataproc o una instancia de Compute Engine tienen un conjunto de permisos de acceso definidos para su uso con la configuración de Permitir el acceso predeterminado:

Lista de permisos de acceso definidos

Puedes elegir entre muchos permisos de acceso. Cuando creas una instancia de VM o un clúster, te recomendamos activar la opción Permitir el acceso completo a todas las API de Cloud (en la consola) o el permiso de acceso https://www.googleapis.com/auth/cloud-platform (si usas la herramienta de línea de comandos gcloud). Estos permisos autorizan el acceso a todos los servicios de GCP. Una vez que hayas establecido el permiso, te recomendamos asignar roles de Cloud IAM a la cuenta de servicio del clúster para limitar dicho acceso.

La cuenta no puede realizar ninguna acción fuera de estos roles, a pesar del permiso de acceso de GCP. Si quieres obtener más información, consulta la documentación de permisos de cuenta de servicio.

Comparación de Cloud IAM con Apache Sentry y Apache Ranger

Cloud IAM desempeña un papel similar a Apache Sentry y Apache Ranger. Cloud IAM define el acceso a través de roles. El acceso a otros componentes de GCP se define en estos roles y se asocia a las cuentas de servicio. Esto significa que todas las instancias que usan la misma cuenta de servicio disponen del mismo acceso a otros recursos de GCP. Cualquier usuario que tenga acceso a estas instancias también dispone del mismo acceso a estos recursos de GCP que la cuenta de servicio.

Los clústeres de Cloud Dataproc y las instancias de Compute Engine no cuentan con ningún mecanismo para asignar usuarios y grupos de Google a usuarios y grupos de Linux. Sin embargo, puedes crear usuarios y grupos de Linux. Dentro del clúster de Cloud Dataproc o de las VM de Compute Engine, siguen funcionando los permisos de HDFS y la asignación de usuarios y grupos de Hadoop. Puedes utilizar esta asignación para restringir el acceso a HDFS o para aplicar la asignación de recursos mediante el uso de una cola YARN.

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

Permisos de Cloud Storage

Cloud Dataproc utiliza Cloud Storage para su sistema de almacenamiento. Cloud Dataproc también proporciona un sistema HDFS local, pero no estará disponible si se elimina el clúster de Cloud Dataproc. Si la aplicación no depende estrictamente de HDFS, es mejor usar Cloud Storage para sacar el máximo partido de GCP.

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 mediante las cuentas de usuario y de servicio de Cloud IAM se puede configurar a nivel de segmento. No aplica permisos basados en usuarios de Linux.

Encriptado de GCP de Hadoop

Con algunas excepciones poco significativas, los servicios de GCP encriptan el contenido del cliente en reposo y en tránsito con varios métodos de encriptado. Además, como el encriptado es automático, el cliente no tiene que hacer nada.

Por ejemplo, si se almacenan datos nuevos en discos persistentes, se encriptan según el estándar de encriptado avanzado de 256 bits (AES-256) y cada clave de encriptado se encripta, a su vez, con un conjunto de claves maestras que se rotan de forma regular. GCP aplica las mismas políticas de encriptado y gestión de claves, bibliotecas criptográficas y raíz de confianza que aplican muchos de los servicios de producción de Google, incluidos Gmail y los propios datos corporativos de Google.

Debido a que el encriptado es una función predeterminada de GCP (a diferencia de la mayoría de los despliegues de Hadoop in situ), no debes preocuparte por implementar el encriptado a menos que quieras utilizar tu propia clave de encriptado. GCP también proporciona una solución de claves de encriptado gestionadas por el cliente y una solución de claves de encriptado suministradas por el cliente. Si necesitas gestionar las claves de encriptado por tu cuenta o almacenar las claves de encriptado in situ, puedes hacerlo.

Si quieres obtener más información, consulta los artículos de encriptado en reposo y encriptado en tránsito.

Auditoría de GCP de Hadoop

El registro de auditoría de Cloud puede mantener varios tipos de registros para cada proyecto y organización. Los servicios de GCP escriben entradas de registro de auditoría en dichos registros para ayudarte a responder a las preguntas sobre quién hizo qué, dónde se hizo y cuándo se hizo en tus proyectos de GCP.

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

Proceso de migración

Para ayudar a ejecutar una operación segura y eficiente de Hadoop en GCP, sigue el proceso que se describe en esta sección.

En esta sección, asumimos que ya tienes configurado tu entorno de GCP. Esto incluye la creación de usuarios y grupos en G Suite. Estos usuarios y grupos se gestionan manualmente o se sincronizan con Active Directory, y lo has configurado todo para que GCP autentique usuarios correctamente.

Determinar quién gestionará las identidades

La mayoría de los clientes de Google usan Cloud Identity para gestionar las identidades, aunque algunos administran sus identidades corporativas por separado de las identidades de GCP. En ese caso, sus permisos POSIX y SSH rigen el acceso del usuario final a los recursos de la nube.

Si tienes un sistema de identidades independiente, crea las claves de cuentas de servicio de GCP y descárgalas para empezar. A continuación, puedes vincular tu modelo de seguridad POSIX y SSH in situ con el modelo de GCP si otorgas los permisos de acceso tipo POSIX correspondientes a los archivos de claves de la cuenta de servicio descargados. Puedes permitir o rechazar el acceso de las identidades in situ a estos archivos de claves.

Si sigues esta ruta, tus propios sistemas de gestión de identidades controlan la capacidad de auditoría. Para proporcionar un seguimiento de la auditoría, puedes usar los registros SSH (que contienen los archivos de claves de la cuenta de servicio) de los inicios de sesión de los usuarios en los nodos perimetrales o puedes optar por un mecanismo de almacenamiento de claves más avanzado y explícito para obtener las credenciales de la cuenta de servicio de los usuarios. En ese caso, la "suplantación de identidad de la cuenta de servicio" se registra para auditoría en la capa del almacén de claves.

Elegir entre usar un solo proyecto de datos o varios

Si tu organización tiene muchos datos, esto implica dividirlos en distintos segmentos de Cloud Storage. También debes plantearte cómo distribuir estos segmentos de datos entre tus proyectos. Puede que quieras trasladar una pequeña cantidad de datos al empezar a utilizar GCP, pero con el tiempo tendrás que trasladar cada vez más a medida que se trasladen las cargas de trabajo y las aplicaciones.

Puede parecer práctico dejar todos los segmentos de datos en un solo proyecto, pero no suele ser una buena estrategia. Para gestionar el acceso a los datos, utilizas una estructura de directorios sin formato con roles de gestión de identidades y accesos para los segmentos, lo que puede resultar difícil de manejar a medida que crece el número de segmentos.

Una alternativa es almacenar los datos en varios proyectos dedicados a diferentes organizaciones (por ejemplo, un proyecto para el departamento financiero, otro para el legal, etc.). En este caso, cada grupo gestiona sus propios permisos de forma independiente.

Durante el procesamiento de datos, puede ser necesario acceder a segmentos o crearlos ad hoc. El procesamiento puede dividirse en los límites de confianza, como cuando los científicos de datos acceden a información generada por un proceso que no les pertenece.

El siguiente diagrama muestra una organización típica de datos en Cloud Storage en un solo proyecto de datos y en varios proyectos de datos.

Opciones de almacenamiento típicas en un proyecto y en varios

Estos son los puntos principales que debes tener en cuenta a la hora de decidir cuál es el mejor enfoque para tu organización.

Con un solo proyecto de datos:

  • Resulta fácil gestionar todos los segmentos, siempre que el número de segmentos sea pequeño.
  • La concesión de permisos la realizan principalmente los miembros del grupo de gestión.

Con varios proyectos de datos:

  • Es más fácil delegar las responsabilidades de gestión a los propietarios de los proyectos.
  • Este enfoque es útil para organizaciones que tienen diferentes procesos de concesión de permisos. Por ejemplo, el proceso de concesión de permisos puede ser diferente para los proyectos del departamento de marketing y para los proyectos del departamento legal.

Identificar aplicaciones y crear cuentas de servicio

Cuando los clústeres de Cloud Dataproc/Hadoop interactúan con otros recursos de GCP, como con Cloud Storage, debes identificar todas las aplicaciones que se ejecutarán en Cloud Dataproc/Hadoop y el acceso que necesitarán. Por ejemplo, imagina que hay una tarea de ETL que rellena datos financieros en California en el segmento financial-ca. Dicha tarea necesitará acceso de lectura y escritura al segmento. Después de identificar las aplicaciones que usarán Hadoop, puedes crear cuentas de servicio para cada una de estas aplicaciones.

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

Si quieres obtener más información sobre las cuentas de servicio, consulta el artículo sobre cómo crear y gestionar cuentas de servicio.

Otorgar permisos a cuentas de servicio

Cuando sepas qué acceso debe tener cada aplicación a los distintos segmentos de Cloud Storage, puedes configurar esos permisos en las cuentas de servicio de la aplicación correspondientes. Si tus aplicaciones también necesitan tener acceso a otros componentes de GCP, como BigQuery o Cloud Bigtable, también puedes otorgarlo mediante las cuentas de servicio.

Por ejemplo, puedes especificar operation-ca-etl como aplicación de ETL para generar informes de operaciones mediante la recopilación de datos de marketing y ventas de California, y otorgarle permiso para escribir informes en el segmento de datos del departamento financiero. A continuación, puedes configurar las aplicaciones marketing-report-ca y sales-report-ca para que cada una disponga de 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 de privilegio mínimo. El principio especifica que debes otorgar a cada usuario o cuenta de servicio solamente los permisos mínimos que necesitan para llevar a cabo sus tareas. Los permisos predeterminados en GCP están optimizados para resultar fáciles de usar y reducir el tiempo de configuración. Para crear infraestructuras de Hadoop que puedan superar las revisiones de seguridad y cumplimiento, debes diseñar permisos más restrictivos. Esforzarte al principio y documentar esas estrategias no solo te ayudará a proporcionar un flujo de procesamiento seguro y conforme, sino que también te ayudará a la hora de revisar la arquitectura con los equipos de seguridad y cumplimiento.

Crear clústeres

Una vez que hayas planificado y configurado el acceso, puedes crear clústeres de Cloud Dataproc o Hadoop en Compute Engine con las cuentas de servicio que hayas creado. Cada clúster tendrá acceso a otros componentes de GCP según los permisos que hayas concedido a esa cuenta de servicio. Debes otorgar los permisos de acceso correctos a GCP y alinearlos con el acceso a la cuenta de servicio. Si alguna vez surge un problema de acceso, especialmente con Hadoop en Compute Engine, comprueba estos permisos.

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

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

Se recomienda evitar el uso de la cuenta de servicio predeterminada de Compute Engine por los siguientes motivos:

  • Si varios clústeres y VM de Compute Engine usan la cuenta de servicio predeterminada de Compute Engine, la auditoría es más complicada.
  • La configuración del proyecto para la cuenta de servicio predeterminada de Compute Engine puede variar, lo que significa que puede tener más privilegios de los que necesita tu clúster.
  • Los cambios en la cuenta de servicio predeterminada de Compute Engine pueden afectar involuntariamente a los clústeres y las aplicaciones que se ejecutan en ella o incluso dañarlos.

Configurar permisos de Cloud IAM en cada clúster

Colocar varios clústeres en un solo proyecto puede facilitar la gestión de los clústeres, pero también puede que no sea la mejor manera de proteger el acceso a ellos. Por ejemplo, en los clústeres 1 y 2 del proyecto A, algunos usuarios pueden tener los privilegios adecuados para trabajar en el clúster 1, pero también pueden tener demasiados permisos en el clúster 2. O incluso peor, pueden tener acceso al clúster 2 simplemente porque se encuentra en el mismo proyecto cuando no deberían tenerlo.

Que un proyecto contenga muchos clústeres puede dificultar el acceso a dichos clústeres, tal y como se muestra en la siguiente figura.

Acceso a clústeres individuales en un proyecto

Si, por el contrario, agrupas clústeres similares en proyectos más pequeños y luego configuras Cloud IAM por separado para cada clúster, tendrás más control sobre el acceso. De esta forma, los usuarios podrán acceder a los grupos destinados a ellos y tendrán acceso restringido al resto.

Acceso a clústeres agrupados en proyectos separados

Restringir el acceso a los clústeres

Si configuras el acceso mediante cuentas de servicio, se protegen las interacciones entre Cloud Dataproc/Hadoop y otros componentes de GCP. Sin embargo, no se controla completamente quién puede acceder a Cloud Dataproc/Hadoop. Por ejemplo, un usuario del clúster que tenga la dirección IP de los nodos del clúster de Cloud Dataproc/Hadoop puede seguir utilizando SSH para conectarse (en algunos casos) o enviar tareas a él. En el entorno in situ, el administrador del sistema generalmente cuenta con subredes, reglas de cortafuegos, autenticación de Linux y otras estrategias para restringir el acceso a los clústeres de Hadoop.

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

Restringir el inicio de sesión de SSH con el inicio de sesión del SO

Para impedir que los usuarios se conecten a un nodo de Hadoop en el entorno in situ, debes configurar el control de acceso perimetral, el acceso de SSH a nivel de Linux y los archivos sudoers.

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

  1. Habilita la función de inicio de sesión del SO en tu proyecto o en instancias individuales.
  2. Concédete los roles necesarios de Cloud IAM a ti y a los miembros de tu proyecto u organización.
  3. Opcionalmente, puedes añadir claves SSH personalizadas a las cuentas de usuario para ti y para los miembros de tu proyecto u organización. Si lo prefieres, Compute Engine puede generar automáticamente estas claves cuando te conectas a las instancias.

Después de habilitar el inicio de sesión del SO en una o más instancias del proyecto, esas instancias solo aceptarán conexiones de cuentas de usuario que tengan los roles necesarios de Cloud IAM en tu proyecto u organización.

A modo de ejemplo, puedes otorgar acceso a la instancia a tus usuarios a través del siguiente proceso:

  1. Otorga los roles necesarios de acceso a la instancia al usuario. Los usuarios deben contar con:

    • El rol iam.serviceAccountUser
    • Uno de los siguientes roles de inicio de sesión:

      • El rol compute.osLogin, que no concede permisos de administrador.
      • El rol compute.osAdminLogin, que concede permisos de administrador.
  2. Si eres un administrador de la organización que quiere permitir que las identidades de Google externas a tu organización accedan a las instancias, otórgales el rol compute.osLoginExternalUser en el nivel de tu organización. También debes conceder a esas identidades externas el rol compute.osLogin o compute.osAdminLogin en el nivel de tu proyecto u organización.

Después de configurar los roles necesarios, conéctate a una instancia con las herramientas de Compute Engine. Compute Engine genera automáticamente claves SSH y las asocia con tu cuenta de usuario.

Si quieres obtener más información sobre la función de inicio de sesión de OS, consulta el artículo sobre cómo gestionar el acceso a la instancia con el inicio de sesión de SO.

Restringir el acceso a la red con reglas de cortafuegos

En GCP, también puedes crear reglas de cortafuegos que usen cuentas de servicio para filtrar el tráfico de entrada o salida. Este enfoque puede funcionar particularmente bien si:

  • Te resulta complicado crear reglas basadas en IP porque tienes un amplio conjunto de usuarios o aplicaciones que necesitan acceso a Hadoop.
  • Estás ejecutando clústeres de Hadoop o VM de cliente efímeros, de modo que las direcciones IP cambian con frecuencia.

Si usas reglas de cortafuegos en combinación con las cuentas de servicio, puedes configurar el acceso a un clúster de Cloud Dataproc/Hadoop para permitir solo una cuenta de servicio concreta. De esa manera, solo las VM que se ejecuten como esa cuenta de servicio tendrán acceso al clúster en el nivel especificado.

El siguiente diagrama ilustra el proceso de uso de cuentas de servicio para restringir el acceso. Tanto dataproc-app-1 como dataproc-1, dataproc-2 y app-1-client son cuentas de servicio. Las reglas de cortafuegos permiten que dataproc-app-1 acceda a dataproc-1 y dataproc-2 y que los clientes que usan app-1-client accedan a dataproc-1. En cuanto al almacenamiento, el acceso y los permisos de Cloud Storage están restringidos por los permisos de Cloud Storage para las cuentas de servicio en lugar de las reglas de cortafuegos.

Usar cuentas de servicio y reglas de cortafuegos para restringir el acceso a los recursos

Para esta configuración, se han establecido las siguientes reglas de cortafuegos:

Nombre de la regla Configuración
dp1 Destino: dataproc-1
Origen: [Intervalo de IP]
Cuenta de servicio de origen: dataproc-app-1
Permitir [puertos]
dp2 Destino: dataproc-2
Origen: [Intervalo de IP]
Cuenta de servicio de origen: dataproc-app-2
Permitir [puertos]
dp2-2 Destino: dataproc-2
Origen: [Intervalo de IP]
Cuenta de servicio de origen: dataproc-app-1
Permitir [puertos]
app-1-client Destino: dataproc-1
Origen: [Intervalo de IP]
Cuenta de servicio de origen: app-1-client
Permitir [puertos]

Si quieres obtener más información sobre el uso de reglas de cortafuegos con cuentas de servicio, consulta la sección sobre el filtrado de origen y destino por cuenta de servicio de este artículo.

Detectar puertos de cortafuegos abiertos involuntariamente

Aplicar las reglas de cortafuegos apropiadas es también importante para mostrar las interfaces de usuario web que se ejecutan en el clúster. Asegúrate de que no tienes puertos de cortafuegos abiertos desde Internet que se conecten a estas interfaces. Los puertos abiertos y las reglas de cortafuegos configuradas incorrectamente pueden permitir que usuarios no autorizados ejecuten código arbitrario.

Por ejemplo, Apache Hadoop YARN proporciona APIs 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 tareas y realizar operaciones de Cloud Storage.

Revisa las configuraciones de redes de Dataproc y crea un túnel SSH para establecer una conexión segura con la instancia maestra de tu clúster. Si quieres obtener más información sobre el uso de reglas de cortafuegos con cuentas de servicio, consulta la sección sobre el filtrado de origen y destino por cuenta de servicio en (/vpc/docs/firewalls#serviceaccounts){: track-type="solution" track-name="internalLink" track-metadata-position="body" }..

¿Qué ocurre con los clústeres de varios propietarios?

En general, se recomienda ejecutar clústeres de Cloud Dataproc/Hadoop por separado para las distintas aplicaciones. No obstante, si tienes que usar un clúster de varios propietarios y no quieres incumplir los requisitos de seguridad, puedes crear usuarios y grupos de Linux dentro de los clústeres de Cloud Dataproc/Hadoop para proporcionar autorización y asignación de recursos a través de una cola YARN. Necesitas implementar la autenticación porque no existe una asignación directa entre los usuarios de Google y los usuarios de Linux. Habilitar Kerberos en el clúster puede reforzar el nivel de autenticación dentro del alcance del clúster.

A veces, los usuarios humanos, como un grupo de científicos de datos, usan un clúster de Hadoop para descubrir datos y crear modelos. En una situación así, agrupar usuarios que comparten el mismo acceso a los datos y crear un clúster dedicado de Cloud Dataproc/Hadoop sería una buena opción. De esta manera, puedes añadir usuarios al grupo que tiene permiso para acceder a los datos. También puedes asignar los recursos del clúster en función de sus usuarios de Linux.