Por una vez, en lugar de tratar temas como la nube, DevOps, impresiones sobre conferencias o ciberseguridad, como suelo hacer, hoy voy a centrarme en los datos. No, no voy a hablar del concepto de los lagos de datos, sino más bien de la parte relacionada con el software y las herramientas.
En las instalaciones de un cliente, tuve la oportunidad de descubrir una tecnología relacionada con el ámbito de los datos: Apache NIFI. Resulta que se trata de una herramienta de gestión de flujos de datos que permite la ingesta, el procesamiento y la transferencia entre varios sistemas mediante una interfaz gráfica muy sencilla.
Hay que saber que este proyecto no fue iniciado por la Fundación Apache (creadora de Zookeeper, del que hablé hace varios años, o de Kafka), sino por la NSA en 2006, que finalmente liberó el proyecto en 2014 en el marco de su programa de transferencia de tecnología para cederlo a la Fundación Apache.
El principio de NIFI
Apache NIFI es una solución de automatización de la gestión de datos; en pocas palabras: un pasarela.
Según los procesadores que definas en la interfaz, recuperará los datos (un archivo, una solicitud API, el contenido de un bucket S3, CSV, JSON, etc.) y los enviará a su destino final (RabbitMQ, Kafka, JMS, PubSub, AMQP, etc.).
El número de procesadores es bastante elevado y permite abordar muchos casos de uso diferentes, con el fin de almacenar y procesar datos localmente o en las plataformas en la nube más conocidas.
Por cierto, hay plantillas disponibles por todo Internet, especialmente en una página de Confluence de la Fundación Apache o en la página de la comunidad de Cloudera.
Entre las siguientes, hay muchas aplicaciones o flujos posibles:
Conversión de una entrada CSV en un documento JSON:
Importación de registros de sistema a través de syslogs para su almacenamiento en HBase:
Llamada a un servicio web HTTP:
Los ejemplos anteriores no son exhaustivos; además, se pueden editar e importar a su instancia de Apache NIFI.
¿Cómo se implementa?
- Hay varios métodos de implementación disponibles:
Standalone AiO: La configuración predeterminada de NIFI incluye una instancia interna de Zookeeper. - Clúster autónomo : Hay dos opciones de configuración que permiten descentralizar la gestión del clúster mediante una instancia externa de Zookeeper.
- AiO autónomo con múltiples instancias : al igual que en la configuración Standalone AiO, es posible realizar el equilibrio de carga dentro de un clúster Zookeeper integrado directamente en Apache NIFI.
- Clúster autónomo con múltiples instancias : De la misma manera que la configuración anterior… utilizando varias instancias externas de Zookeeper.
Pero eso no es todo: la Fundación Apache (o, al menos, los desarrolladores) también han pensado en los aficionados a los contenedores, ya que también es posible implementar la aplicación mediante Docker Compose y Kubernetes (a través del gestor de paquetes Helm y el operador disponible aquí).
Aspectos a tener en cuenta
- Apache NIFI consume muchísimos recursos y espacio en disco; calcula al menos 1 GB para el archivo. El servicio se inicia sin problemas en un servidor poco potente, pero el arranque llevará mucho tiempo. Por poner un pequeño ejemplo, en una máquina virtual con 1 vCPU y 1 GB de RAM, el arranque de NIFI dura varios minutos.
- Al igual que muchos proyectos impulsados por la Fundación Apache, hay algunos requisitos previos. El primero y más importante es Java, o bien OpenJDK (la versión 11 funciona muy bien).
- Es cierto que la configuración está bien explicada en la página web oficial; cada opción se detalla, ya sea la agrupación en clústeres (Zookeeper), el cifrado (abordaré este tema más adelante), las notificaciones, la configuración del proxy… Todoestá ahí y es fácil de encontrar. Si por casualidad no encuentras lo que buscas, una simple búsqueda en Internet te dará la respuesta que necesitas.
- La Fundación Apache también ha puesto a disposición un kit de herramientas NIFI con múltiples funciones: Flow Analyzer, Node Manager, la interfaz de línea de comandos (para facilitar el inicio de NIFI), Zookeeper Migrator, etc.
Seguridad y cifrado
Cuando me refiero a la seguridad y al cifrado, me refiero a los certificados TLS, la gestión de usuarios y los almacenes de claves de tipo KMS, lo que nos lleva a la sección «nifi.security » del archivo «nifi.properties».
Certificados TLS
En Apache, Nginx, Cherokee y otros servicios cuya configuración es relativamente sencilla, la declaración de certificados TLS no requiere el uso de «magia negra» ni de herramientas o software poco comunes… Sin embargo, algunos servicios que necesitan Java para funcionar requieren un almacén de claves.
La creación de dicho artefacto a veces obliga a realizar malabarismos con los siguientes comandos:
# Creación del almacén de claves
keytool-genkey-alias mydomain -keyalg RSA -almacenamiento de claves KeyStore.jks -tamaño de clave 2048
# Generar una CSR básica en el nuevo almacén de claves
keytool-certreq-alias mydomain -keystore KeyStore.jks -archivo mydomain.csr
# Importe los certificados raíz e intermedios a su almacén de claves
keytool-import-trustcacerts-alias root -file root.crt -almacén KeyStore.jks
keytool-import-trustcacerts-alias intermedio -file intermedio.crt -almacenamiento de claves KeyStore.jks
# Descarga e importa tu nuevo certificado
keytool-import-trustcacerts-alias mydomain -file mydomain.crt -almacenamiento KeyStore.jks
Por su parte, NIFI, con la ayuda del NIFI Toolkit, ofrece un método mucho más sencillo: tls-toolkit.sh, un único comando, en lugar de cinco, para generar un almacén de claves de forma mucho más fiable.
bin/tls-toolkit.sh standalone -n'nifi[01-10].subdominio[1-4].dominio(2)'-C'CN=username,OU=NIFI'--subjectAlternativeNames'nifi[21-30].other[2-5].example.com(2)'
Les invito a consultar la documentación sobre los distintos escenarios relacionados con tls-toolkit (autónomo o cliente/servidor).
Almacenes de llaves de tipo KMS
Es un tema muy amplio, entre el NIFI Toolkit, que ofrece el comando encrypt-config.sh y las opciones de configuración del cifrado de contraseñas mediante Hashicorp Vault, AWS KMS, Google Cloud KMS y Azure Key Vault, no falta nada para proteger al máximo su instancia de NIFI (y no he abordado el endurecimiento del sistema operativo en el caso de una máquina virtual, tema que no se tratará en este artículo).
En cuanto a los servicios de gestión y generación de claves de seguridad, cada uno tiene su propia sección en el archivo de configuración nifi.properties:
- Hashicorp Vault: vault,
- AWS KMS: aws.kms,
- Azure Key Vault: azure.keyvault,
- Google Cloud KMS: google.kms
Solo he mencionado las secciones; evidentemente, las opciones de configuración son mucho más completas e incluyen la URL del servicio, las credenciales para que NIFI pueda autenticarse en él, la ruta de la clave o su ID y, en el caso de Hashicorp Vault, los tipos de almacenes (ssl keystore/truststore, key/value), los conjuntos de cifrado activados, los distintos protocolos, etc.Opciones de configuración extremadamente completas.
El comando encrypt-config.sh del NIFI Toolkit lleva bastante lejos el concepto de seguridad al cifrar la configuración del cifrado directamente en el archivo nifi.properties.
¿A quién se le ocurrió que dos medidas de seguridad son mejores que una sola?
Gestión de usuarios
En este nivel, las opciones disponibles son relativamente numerosas: Single User, Lightweight Directory Access Protocol, Kerberos, OpenID Connect, SAML, Apache Knox y JSON Web Tokens, siendo Single User la opción predeterminada.
Las credenciales predeterminadas se encuentran en el archivo login-identity-providers.xml…sin cifrar; sin embargo, el siguiente comando permite modificarlas:
./bin/nifi.sh set-single-user-credentials <username><password>
La configuración del Protocolo ligero de acceso a directorios (o LDAP) requiere un poco más de trabajo, sobre todo en el archivo login-identity-providers.xml, tras modificar la opción nifi.security.user.login.identity.provider.
El archivo login-identity-providers.xml específico para LDAP
<provider>
<identifier>ldap-provider</identifier>
<class>org.apache.nifi.ldap.LdapProvider</class>
<property name="Authentication Strategy">START_TLS</property>
<property name="Manager DN"></property>
<property name="Manager Password"></property>
<property name="TLS - Keystore"></property>
<property name="TLS - Keystore Password"></property>
<property name="TLS - Keystore Type"></property>
<property name="TLS - Truststore"></property>
<property name="TLS - Truststore Password"></property>
<property name="TLS - Truststore Type"></property>
<property name="TLS - Client Auth"></property>
<property name="TLS - Protocol"></property>
<property name="TLS - Shutdown Gracefully"></property>
<property name="Referral Strategy">FOLLOW</property>
<property name="Connect Timeout">10 secs</property>
<property name="Read Timeout">10 secs</property>
<property name="Url"></property>
<property name="User Search Base"></property>
<property name="User Search Filter"></property>
<property name="Identity Strategy">USE_DN</property>
<property name="Authentication Expiration">12 hours</property>
</provider>
La documentación oficial es muy completa y os recomiendo encarecidamente que le echéis un vistazo para conocer todas las opciones de configuración disponibles y así proteger vuestra instancia de NIFI lo mejor posible.
Faltan alternativas verdaderamente gratuitas y de código abierto; entre los proveedores de servicios en la nube, no hay ningún servicio que integre todas las funcionalidades de NIFI, sino una combinación de varios:
- AWS: Data Pipeline, Glue y SWS (Simple Workflow Service),
- Azure: Data Factory, Data Catalog y Logic Apps,
- Google Cloud: DataPrep y Cloud Composer,
- IBM Cloud: DataStage y Watson Knowledge Catalog,
Además, a pesar de la aparente simplicidad de la interfaz y de la relativa facilidad para implementar flujos de trabajo de gestión de datos, el elevado número de procesadores y controladores—algunos de los cuales se encuentran en plena fase de obsolescencia, siguen estando documentados pero sin fecha de retirada anunciada— puede suponer un verdadero obstáculo para el uso de esta solución.
Y ni siquiera menciono las múltiples versiones de un mismo Processor ( las relacionadas con Kafka, por ejemplo)...por si acaso, podría ser útil.
Mickaël DANGLETERRE
Arquitecto de Cloud y DevOps
