Seguridad en arquitecturas basadas en OpenLDAP

Hace ya unos cuantos meses vimos como podíamos integrar Kerberos con un servidor OpenLDAP, creando así un servicio de nombres y autenticación en el cual OpenLDAP se utiliza como base de datos para los principales de Kerberos, así como para almacenar información de cuentas de usuarios y grupos para sistemas Unix/Linux. Aprovechando las funcionalidades de replicación de OpenLDAP, conseguíamos posteriormente un despliegue con tolerancia a fallos.

Para continuar mejorando lo que hicimos entonces, vamos a establecer las medidas de seguridad necesarias que aseguren que las comunicaciones entre los diferentes elementos que forman la solución se encriptan siempre que sea posible.

Empezando por lo más sencillo, es necesario establecer unas reglas en los cortafuegos que solo permitan las conexiones a los puertos requeridos de cada uno de los servicios proporcionados. En concreto es necesario crear reglas para permitir las conexiones a los siguientes puertos:

• Puertos 389 y 636. Puertos de servicio de OpenLDAP para establecer conexiones cifradas mediante StartTLS y ldaps respectivamente.
• Puerto 88. Puerto de servicio del KDC de Kerberos. Necesario para realizar la autenticación de usuarios mediante la petición y expedición de tickets.
• Puertos 464 y 749. Puertos del servicio kadmin de Kerberos para el proceso de cambio de contraseñas.

Una vez establecidas estas reglas básicas de cortafuegos, el siguiente paso es cifrar las comunicaciones entre los servidores OpenLDAP y los clientes que deban acceder a los mismos. Llegados este punto puede resultar interesante que consideremos el siguiente diagrama:

Relaciones entre los componentes de la solución.

Analizando el diagrama anterior y teniendo en cuenta que los servidores OpenLDAP son el repositorio central de toda la arquitectura del servicio de nombres y validación que queremos desplegar, está claro que es necesario cifrar todas las comunicaciones que se realicen desde cualquier cliente. Es importante señalar que, desde el punto de vista de OpenLDAP, Kerberos es un cliente de LDAP más, ya que este realizará consultas para buscar los principales correspondientes a todas aquellas peticiones de validación que reciba. También es importante señalar que para realizar el passthrough de autenticación, OpenLDAP delega el proceso de autenticar un usuario contra el KDC a través del servicio saslauthd que se encuentra corriendo en el mismo servidor.

Aunque posteriormente volveremos sobre este diagrama, empecemos por cifrar las comunicaciones entre OpenLDAP y los clientes existentes, incluido el servidor OpenLDAP secundario o réplica ya que, para utilizar el mecanismo de replicación syncrepl, se realizan consultas LDAP estándar así que, estas comunicaciones también podemos entenderlas como procedentes de un cliente LDAP.

Para cifrar las comunicaciones lo que necesitamos es disponer de un par clave privada-certificado por cada servidor. Podemos crear nuestra propia CA de forma simple con OpenSSL, crear certificados autofirmados o, si disponemos de una CA corporativa, generar dichos certificados en ella. En resumen, al final terminaremos con un par de ficheros en formato PEM que tendremos que copiar a nuestros servidores y configurar OpenLDAP para que los utilice para el cifrado de las comunicaciones.

 

Una vez copiados los ficheros y aprovechando el backend config, configuramos de forma dinámica los servidores, cambiando los siguientes atributos de configuración:

• olcTLSCACertificateFile, este atributo establece la ruta y fichero que contiene los certificados de todas las CAs en las que se confía.
  
• olcTLSCACertificatePath, este atributo establece la ruta que contiene los ficheros con los certificados de todas las CAs en las que se confía. Este parámetro es complementario al anterior y probablemente no sea necesario usar ambos.
  
• olcTLSCertificateFile, este atributo establece la ruta y fichero que contiene el certificado del servidor OpenLDAP.
• olcTLSCertificateKeyFile, este atributo establece la ruta y fichero que contiene la clave privada correspondiente al certificado del servidor OpenLDAP.
• olcTLSCipherSuite, este atributo establece que cifrados acepta el servidor OpenLDAP, así como el orden de los mismos. Es muy importante tener en cuenta que, el valor de este atributo, depende de la biblioteca SSL que se haya utilizado para la compilación de OpenLDAP. Esto quiere decir que, la cadena que utilicemos como valor para este atributo, debe ser entendida por la biblioteca. Como apunte para tenerlo en cuenta, en el caso de CentOS, OpenLDAP está compilado contra OpenSSL, mientras que en Debian está compilado contra GnuTLS. 
  

