NetBird 0.74 en municipios: agentes, límites y logs
Mini-caso sobre NetBird Agent Network para controlar llamadas de agentes, proveedores, políticas y logs sin repartir API keys.
Una API key copiada en una notebook de soporte sobrevivió a dos proveedores y tres pruebas de automatización. NetBird 0.74.0, publicado el 1 de julio de 2026, agregó Agent Network para dar identidad, políticas, límites y logs a llamadas de agentes y personas sobre un túnel WireGuard. Este caso de industria muestra cómo revisar proveedores, presupuesto, acceso interno y respaldo antes de ponerlo en producción.
Dónde aparece la llave que nadie quiere reconocer
El problema aparece cuando un agente interno necesita consultar un proveedor de modelos y también acceder a una herramienta privada. En una municipalidad chica del Gran Mendoza, el IT manager encuentra una etiqueta adhesiva con el nombre del proveedor pegada en una notebook de soporte. El objeto parece menor, pero revela una práctica peligrosa: credenciales repartidas, sin usuario real, sin política visible y sin corte central. La API key quedó suelta. La cifra que corrige la lectura viene del repositorio oficial: netbirdio/netbird registró 26.608 estrellas al chequeo de esta corrida. El release 0.74.0 introdujo Agent Network, un gateway por cuenta para que agentes usen proveedores y recursos internos con identidad, túnel, políticas y logs. El punto operativo es simple: cada llamada debe quedar asociada a una persona, grupo o servicio. El dato global se conecta con una rutina local. La Stack Overflow Survey 2025 muestra que PostgreSQL sigue siendo una base extendida entre desarrolladores. Para un municipio, esa familiaridad ayuda a guardar auditoría propia: solicitante, proveedor, costo estimado, política aplicada y resultado.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, IT registra usuarios y grupos desde el proveedor de identidad. Segundo, NetBird crea túneles WireGuard entre equipos, servicios y gateway. Tercero, Agent Network recibe una solicitud de un agente o usuario autorizado. Cuarto, el gateway inyecta la credencial del proveedor desde el lado servidor y bloquea headers de autorización enviados por el cliente. Quinto, políticas y límites deciden qué proveedor, modelo o recurso puede usarse. Sexto, logs y métricas guardan usuario, destino, estado, consumo y error. NetBird recibe identidad, pares, grupos, políticas y rutas privadas; entrega conectividad segura y registros de acceso. Agent Network toma solicitudes de agentes, aplica política y reenvía al proveedor permitido. WireGuard cifra el transporte entre pares. PostgreSQL o la base de auditoría municipal guarda inventario de autorizaciones, tickets, costos y revisiones. El backup recupera configuración, políticas y registros necesarios para explicar una llamada. El permiso de crear proveedores queda en IT. El permiso de usar un proveedor queda en grupos concretos. El permiso de revisar consumo queda en gerencia o administración. La baja de un proveedor debe cortar túnel, política y secreto en un mismo procedimiento.
Qué se instala o configura primero
El primer entregable verificable es un laboratorio con un agente, un proveedor, dos grupos y un recurso interno de prueba. La pila mínima incluye NetBird 0.74.0, proveedor de identidad, gateway Agent Network, políticas, límites de uso, logs, backup de configuración y tablero de consumo. Una VM de 2 vCPU y 4 GB para control y gateway puede costar entre USD 35 y USD 70 por mes, entre $ 52.850 y $ 105.700 al dólar oficial vendedor de $ 1.510; quedan fuera consumo de proveedor, licencias externas y revisión legal de datos. El primer ciclo puede resolverse en dos semanas si la identidad ya existe. UMSA puede aplicarlo cuando soporte, mesa de entradas o áreas técnicas prueban agentes con datos internos y necesitan cortar credenciales rápido. La primera entrega debe mostrar una llamada permitida, una llamada rechazada, un proveedor deshabilitado y un reporte de logs. La validación de datos sensibles se define antes del piloto. El inventario mínimo lista qué datos puede leer cada agente, quién aprueba el uso y qué retención tienen los logs.
Dónde se rompe y cómo probarlo
El primer riesgo es el proveedor sin límite. La señal aparece cuando un grupo puede usar más modelos o endpoints de los aprobados. La prueba crea dos políticas, ejecuta llamadas permitidas y rechazadas, y revisa el log. El segundo riesgo es la credencial en el cliente. La señal llega cuando una API key aparece en variables locales, navegador o repositorio. La prueba busca secretos, ejecuta una llamada y verifica que el gateway agregue la credencial del lado servidor. El tercer riesgo es el corte incompleto. La señal aparece cuando se desactiva un usuario y el agente todavía puede llamar al proveedor. La prueba bloquea el usuario en identidad, espera sincronización y repite la consulta. El cuarto riesgo es el registro insuficiente. La señal llega cuando administración pregunta cuánto se usó y solo hay facturas del proveedor. La prueba compara logs de NetBird, ticket de autorización y estimación de consumo por área. El piloto sirve si deja una evidencia incómoda y útil: quién llamó, a qué proveedor, con qué política, cuánto costó y cómo se corta en cinco minutos.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.