Fija OpenZiti en la v2.0.6 o posterior dentro de la línea 2.0, y no trates una etiqueta de prelanzamiento como la versión fijada para el cliente

Fija OpenZiti en la v2.0.6 o posterior dentro de la línea 2.0, y no trates una etiqueta de prelanzamiento como la versión fijada para el cliente

La frase que oye un MSP es: «tenemos un overlay zero trust, así que la red plana ha desaparecido». La respuesta es que el overlay es un plano de control que igualmente hay que inventariar, fijar a una versión y blindar. No es un eslogan que jubile las ventanas de cambio. El proyecto del que hablamos es OpenZiti, repositorio openziti/ziti, con licencia Apache-2.0, 4417 estrellas y 276 forks en GitHub a 4 de octubre de 2026 y página principal en openziti.io. Son recuentos, no una afirmación de popularidad que vaya más allá de la cifra.

La versión fijada va en la misma frase. La versión completa más reciente de la línea 2.0 es la v2.0.6, publicada el 18 de septiembre de 2026. También existen la v2.0.7 (25 de septiembre) y la v2.0.8 (8 de octubre), y ambas siguen marcadas como prelanzamientos.

A continuación: qué puede significar «overlay zero trust programable», es decir, servicios enrutados por identidad, un controlador, routers de borde e identidades inscritas. Y qué no es OpenZiti, frente a otros seis productos que resuelven trabajos distintos. El consejo de mantenimiento se detiene en «aplicar una versión fijada», y los seis controles defensivos no añaden detalles de ataque.

La frase sobre funcionalidades que usa este artículo sale de la descripción del repositorio y de nada más: el proyecto principal de OpenZiti distribuye los ejecutables de una red programable y totalmente zero trust. Entre los temas del repositorio están overlay, zero-trust y ZTNA, la rama por defecto es main y el lenguaje principal es Go. Aquí no se vende como hecho ninguna topología de alta disponibilidad, ninguna cifra de rendimiento ni ningún número de clientes. El diagrama de cómo un cliente conectó sus controladores es el registro de diseño de ese cliente, no una afirmación que esta página pueda sacar de un recuento de estrellas.

Los objetos que un MSP sigue teniendo que nombrar son controladores, routers de borde e identidades inscritas, incluida una malla de controladores HA si el cliente la tiene. Son nombres para una exportación de inventario. No son una guía de instalación, ni una topología para copiar, ni la promesa de que todos los entornos tengan la malla. Si el cliente no tiene un segundo controlador, el inventario lo dice. Una fila HA vacía es un hecho. Un segundo controlador supuesto, no.

«Enrutado por identidad» es la frase para el comprador, y es estrecha. A un servicio se llega mediante una identidad inscrita y una política, no porque el host esté en la LAN del cliente. Esa es la diferencia que un overlay puede reivindicar aquí. No es una afirmación de que los errores de configuración sean imposibles. Una política demasiado amplia, una identidad que nunca se revocó o un router administrado donde no debería siguen siendo fallos operativos corrientes. El overlay cambia la pregunta de «qué subred» a «qué identidad y qué política». No elimina la pregunta.

Las estrellas son un recuento, y ahí se acaba. Las 4417 estrellas del 4 de octubre de 2026 no son una evaluación de seguridad, ni un contrato de soporte, ni una versión fijada. El repositorio recibe push con frecuencia; el último antes de este artículo fue el 8 de octubre de 2026. Eso dice que el proyecto se mueve. No dice qué etiqueta debe ejecutar un cliente.

La licencia es Apache-2.0, según indica GitHub. Una licencia informa al comprador sobre las condiciones de derechos de autor. No le dice qué versión es segura para una ventana de cambio, y no sustituye a la versión fijada.

La página de versiones se lee mejor como una lista breve que como una hoja de cálculo de digests. La v2.0.6 (18 de septiembre de 2026) es una versión completa. La v2.0.7 (25 de septiembre) y la v2.0.8 (8 de octubre) son prelanzamientos. La v1.6.21 (18 de septiembre) y la v1.5.18 (22 de septiembre) son versiones completas de las líneas antiguas, y la v2.0.5 (15 de septiembre) es la versión completa anterior de la 2.0. Cada etiqueta se queda dentro de su línea. Una etiqueta 1.6 no pasa a ser «más nueva que la 2.0» porque se publicara más tarde ese día, y una etiqueta 2.0 no cierra una línea de mantenimiento 1.5 por el mero hecho de existir.

La regla de fijación es una frase que un MSP puede repetir. En la línea 2.0, no bajar de la v2.0.6, no ejecutar un latest flotante y no promover la v2.0.7 ni la v2.0.8 mientras estén marcadas como prelanzamientos. Un cliente que sigue en 1.6 se queda en una etiqueta 1.6 revisada (la más reciente es la v1.6.21) hasta una migración planificada, no porque exista una etiqueta 2.0. «Coge la última y ya» entre 1.5, 1.6 y 2.0 es la instrucción que este artículo rechaza. Las líneas de mantenimiento existen para que una migración planificada sea una migración, con un ticket, y no un accidente del orden de clasificación.

Las notas de versión de la v2.0.6, la v2.0.7 y la v2.0.8 describen correcciones de errores y actualizaciones o backports de componentes. El mensaje de seguridad es breve: el proyecto publica correcciones y el MSP aplica una versión fijada tras una ventana de cambio. Quien quiera la lista de incidencias puede abrir la página de versiones.