Debido al impacto que tiene en las comunicaciones, de momento dejaremos de lado el atributo olcTLSCipherSuite así que, usando nuestro editor favorito de servidores LDAP, cambiamos adecuadamente el valor del resto de atributos de configuración en la rama cn=config y tendremos algo similar a lo siguiente:

Configuración de certificados en OpenLDAP.

Es necesario asgurar que la ruta y permisos de estos ficheros son correctos o recibiremos un error al modificarlos, ya que el proceso slapd intentará acceder a los mismos y al no poder hacerlo, rechazará la modificación de dichos atributos.

 

A continuación, una vez configurados los certificados de ambos servidores, tenemos dos opciones para realizar el encriptado de las comunicaciones, levantar slapd con el puerto adicional 636 para el uso de ldaps o habilitar el uso de StartTLS sobre el puerto estándar 389. Veamos un poco las diferencias entre ambas soluciones:

• ldaps, también conocido como LDAP seguro, es el mecanismo diseñado originalmente para LDAPv2 que permite confidencialidad en las comunicaciones entre un servidor OpenLDAP y un cliente. Se inicia en el momento de establecer la conexión entre el servidor y el cliente y requiere el uso de un puerto adicional que, por defecto, es el 636. 
  
• StartTLS es el mecanismo estándar defiinido en la RFC 2830 para LDAPv3. En esta RFC se establece el procedimiento para que, una vez que se ha establecido correctamente la conexión LDAP entre cliente y servidor, se habilite el uso de TLS/SSL para cifrar la comunicación sobre el puerto 389 estándar de cualquier servidor LDAP.
  

Lo cierto es que, una vez establecida la conexión cifrada, no hay diferencia entre ambas soluciones, salvo por el uso de un puerto adicional en el caso de ldaps. Como el uso de una u otra solución dependerá de las necesidades de los clientes que vayan a conectarse, es importante considerar ambas para fijar una u otra, pero es importante tener en cuenta que es preferible usar StartTLS siempre que sea posible.

Teniendo en cuenta las diferencias entre ldaps y StartTLS, de momento vamos a configurar ambas empezando por la sencilla. Para configurar ldaps, solo tenemos que levantar el servidor OpenLDAP especificando una URL adicional para ldaps. En general, haremos esto modificando el fichero slapd que define los parámetros utilizado para arrancar el servicio. En función de la distribución utilizada, este fichero se encontrará en una ruta u otra. En el caso de usar CentOS o Debian, estos ficheros están en /etc/sysconfig y /etc/default respectivamente:

Configuración URL ldaps - CentOS.

Configuración URL ldaps - Debian.

Tras realizar este cambio y reiniciar el servicio slapd, este escuchará en el puerto 636 presentando el certificado obtenido inicialmente para cada servidor. Al conectar de nuevo al servidor desde un cliente LDAP, debemos escoger como puerto de conexión el 636 y SSL como método de encriptación, con lo que estaremos usando ldaps para conectarnos con el servidor. Usando Apache Directory Studio recibiremos un mensaje, acerca del certificado presentado por el servidor OpenLDAP, como el siguiente al establecer la conexión por primera vez al puerto 636:

 

Verificación de certificado de servidor.

De este modo tan simple, podemos asegurar que la conexión entre nuestro cliente y el servidor OpenLDAP está cifrada protegiendo de momento mediante ldaps, las tareas de administración que realicemos.

A continuación vamos a cifrar el tráfico de replicación entre el servidor master y el servidor réplica de la infraestructura, para lo cual usaremos StartTLS en vez de ldaps. Para esto, una de las primeras comprobaciones que debemos hacer ,es verificar que el servidor soporta la extensión StartTLS definida en la RFC 2830. Podemos comprobarlo mediante una búsqueda sencilla con ldapsearch o bien usando un editor LDAP. En general, mediante un comando ldapsearch, el resultado que debemos obtener es similar al siguiente:

 

Lista de controles, características y extensiones soportadas.

 

Entre todos los OIDs que se muestran en la salida anterior, el correspondiente a StartTLS es el 1.3.6.1.4.1.1466.20037 como se describe en la RFC 2830. Esto indica que cuando configuremos cualquier cliente para emplear StartTLS, este enviará este OID en una petición extendida solicitando el uso de dicha extensión. Al estar soportada por el servidor, la conexión LDAP establecida pasará a estar cifrada entre ambos servidores para el tráfico de replicación.

 

