El nuevo lanzamiento de la plataforma de contenedores Kubernetes 1.13 elimina una vulnerabilidad crítica (CVE-2018-1002105), que permite a cualquier usuario obtener un control completo sobre un grupo de contenedores aislados. El problema también se solucionó en las actualizaciones 1.10.11, 1.11.5 y 1.12.3.
En la vulnerabilidad encontrada en Kubernetes para poder realizar el ataque es suficiente enviar una solicitud especialmente diseñada a través de la API para determinar los backends disponibles (solicitud de descubrimiento).
Sobre la vulnerabilidad de Kubernetes
Debido a un error, este tipo de solicitud deja abierta la conexión de red, lo que permite utilizar el servidor API (kube-apiserver) como intermediario para enviar solicitudes a cualquier servidor utilizando la conexión establecida con el servidor API.
En consecuencia, las solicitudes reenviadas a través de dichas conexiones serán procesadas por el backend como solicitudes internas del servidor API, enviadas utilizando los parámetros de autenticación del servidor API.
De forma predeterminada, todos los usuarios de Kubernetes autenticados y no autenticados tienen la capacidad de enviar solicitudes a través de la API de descubrimiento, que son suficientes para lanzar un ataque.
Por lo tanto, cualquier usuario de Kubernetes sin privilegios que tenga acceso a la API puede obtener un control completo sobre toda la infraestructura, por ejemplo, enviando una solicitud para ejecutar su código en el host.
Además de obtener el control de la infraestructura de Kubernetes, la vulnerabilidad también puede aplicarse a ataques dirigidos a clientes a través de la manipulación de los servicios al cliente ubicados en la nube.
El problema se manifiesta en todas las versiones de Kubernetes, comenzando con la versión 1.0.
Por lo que se recomienda a todos los administradores de Kubernetes que actualicen con urgencia sus sistemas a los problemas actuales, así como que auditen los registros del sistema para detectar posibles actividades maliciosas.
Como una solución para protegerse contra ataques de usuarios no autorizados, pueden deshabilitar el acceso anónimo a la API usando la opción «–anonymous-auth = false» y revocar los derechos para realizar operaciones exec/attach/portforward.
Se señala por separado que, en los registros de Kubernetes, el ataque que utiliza solicitudes no autorizadas no se registra en absoluto, por lo tanto, fue posible determinar si el compromiso fue posible solo mediante signos indirectos.
Sobre el nuevo lanzamiento de Kubernetes 1.13 y sus novedades
En este nuevo lanzamiento de Kubernetes 1.13 la interfaz CSI (Container Storage Interface) se ha estabilizado, lo que le permite crear complementos para admitir varios sistemas de almacenamiento.
CSI proporciona una única interfaz para asignar espacio, adjuntar y montar repositorios, lo que le permite suministrar complementos para la integración con varios servicios de almacenamiento sin la necesidad de realizar cambios en la base de código de Kubernetes.
De forma predeterminada, se utiliza el servidor DNS CoreDNS.
CoreDNS está escrito en el lenguaje Go y destaca por una arquitectura flexible basada en complementos.
Por ejemplo, funciones específicas como el descubrimiento de servicios de Kubernetes, la acumulación de métricas para el sistema de monitoreo de Prometheus y la integración con el sistema de almacenamiento de configuración, etc. se implementan a través de complementos.
Kubeadm se ha estabilizado como una interfaz simplificada para administrar el clúster Kubernetes, que le permite realizar operaciones tales como crear e implementar un clúster en el equipo existente, configurar los componentes básicos de Kubernete, conectar y eliminar nodos, realizar operaciones de actualización;
Se presenta una interfaz experimental para crear complementos para la integración con sistemas de monitoreo de terceros.
El registro de complementos de dispositivos Kubelet de servicio estabilizado, que proporciona los medios para acceder a Kubelet desde complementos.
El programador de distribución de contenedores de TAVS (Topology Aware Volume Scheduling) se ha estabilizado, teniendo en cuenta la topología de las secciones del Pod (teniendo en cuenta las restricciones establecidas para los nodos y las zonas).
Pasamos a la fase de prueba beta de APIServer DryRun, al equipo de Kubectl Diff y la capacidad de usar dispositivos de bloque sin procesar como fuentes de datos persistentes (fuente de volumen persistente).
Si quieren conocer un poco más sobre este nuevo lanzamiento pueden visitar el siguiente enlace.