Versiones anteriores de 2026, en agosto, también incluían correcciones de seguridad en el controlador y en los routers, con los avisos enumerados en sus notas de versión. El consejo práctico no cambia: fijar una versión actual y revisada, y tratar un aviso de seguridad como un motivo para actualizar según lo planificado.

Headscale es un servidor de coordinación para otra familia de overlays. Este artículo no compara listas de funcionalidades con él. Mezclar ambos en una sola historia de bastionado ocultaría de qué plano de control trata realmente el ticket.

Linkerd2 es un service mesh con plano de datos basado en proxies. OpenZiti, tal como se trata aquí, es un overlay de identidad. Este no es un artículo sobre sidecars de malla, y una política de sidecar no es la versión fijada de un controlador de overlay. Un MSP puede usar ambos. Usar ambos no es lo mismo que decir «uno sustituye al otro».

Tetragon es aplicación de políticas en tiempo de ejecución y observabilidad, en otro proyecto. No es esta versión fijada. Un sensor que vigila un nodo no elige la etiqueta de OpenZiti, y una etiqueta de OpenZiti no se convierte en política de ejecución porque ambas palabras puedan aparecer en la misma diapositiva de arquitectura.

Gatekeeper y Kyverno son admisión de políticas de clúster. Un overlay zero trust no sustituye a una política de admisión de Kubernetes, y una política de admisión no fija la versión de un overlay. Los objetos son distintos: uno admite o deniega solicitudes de API en un clúster, el otro enruta identidades inscritas hacia servicios. Tratarlos como sustitutos es la forma en que una ventana de cambio pierde a la vez la etiqueta del overlay y las restricciones de admisión.

Trivy, Prowler, Grype y Syft son escáneres y herramientas SBOM. Un hallazgo de escaneo no es una decisión de versión para un overlay, y este artículo no toma prestadas sus versiones para adornar la fijación de OpenZiti.

Un MSP puede usar varios. El error del comprador es tratarlos como sustitutos. El trabajo de este artículo es la versión fijada de OpenZiti y la higiene de ese plano de control, nada más. Si el título del ticket pudiera cambiarse por Headscale, Linkerd2, Tetragon, Gatekeeper, Kyverno o Trivy sin cambiar los pasos, el ticket no trata de esta fijación.

Cada uno de los seis controles siguientes tiene pruebas que cuentan y pruebas que no. Un recuento de estrellas, un eslogan de marketing que dice «zero trust» y un digest latest flotante no son prueba de ninguno.

Primero, inventariar controladores, routers de borde e identidades inscritas, incluidos los miembros de un clúster de controladores HA si existen. La prueba es una exportación de inventario que nombra esos objetos e indica si existe un segundo controlador. Una diapositiva que dice «overlay desplegado» no es esa exportación.

Segundo, fijar una línea conocida después de la ventana de cambio. En la línea 2.0, el mínimo es la v2.0.6. Los prelanzamientos como la v2.0.7 y la v2.0.8 quedan fuera de ese ticket salvo que el cliente acepte expresamente un prelanzamiento, por escrito, en ese ticket. La prueba es la cadena de la etiqueta en el registro de cambio, no un digest que alguien descargó la mañana de la ventana porque aparecía el primero.

Tercero, exigir MFA de administrador en las identidades del controlador y de la consola de administración, revocar inscripciones obsoletas y mantener el mínimo privilegio en las políticas de identidad y de servicio. La prueba es una configuración de MFA en esas identidades de administración y un registro de revocación de las inscripciones que ya no tienen responsable.

Cuarto, acceder al plano de gestión solo desde redes de administración de confianza o hosts de salto. La exposición pública de la administración o de la inscripción no es un valor por defecto. La prueba es una lista de permitidos, o una regla equivalente de host de salto, adjunta al ticket. Un diagrama de cortafuegos sin identificadores de reglas es un dibujo.

Quinto, hacer simulacros de copia de seguridad y restauración del modelo de datos del controlador y del material de inscripción. Reconstruir desde soportes de confianza y rotar las identidades tras una sospecha de compromiso. La prueba es el acta del simulacro de restauración: la fecha, quién lo hizo y si la restauración produjo un controlador que el inventario sigue reconociendo.

Sexto, enviar los registros de auditoría a un SIEM. Tratar las inscripciones inesperadas, las retiradas de MFA de administrador y la inestabilidad de los enlaces de los routers como señales operativas que vigilar. La prueba es el nombre de la consulta en el SIEM y un responsable que la revisa. Un bucket de registros que nadie abre es almacenamiento, no vigilancia.

La frase que el equipo de cambios puede repetir: no confundir «hemos desplegado un overlay» con «el plano de control está fijado y blindado». El despliegue es el comienzo del inventario. La fijación y el blindaje son tickets posteriores, y tienen que nombrar una línea.

En resumen: OpenZiti (openziti/ziti) tiene licencia Apache-2.0 y contaba con 4417 estrellas en GitHub a 4 de octubre de 2026. Su versión mínima en la línea 2.0 es la v2.0.6, publicada el 18 de septiembre de 2026, mientras que la v2.0.7 y la v2.0.8 siguen siendo prelanzamientos. La página principal es openziti.io.

OpenZiti no es Headscale, ni Linkerd2, ni Tetragon, ni Gatekeeper, ni Kyverno, ni Trivy. Fija la línea, blinda el plano de control y guarda las pruebas en el ticket.