Para configurar el uso de StartTLS entre ambos servidores, solo es necesario modificar el atributo olcSyncRepl existente en el servidor réplica, ya que hay que recordar que en OpenLDAP, la operación de replicación se inicia desde los servidores réplica y que en el servidor maestro solo es necesario habilitar el overlay syncprov para permitir las replicaciones.

En este caso, lo más recomendable es utilizar un editor gráfico LDAP para realizar la modificación de este atributo, el cual está definido en la rama cn=config de configuración dinámica del servidor. Para forzar el uso de StartTLS entre los servidores, las opciones que debemos añadir al atributo olcSyncRepl son las siguientes:

• starttls=yes o critical, para establecer la sesión TLS antes de realizar la operación de autenticación con el servidor LDAP maestro. Si usamos la opción critical, la replicación fallará en caso de no poder iniciarse la sesión TLS. Si especificamos yes, pasará a usar ldap no cifrado en caso de fallo en el establecimiento de la sesión TLS.
  
• tls_cert, tls_key, tls_cacaert y tls_cacertdir, para establecer la ruta a los ficheros de certificado, tanto de CAs como del propio servidor, así como al fichero que contiene la clave privada del servidor LDAP réplica.
• tls_reqcert=demand, para forzar al servidor maestro el presentar su certificado para la conmprobación del mismo.
  

Teniendo en cuenta todas estas opciones, lo único que necesitamos es cambiar el atributo del siguiente modo:

 

Modificación de olcSyncRepl en servidor réplica.

Aunque hemos usado el backend de configuración dinámica y estas opciones se empiezan a utilizar en el momento de establecerlas, es necesario reiniciar el servidor réplica. Una vez hecho esto, lo primero es comprobar que la replicación funciona correctamente, para lo cual basta con añadir una nueva entrada o modificar una ya existente y confirmar que los cambios se replican adecuadamente.

 

Podemos comprobar que, efectivamente, se está realizando la replicación MASTER-RÉPLICA de forma cifrada mediante el comando tcpdump:

 

Replicación cifrada entre master y réplica.

 

Estos paquetes los veremos en el momento de realizar cualquier modificación en el servidor master y, como se puede apreciar, el tráfico de replicación está cifrado entre ambos servidores. Adicionalmente,  podemos comprobarlo en los logs de ambos servidores:

 

Sesión TLS entre servidor master y réplica.

 

Y por último, aseguramos que la replicación es correcta verificando que el contextCSN de ambos servidores es idéntico:

 

ContextCSN del servidor MASTER.

 

ContextCSN del servidor RÉPLICA.

Por tanto, llegados a este punto, tenemos cifradas las comunicaciones entre los clientes LDAP como pueden ser las herramientas administrativas así como la replicación entre el servidor MASTER y los servidores RÉPLICA existentes.

Ahora, recordando el análisis realizado al principio del post y para terminar, es necesario que establezcamos la seguridad de las comunicaciones necesarias entre los servicios de Kerberos y el servidor OpenLDAP. Como ya se estableció, desde el punto de vista de OpenLDAP, tanto el servicio kdc como el servicio kadmin, son clientes LDAP, los cuales debemos configurar adecuadamente para o bien utilizar ldaps o emplear StartTLS.

Como ya vimos en el post en el que integrábamos Kerberos con un backend OpenLDAP, toda la configuración necesaria debemos realizarla en el fichero kdc.conf, el cual se encuentra en la ruta /var/kerberos/krb5kdc en sistemas CentOS o en la ruta /etc/krb5kdc en el caso de sistemas Debian. El fichero que generamos entonces es similar al siguiente:

Fichero de configuración kdc.conf.

Revisando la documentación de Kerberos comprobamos que, a la hora de especificar la URL de los servidores LDAP, lo recomendado es emplear ldaps para asegurar que la comunicación entre los servicios de Kerberos y OpenLDAP está cifrada.

En este caso, como Kerberos hará uso de las bibliotecas LDAP del sistema operativo, lo primero que debemos hacer es configurar el fichero ldap.conf. En este fichero se establece la configuración del cliente ldap del sistema, indicando la ruta al fichero que contendrá el certificado de la CA que ha firmado el certificado empleado por OpenLDAP. Para realizar esta configuración solo necesitamos modificar la opción TLS_CACERT indicando la ruta al fichero, o la opción TLS_CACERTDIR, para indicar la ruta al directorio donde se encuentran los ficheros con los certificados de las CAs en las que se confía:

 

Fichero ldap.conf.

 

Con esta configuración establecida, solo necesitamos modificar el fichero kdc.conf e indicar como URL de acceso ldaps:// en el parámetro de configuración ldap_servers. El fichero quedaría más o menos así:

Fichero kdc.conf modificado para usar ldaps.

 

Una vez realizado este cambio solo nos falta reiniciar los servicios y comprobar que estos arrancan y se conectan al puerto 636 correctamente:

Conexiones del servicio kdc mediante ldaps.

Conexiones del servicio kadmin mediante ldaps.

Llegado este punto, las comunicaciones entre los diferentes elementos del sistema que establecen conexiones con el servidor OpenLDAP están cifradas pero, para terminar de asegurar que solo se permiten este tipo de conexiones, es necesario que configuremos el propio servidor OpenLDAP para que exija el uso de confidencialidad en todas las conexiones. Para esto, lo único necesario es que establezcamos el atributo de configuración olcSecurity con el valor ssf=1. Al establecer este atributo, cualquier conexión no cifrada se rechazará con el mensaje confidentiality required sin necesidad de reiniciar el servidor OpenLDAP:

Mensaje de error para conexiones no cifradas.

En resumen, hemos establecido las configuraciones mínimas necesarias para establecer la encriptación y por tanto confidencialidad de las comunicaciones entre el servicio OpenLDAP y los clientes existentes, incluyendo los servicios de Kerberos que emplean el servidor LDAP como backend. Además hemos establecido que el servidor OpenLDAP exija siempre el uso de encriptación en cualquier conexión que se establezca, lo que provoca que no puedan realizarse conexiones no encriptadas al puerto 389. Teniendo esto último en cuenta, para comprobar el contextCSN de cada uno de los servidores, ahora necesitamos realizar el comando ldapsearch especificando la opción -Z del siguiente modo:

Comprobación del contextCSN mediante StartTLS.

Tengamos en cuenta que, al haber configurado el cliente ldap del sistema, especificando la ruta al fichero que contiene el certificado de la CA en ldap.conf, las herramientas como ldapsearch usarán dicha configuración para establecer la comunicación mediante StartTLS correctamente.

Para terminar, solo falta impedir que se puedan realizar operaciones bind anónimas, para lo cual solo es necesario que cambiemos el atributo de configuración dinámica olcDisallows y especifiquemos bind_anon lo cual queda más o menos así:

Deshabilitando el bind anónimo.

También es recomendable establecer que se requiere siempre autenticación, para realizar cualquier tipo de operación en el servidor de directorio, así como requerir siempre el uso del protocolo LDAPv3. Estas opciones podemos establecerlas modificando el atributo olcRequires como se ve en la imagen anterior. Con estos cambios, al intentar hacer una búsqueda empleando un bind anónimo, recibimos un mensaje como el siguiente:

Error en operaciones con bind anónimos.

Este cambio provoca que cualquier cliente que hayamos configurado, que realice operaciones bind anónimas, requiera ahora de un usuario del directorio, especificado por su DN y una contraseña. Como veremos en futuras entradas, esta configuración es muy importante cuando configuramos cualquier sistema Unix/Linux para que utilice un servidor OpenLDAP como servicio de nombres y requerirá la correcta configuración del servicio nslcd o sssd.

En próximas entradas, veremos como integrar un servidor DNS con OpenLDAP así como emplear tickets Kerberos para el acceso a los diferentes servicios, especificando diferentes mecanismos SASL para la validación al realizar operaciones.

Kubernetes - Notas adicionales sobre ReplicaSets

Continuando con los objetos de tipo ReplicaSets, hoy vamos a ver unas notas adicionales que pueden ser de interés y que debemos tener en cuenta.

Como ya vimos en la anterior entrada sobre los objetos ReplicaSet, este tipo de objeto permite controlar de forma automática un conjunto de PODs. Esto implica que el KCP monitorizará en todo momento el número de PODs del ReplicaSet, asegurando que el estado del cluster coincida con la configuración que hemos aplicado y manteniendo el número de PODs que hayamos fijado en la configuración del objeto ReplicaSet.

En resumen, partiendo de una situación como la siguiente:

Objeto ReplicaSet en el cluster.

Vemos que hemos definido un ReplicaSet en el que hemos fijado que siempre debe haber un total de 2 PODs corriendo en todo momento. Evidentemente este caso es muy sencillo y vemos rápidamente la relación entre los PODs y el ReplicaSet correspondiente, pero en entornos reales donde podemos tener cientos de PODs corriendo esto puede ser bastante más confuso, con lo que podemos comprobar como está gestionado un POD haciendo un describe del mismo:

Describe de un POD controlado por un ReplicaSet.

