Un control plane para Linux hosts pasa de Python a Go en un solo binario
nkt (NetKnownsThat) se ha abierto en código tras reescribirse por completo en Go: un binario estático de 30 MB que audita configs, gestiona firewalls y centraliza flota vía Hub
El equipo de nkt (NetKnownsThat) ha abierto el código de un control plane para hosts Linux que reescribió por completo en Go después de años arrastrando un backend en Python. El resultado se despliega como un único binario estático de unos 30 MB, con versiones precompiladas para linux/amd64, linux/arm64 y linux/arm.
No es un lanzamiento nuevo, sino la evolución de una herramienta interna. nkt empezó siendo un puñado de scripts de auditoría y acabó convertido en una navaja suiza. El problema era llevarla a decenas de VPS heterogéneos, desde bare metal hasta routers ARM de gama baja. Cada servidor exigía su propio venv, la versión de Python variaba según la Ubuntu de turno, pip llegaba a romper paquetes del sistema y la librería de criptografía pedía un compilador de Rust en máquinas que no lo tenían. Empaquetar todo eso con PyInstaller daba binarios de 200 MB que reventaban con errores opacos de glibc. Sumado a un parseo que se comía la RAM, el equipo decidió reescribir. La interfaz, en React y Ant Design, se quedó; el backend y la TUI pasaron a Go.
Qué hace
nkt no se limita a listar puertos abiertos. Lee los ficheros reales de nginx, haproxy, caddy, docker-compose, ufw y firewalld y los cruza con el estado del host: salida de ss, contenedores vivos, sockets TLS. Si una config dice que el puerto 80 está abierto pero el firewall lo bloquea o el contenedor no corre, lo marca como Finding y señala fichero, línea y cómo arreglarlo.
Para editar desde la web hay rollback optimista: antes de aplicar un cambio corre nginx -t o haproxy -c, y si falla el fichero vuelve solo a la versión anterior. También avisa si estás a punto de cerrarte el acceso por SSH. Encima hay un mapa de topología que encadena red externa, servicio, listener, pool, backend y contenedor o VM, para ver dónde se rompe la cadena.
El Hub y el túnel de rescate
Con dos servidores SSH sobra. Con cincuenta hace falta un Hub central que se conecta a la flota por SSH. Al añadir un host, comprueba la arquitectura con uname, cross-compila el binario al vuelo, lo sube por SFTP y monta la unidad systemd. Desde ahí se centraliza fail2ban: si una IP ataca un nodo, se le banea en toda la flota con un clic, y el Hub se inyecta solo en la lista ignoreip para no autobloquearse.
El detalle interesante es el canal de respaldo. Si alguien bloquea el puerto 22 con ufw o sshd se cae, el Hub levanta un túnel TLS inverso separado. Con SSH muerto, el panel, la terminal web y las actualizaciones de binario siguen funcionando por ahí.
El escaneo de malware va más allá de ClamAV: busca mineros de cripto, procesos que corren desde /tmp, entradas raras en ld.so.preload y cron jobs que encadenan curl con sh. Hay binarios publicados junto a SHA256SUMS, y desde fuente basta con make, que decide si compila en Docker o en el host. El Hub se levanta con docker compose.
La pieza es de las que interesan a quien lleva flota: el salto a un binario único con cross-compilación al vuelo resuelve un problema real de despliegue, y el túnel de respaldo cubre el escenario donde normalmente pierdes la máquina. Queda por ver cómo se porta con flotas que ya viven dentro de Kubernetes y no fuera.
