Learner, el nuevo estado de nodo en etcd v3.4

Aunque algunas configuraciones de Kubernetes como K3s utilizan otras bases de datos para guardar el estado, la gran mayoría de los despliegues de Kubernetes utilizan clusters etcd. Por eso es importante echarle un ojo a las novedades de la nueva versión 3.4 que acaba de ser publicada. También podéis leer el resumen que hacen en el blog de Kubernetes.

Entre las novedades que trae, hay una que parece que va a tener recorrido dentro de los futuros desarrollos de etcd y que hay que empezar a conocer. Se trata de un nuevo estado de nodo llamado learner. En este nuevo estado, el nodo no aumenta el quorum del cluster etcd y no puede participar en procesos de elecciones, sin embargo, recibe todos los datos y actualizaciones del líder. Un nodo en este estado learner puede ser promocionado a nodo seguidor y operar de forma normal dentro del cluster etcd cuando esté al día de los datos.

En el propio documento de diseño proponen los siguientes pasos de este estado learner para la futura v3.5:

• Aumentar la capacidad de reconfiguración y tolerancia a errores de configuración haciendo este estado por defecto al crear un nuevo nodo en el cluster.
• Promocionar al learner automáticamente a miembro con derecho a voto cuando se cumplan ciertas condiciones definidas por el usuario.
• Dejarlo "en el banquillo" y promocionar al learner automáticamente cuando el cluster sufra problemas de disponibilidad (cuando caigan otros nodos, o no sean accesibles). 
• Crear learners de solo lectura. Esto puede descargar al líder de operaciones de red sin aumentar ni complicar el consenso del cluster. 

Podéis encontrar aquí el documento de diseño de este nuevo estado learner con los escenarios que han propiciado su aparición en la v3.4 dándose todos ellos cuando se añade un nuevo nodo al cluster etcd. Las imágenes de los diferentes escenarios que explico a continuación están extraídas de este documento.

Problemas en la creación de un nodo en el cluster etcd antes de v3.4

La motivación crear este nuevo estado de nodo ha sido triple. En primer lugar, podían aparecer problemas de sobrecarga del nodo líder en el cluster cuando se unía un nuevo nodo. Cuando el líder del cluster etcd le manda toda la información del log para que se ponga al día, puede sobrecargar su red y dar problemas de timeout en el latido que manda al resto de nodos seguidores del cluster, haciendo que comience un nuevo proceso de elecciones.

En segundo lugar, podría haber problemas cuando un nuevo miembro se unía al cluster etcd cuando se producía un particionamiento de la red. Dependiendo de si el líder queda aislado y dónde se crea el nuevo nodo, puede llevar a provocar a la pérdida del quorum.

Finalmente, el caso más grave ocurre cuando un se da de alta en el cluster etcd un nuevo nodo con una configuración incorrecta. El problema es que hasta ahora las configuraciones incorrectas también cambiaban el tamaño del quorum y se podía llegar a dejar inoperativo todo el cluster etcd si se añadían nodos inaccesibles en número suficiente como para que nunca se pueda alcanzar el quorum.

Esto, puede ocurrir de manera accidental, pero puede convertirse en un ataque intencionado si se logra acceso al backend de etcd. El ataque consiste en dar de alta suficientes nodos inaccesibles como para que el cluster etcd pierda el quorum.

Riesgos de seguridad y actualización del cluster etcd a v3.4

Hay que tener en cuenta que tener un acceso inseguro al backend de la base de datos etcd es equivalente a tener acceso root a todo el cluster de Kubernetes, ya que se puede consultar y modificar el estado de los nodos, pods, autorizaciones, accesos, etc. sin tener que pasar por el servidor API de Kubernetes.

Los efectos de dejar inoperativo la base de datos etcd es que el servidor API deja de poder consultar o modificar la base de datos y por lo tanto, queda inoperativo todo el cluster de Kubernetes. Entre las medidas que hay que implementar para corregir un acceso inseguro a la base de datos etcd están:

• Despliegue del cluster etcd en nodos diferentes a los nodos master de Kubernetes. Esto evita que desde una intrusión en un nodo maestro inseguro pueda accederse directamente a la administración de la base de datos etcd.
• Uso de certificados TLS y rotación automática y periódica de lo mismos entre el servidor API de Kubernetes y la base de datos etcd.
• Uso de firewall para que sólo el servidor API de Kubernetes tenga acceso al cluster etcd.

En la página de actualización de etcd de v3.3 a v3.4 explican que ésta es una actualización que puede hacerse sin caía del servicio, siempre y cuando tengamos un despliegue de alta disponibilidad con varios nodos etcd, actualizando uno a uno cada nodo.