Como vemos en la líinea Controlled By, este POD está controlado por el objeto superior ReplicaSet/webapp.

Sabemos que los PODs controlados por un objeto de tipo ReplicaSet están dados por el selector del ReplicaSet y la etiqueta de los PODs, es decir que todos los PODs que contengan la etiqueta que coincida con el selector definido serán controlados por un ReplicaSet determinado.

Esto nos puede llevar a situaciones en las que, si por alguna razón hay PODs con etiquetas coincidentes con las del campo selector de un ReplicaSet, dichos PODs pasen a estar bajo el control de dicho ReplicaSet. Por ejemplo, partiendo de la situación anterior, si arranco manualmente un POD basado en la siguiente descripción:

Definición de un POD simple.

Al aplicar esta configuración debería existir un nuevo POD, con el nombre webserver-v1, corriendo en el cluster:

Estado del cluster.

Pero, como podemos ver, el nuevo POD no aparece en la salida del comando get all así que ¿donde está el nuevo POD? Es importante que nos fijemos en que el campo selector del ReplicaSet coincide con el campo label asignado en el POD que hemos descrito, por tanto el KCP lo ha puesto directamente bajo el control del ReplicaSet webapp. Como el número de PODs establecido del ReplicaSet ya coincide con el número de PODs corriendo en el sistema, el nuevo POD con nombre webserver-v1 se ha borrado nada más arrancar. Podemos confirmar este hecho consultando la sección de Events del ReplicaSet con el subcomando describe de kubectl:

Descripción del ReplicaSet webapp.

Podemos observar que la última línea muestra que se ha borrado el POD webserver-v1, lo que nos indica que nada más aplicar el fichero de descripción del mismo, el KCP ha puesto dicho POD bajo control del ReplicaSet webapp debido a que su etiqueta coincide con el campo selector del mismo.

Este punto debe tenerse en cuenta ya que implica que, si no identificamos correctamente las templates de PODs de diferentes objetos, podemos provocar conflictos en los cuales objetos de bajo nivel como PODs estén controlados por otros de alto nivel a los que no corresponden.

Hasta aquí lo más básico relacionado con los objetos de tipo ReplicaSet, en próximas entradas veremos como controlar este tipo de objetos con Deployments.

Kubernetes - Conceptos básicos III

Siguiendo con los conceptos básicos de Kubernetes, vamos a estudiar de forma simple la arquitectura de un cluster de Kubernetes.

Vimos en la primera entrada de esta serie de posts que podíamos distinguir entre nodos master y nodos worker, llamados anteriormente minions. En general, dentro de la terminología de Kubernetes, un nodo es directamente un worker, el cual se caracteriza porque dispone del motor de ejecución de contenedores, los procesos kubelet y kube-proxy y es gestionado por los componentes del master.

 

En general, la arquitectura de un cluster de Kubernetes estará formado por uno o más nodos master y varios nodos worker. Los administradores usarán el comando kubectl para comunicarse con un balanceador de carga, que repartirá las conexiones entre todos los nodos master, controlando así el cluster y estableciendo el estado deseado del cluster. La forma más sencilla de ver esta arquitectura es la siguiente:

 

Arquitectura básica de un cluster de Kubernetes.

Esta gestión de los nodos worker por parte del master, se realiza mediante la comunicación entre el apiserver del nodo master y el proceso kubelet de los nodos worker. Esta comunicación permite al master obtener los logs del nodo worker, la ejecución de contenedores y proporcionar la característica de reenvío de puertos de kubelet.

Esta comunicación entre el apiserver y kubelet se realiza mediante el protocolo HTTPS, pero el apiserver por defecto no comprueba el certificado ofrecido por kubelet. Para forzar la comprobación del certificado ofrecido por kubelet, es necesario usar la opción --kubelet-certificate-authority del apiserver especificando un conjunto de certificados raíz que permitan la comprobación del certificado de kubelet.

El apiserver también se conecta con los nodos y contenedores usando el protocolo HTTP y aunque, puede cambiarse a HTTPS no se realiza ningún tipo de validación de credenciales ni de comprobación de certificados en estas conexiones.

Adicionalmente, los nodos worker y servicios del propio master se comunican con el apiserver, que por defecto acepta peticiones HTTPS en el puerto 443. Para añadir más seguridad a estas comunicaciones es importante utilizar autenticación de clientes, por ejemplo mediante certificados de cliente, así como autorizaciones para dichas conexiones.

Podemos obtener el estado de un worker, en base a una serie de características del mismo, utilizando el comando siguiente:

Descripción de estado de un nodo.

 

La salida de este comando es bastante extensa y entre toda la información que proporciona, nos devolverá el rol del nodo, su hostname y dirección interna y externa, la capacidad del nodo en terminos de CPU y memoria disponible, la versión del motor de ejecución de contenedores, una lista de los últimos eventos y el estado de condiciones como falta de memoria o disco.

Dentro de los tipos de condiciones de un nodo worker, es muy importante la condición Ready. Esta condición indica al master si el nodo worker es capaz de ejecutar contenedores y puede tener tres valores diferentes, True, False o Unknown. Si la condición Ready de un nodo worker permanece en estado False o Unknown durante más de un tiempo determinado, que por defecto son 5 minutos y se denomina pod-eviction-timeout, el kube-controller-manager del master lanza un borrado de los contenedores que se estén ejecutando en el nodo worker. Si el master no puede comunicarse con el proceso kubelet del nodo worker, es posible que los contenedores sigan ejecutándose en el nodo fallido hasta que la comunicación con el kube-apiserver vuelva a establecerse.

En caso de querer realizar algún tipo de operación de mantenimiento con un nodo worker, que implique que el nodo no puede aceptar contenedores, podemos hacer el nodo worker no disponible con el comando:

Marcando un nodo como no disponible.

El proceso kube-controller-manager del master ejecuta controladores que operan sobre recursos y objetos del cluster de Kubernetes, siendo uno de estos el controlador de nodos. Este controlador de nodos es responsable, entre otras cosas, de monitorizar la salud de todos los nodos del cluster y en caso de ser necesario, de mover los contenedores de un nodo que no responde a otro cuyo estado Ready sea True.

Kubernetes y el soporte de Docker

Tras el anuncio por parte del equipo de Kubernetes de no continuar soportando Docker como motor de ejecución de contenedores, muchos hemos pensado ¿y ahora que es lo que debemos hacer? Pues para empezar, lo mejor es leer el anuncio oficial de Kubernetes, el cual podéis encontrar en el siguiente enlace.

Otro artículo interesante, publicado por Red Hat, explica un poco más las razones detrás de este cambio y en el cual podemos ver que está muy relacionado con la complejidad del desarrollo que implica integrar Docker como motor de contenedores.

Lo importante que sacamos en claro de ambos artículos, es que podemos seguir usando todas las imágenes que hemos desarrollado hasta hora utilizando Docker con lo que, en principio, el impacto debería ser mínimo.

Sin embargo, para ir adelantándonos un poco, vamos a ver de forma rápida como podemos adaptar una instalación que tengamos de minikube para que el motor de ejecución de contenedores sea otro diferente a Docker.

En un post anterior vimos como instalar minikube usando un host con Docker. Aquella instalación utilizaba Docker como motor para la ejecución de contenedores. Ahora, lo que vamos a hacer es sencillamente volver a crear un cluster de Kubernetes mediante minikube, pero en este caso vamos a especificar que el runtime de contenedores será otro diferente, en mi caso he escogido containerd ya que se instala por defecto con Docker. El comando en cuestión es el siguiente:

Creación del "cluster" con minikube.

Es recomendable actualizar a las últimas versiones disponibles de minikube y containerd, además de especificar en el comando que la versión de Kubernetes a usar es la 1.20.0. Para el correcto funcionamiento de la red, en mi caso ha sido necesario copiar el contenido de la ruta /usr/libexec/cni a /opt/cni/bin. Esto se debe a que, por defecto, los plugins CNI se buscan en /opt/cni/bin pero el paquete containernetworking-plugins los instala en /usr/libexec/cni. Como referencia, podemos ver que el fichero de configuración de containerd (/etc/containerd/config.toml) especifica que la ruta para la búsuqeda de plugins de red es /opt/cni/bin así que podemos cambiarlo igualmente a la ruta de instalación del paquete containernetworking-plugins:

Configuración de los plugins CNI.

Una vez creado correctamente nuestro cluster, podemos comprobar que el motor de contenedores ya no es Docker con solo comprobar si hay contenedores corriendo bajo su control:

Contenedores controlados por Docker.

 

Podemos ver, sin embargo, que los PODs de los servicios de infraestructura de Kubernetes se encuentran corriendo correctamente:

 

Servicios de infraestructura de Kubernetes.

Como hemos cambiado el runtime de contenedores a containerd, podemos comprobar que estos se están ejecutando correctamente usando el comando siguiente:

Contenedores bajo el control de containerd.

Un punto importante del comando anterior, es que he tenido que especificar el namespace del cual quiero obtener información, siendo por defecto k8s.io para containerd. En este namespace veremos tanto los contenedores de infraestructura de Kubernetes, así como aquellos correspondientes a nuestros servicios.

Por tanto hemos cambiado el runtime de nuestro cluster a containerd correctamente. Ahora solo tenemos que comprobar que, cualquiera de nuestras imágenes usadas hasta ahora con Docker, siguen funcionando correctamente. Por ejemplo, creando un replicaset con la imagen de un servidor Apache simple almacenada en Docker Hub, tenemos lo siguiente:

Despliegue de un replicaset usandoo una imagen en Docker Hub.

Por tanto, nuestras imágenes pueden seguir usándose sin problemas y el impacto que podemos tener es menor de lo que podíamos pensar. De todos modos, es importante revisar el impacto que implica en clusters reales el cambio del runtime de contenedores de Docker a containerd o cri-o. Además será importante investigar un poco más como funcionan y como podemos interactuar coon estos motores de contenedores.

ELK - Creando visualizaciones simples

Hace demasiado que no publicaba una nueva entrada sobre la pila ELK, la última entrada tiene más de un año, así que hoy vamos con un nuevo post en el que vamos a utilizar las capacidades de ingesta de Elasticsearch y, con los datos que tengamos, realizaremos una gráfica simple. 

 

En las entradas anteriores enviabamos datos a Logstash, para procesarlos y crear documentos con los campos necesarios para posteriormente almacenarlos en un índice de Elasticsearch. Además, también vimos como crear un índice y definíamos el tipo de dato específico de los campos que nos interesan.

Desde entonces ha llovido mucho y aunque continuamos con una configuración similar, vamos a introducir un pequeño cambio y usaremos un nodo de elasticsearch como nodo de ingesta, en el cual podremos definir un pipeline para procesar los datos que recibimos sin necesidad de usar Logstash. Básicamente, lo que estamos haciendo es pasar la funcionalidad de Logstash directamente al cluster de Elastic.

 

Para esto, vamos a empezar de forma sencilla analizando los mensajes que vamos a recibir desde un nodo que nos envía información mediante filebeat, la cual vamos a generar usando syslog_generator:

 

Mensajes recibidos desde filebeat.

 

Como vemos, filebeat envía una gran cantidad de campos que no nos interesan, ya que solo queremos quedarnos con el campo message que contiene el mensaje real creado por syslog_generator.

 

Vamos a empezar de forma simple creando un pipeline en Elastic que elimine todos esos campos que nos sobran. Para este tipo de tareas, como siempre, lo mejor es utilizar la consola de desarrollo de Kibana. Veamos directamente el pipeline para analizarlo posteriormente:

 

Pipeline básico de eliminación de campos.

Con este pipeline definimos que queremos eliminar una serie de campos de los mensajes recibidos, en concreto los que aparecen en el campo field dentro del procesador remove, que podemos ver en la imagen superior.

Una vez definido un pipeline, este queda almacenado en el cluster, pero para usarlo necesitamos asociarlo a un índice. Para seguir con nuestras pruebas, lo que hacemos es editar el índice que se ha creado automáticamente en el cluster en cuanto ha empezado a recibir datos de los nodos con filebeat y modificamos su atributo index.default_pipeline. Este atributo establece que pipeline hay que aplicar a los documentos recibidos antes de almacenarlos en el índice. Podemos editarlo desde la opción Edit Settings de la sección Index Management:

Modificación de las propiedades del índice.

Al especificar que debe aplicarse el pipeline a los documentos antes de almacenarlos, todos los campos que hemos indicado dentro del procesador remove del pipeline son eliminados, con lo que ahora podemos ver lo siguiente desde la sección Discover para el patrón del índice generado por filebeat:

Documentos en el índice filebeat tras pasar por el pipeline.

Como vemos, ahora cada documento se ha almacenado en el índice sin los campos que hemos eliminado anteriormente.

Para llegar a este punto hemos tenido que modificar manualmente el índice que se ha creado de forma automática pero, como esto no es muy operativo que se diga, empecemos por establecer en la configuración de filebeat que pipeline debe utilizarse estableciendo la opción pipeline en el fichero filebeat.yml de nuestro nodo filebeat origen:

Configuracion de filebeat aplicando el pipeline.

Por tanto, como vemos, podemos aplicar el pipeline a la salida configurada de filebeat en origen directamente. Al hacerlo comprobamos que todos los campos que hemos configurado en el procesador remove del pipeline remove_extra_fields, no se han almacenado en los documentos del índice filebeat.

Por tanto, ahora que tenemos claro que podemos pasar cierta funcionalidad de Logstash directamente a Elasticsearch, pasemos a hacer un pipeline que procese nuestro campo message adecuadamente, nos devuelva los campos que necesitamos, elimine el resto y para finalizar, escriba los documentos en un índice diferente, donde estableceremos los mapeos necesarios para cada campo, asegurándonos que el tipo de dato de cada uno se almacena de forma correcta.

El pìpeline que realiza toda la manipulación de campos que necesitamos es el siguiente:

Pipeline de eliminación de campos y procesado del campo message.

Como en la imagen anterior no queda muy claro, podéis encontrar el pipeline completo, junto con la creación del índice definitivo, anexado con este post.

Ya hemos comprobado que este pipeline modifica el documento, eliminando aquellos campos que no necesitamos y crea los nuevos campos a partir del procesado del campo message original. A continuación crearemos un índice especificando los campos que necesitamos en cada documento y, lo más importante, con el tipo de dato correcto. Ya sabemos que, para crear un índice, lo mejor es usar la consola de desarrollo de Kibana. Podemos crear el índice de una manera similar a la siguiente:

Creación del índice.

Una vez creado nuestro nuevo índice, creamos el index pattern necesario para que Kibana pueda obtener datos de Elasticsearch. Para esto, desde el menú Management, en la sección Index Patterns de Kibana, creamos el nuevo patrón especificando que el campo @timestamp es el que contiene la información de fecha y hora para poder hacer el filtrado por tiempo:

 

Creación del index pattern correspondiente al nuevo índice.

Seleccion del campo de fecha del index pattern.

Es importante que nos demos cuenta que el campo @timestamp de cada documento contiene la fecha y hora de recepción de la información enviada por filebeat, la cual no es la misma que aparece en el campo message. Para corregir esto, el pipeline hace una conversión del campo EVENT_TIMESTAMP que hemos construido con el procesador dissect y copia dicha información en el campo @timestamp. Esta operación de conversión la realiza el siguiente procesador:

Modificación del campo @timestamp.

A continuación cambiamos la configuración de filebeat en el nodo origen para especificar el nombre del pipeline que deseamos usar antes de almacenar los documentos en el índice:

Configuración definitiva de filebeat.

Con toda la configuración ya realizada, podemos comprobar como tenemos datos en el índice en los campos deseados y con el tipo de dato correcto:

Datos del indice temperature_sensors.

Ya con nuestros datos, podemos pasar a hacer una representación gráfica simple de los valores de temperatura recibidos desde la sección Visualize. Podemos crear una gráfica de tipo lineal para ver los valores medios de temperatura:

Valores medios de temperatura.

Esta representación nos muestra los valores medios de temperatura para cada intervalo temporal que seleccionemos. Para esto establecemos que en el eje Y queremos el valor medio del campo TEMPERATURE_VALUE de cada documento y, en el eje X establecemos un histograma basado en el campo de fecha y hora @timestamp.

El problema de esta visualización, es que estamos obteniendo el valor medio de los valores de temperatura enviados por tres sensores diferentes. Para mostrar en la misma gráfica el valor medio de temperatura, por cada uno de los sensores que estamos simulando con syslog_generator, tenemos que añadir filtros en el eje X para los identificadores de cada uno de los sensores. Esto podemos hacerlo más o menos del siguiente modo:

Filtro por cada sensor.

Al realizar esta configuración, pasamos a tener una gráfica como la siguiente:

Valor medio de temperatura por cada sensor.

Es importante tener en cuenta que cada uno de los valores que vemos en cada gráfica, se corresponden con el valor medio de todos los valores recibidos en ese intervalo de tiempo. Si aumentamos la resolución, disminuyendo el tiempo de representación de la gráfica, podemos ver algo como lo siguiente:

Valores de temperatura por segundo de cada sensor.

En esta gráfica ya tenemos una resolución de un segundo, correspondiente a la tasa de envío de información que he configurado en syslog_generator para simular la información de temperatura de cada sensor simulado.

Por tanto y en resumen, hemos visto como crear un pipeline que nos permite procesar los documentos que llegan a Elasticsearch, sin necesidad de utilizar Logstash, hacer las modificaciones necesarias para obtener los campos que nos interesan y almacenar dichos documentos en un índice diferente.

Además, basándonos en dichos datos, hemos creado una gráfica simple en la que hemos podido aplicar filtros para diferenciar entre diferentes fuentes del mismo índice.

En el siguiente enlace podéis encontrar el fichero que contiene la definición del pipeline así como la del índice utilizados a lo largo del post.