Usuario de la API

El agente no necesita cuenta en RouterOS. Tres cosas de tu máquina sí: la capa de la API del colector, el transporte relay y los marcadores en el log del router. Dales un único usuario dedicado con read y api, más test si usas el relay.

Políticas necesarias

Lo usa	Ejecuta por la API binaria	Política
la capa de la API de forward	/interface/monitor-traffic, /interface/print (name, default-name, type, comment, actual-mtu), /interface/list/member/print (list, interface), /interface/bridge/port/print (interface, bridge), /interface/print stats-detail, /interface/ethernet/print stats, /system/resource/print, /system/resource/cpu/print, /system/health/print, /ip/firewall/connection/print count-only, y una vez por reinicio /log/print (topics, message, el buffer de memoria)	read,api
record --log-markers, mark --log-markers	/log/print (time, topics, message)	read,api
el transporte relay (--transport relay, o auto cuando el directo no responde)	/tool/fetch output=user contra la dirección del agente	read,api,test

/tool fetch y /tool profile exigen ambos la política test (verificado). mikroscope usa /tool fetch para el relay y no usa /tool profile.

read,api basta para la capa de la API y para --log-markers. test solo hace falta cuando se usa el relay — --transport relay, o auto cuando el transporte directo no responde — sea cual sea --api-mode. Con --api-mode off la capa no necesita ningún usuario.

No todas las llamadas de la primera fila se ejecutan siempre. /system/health/print se omite en slow y con --no-health; el count-only de conntrack solo se ejecuta cuando --conntrack-every es mayor que 0, y su valor por defecto es 0 incluso en full; monitor-traffic solo se ejecuta cuando se da --interfaces, mientras que las tres lecturas de configuración del inventario de interfaces se ejecutan siempre que la capa esté encendida, una vez antes de la primera extracción del kernel y de nuevo cada --labels-every; las dos lecturas de stats siguen a --counters-every, 10 s por defecto. Qué llamadas se ejecutan y con qué cadencia está en Capa de la API de RouterOS.

Sin dirección y usuario, cada orden lo dice de una manera distinta:

• forward funciona solo con la capa del kernel. Con una dirección que no responde registra api tier: not connected yet, will keep trying: … y sigue reintentando.
• mark --log-markers y --transport relay fallan con the RouterOS API needs --api, --api-user and MIKROSCOPE_API_PASSWORD.
• record --log-markers conserva la grabación, imprime log markers: the RouterOS API needs … en stderr y sale con 0.
• --transport auto, cuando el transporte directo no responde, falla con direct transport did not answer and the relay is not configured: the RouterOS API needs … (or `install --expose`).

Esa comprobación solo mira --api y --api-user. Un MIKROSCOPE_API_PASSWORD vacío no se detecta ahí; aparece como un inicio de sesión fallido, api <dirección>: ….

Crear el usuario

1. Crea un grupo que conceda read, api y test y niegue por su nombre todas las demás políticas que define RouterOS:

   /user/group/add name=mikroscope policy=read,api,test,!write,!ftp,!local,!telnet,!ssh,!reboot,!policy,!winbox,!password,!web,!sniff,!sensitive,!romon,!rest-api

   Quita test de la lista si nunca vas a usar el relay.

2. Crea el usuario en ese grupo, restringido a la dirección del colector:

   /user/add name=mikroscope group=mikroscope password=<generate> address=<collector host>/32

3. Restringe /ip/service para api a tu LAN. Junto con address= en el usuario, las dos son limitaciones del lado de RouterOS sobre desde dónde se acepta la contraseña, y ninguna depende de mikroscope.

4. Pasa la dirección, el usuario y la contraseña a la CLI, como en Pasar las credenciales.

Crea este usuario para mikroscope en vez de reutilizar uno hecho para otra herramienta. Un usuario de la API de mínimo privilegio creado para otra cosa suele pertenecer a un grupo que niega test, así que no puede ejecutar el relay, y ampliar ese grupo lo amplía también para la otra herramienta.

Lo que ve read

read no es estrecha. Por la API binaria, /container/print devuelve todas las propiedades de todos los contenedores, cmd y envlist incluidas, a un usuario con solo read,api (verificado). Si puede leer también los valores de las entradas de la envlist en /container/envs está sin probar; el diseño supone que este usuario puede, y por eso trata la entrada TOKEN del agente, cuando hay una, como legible por él.

El colector acota lo que pide allí donde lee configuración. Las tres lecturas del inventario de interfaces nombran sus propiedades — name, default-name, type, comment y actual-mtu; list e interface; interface y bridge — y ningún otro campo, así que ninguna se trae un campo que pudiera llevar un secreto; /system/resource, /system/resource/cpu, /system/health y /log/print llevan también un .proplist. Las lecturas de contadores — monitor-traffic, stats, stats-detail — y el count-only de conntrack no. Nada de esto limita lo que el usuario tiene permitido pedir: sigue pudiendo pedir todas las propiedades de todos los contenedores.

Pasar las credenciales

Ajuste	Opción	Variable de entorno
dirección	--api	MIKROSCOPE_API_ADDR
usuario	--api-user	MIKROSCOPE_API_USER
contraseña	ninguna	MIKROSCOPE_API_PASSWORD

La contraseña no tiene opción a propósito: una opción se ve en ps y en el historial de la shell. El .env.example del repositorio da la dirección como 192.168.88.1:8728.

La conexión con la API no va cifrada

record, mark y forward se conectan a la API binaria sin cifrar. El cliente incluido en el repositorio puede usar TLS, pero ninguna opción lo activa, así que el inicio de sesión y cada respuesta cruzan sin cifrar la red entre el colector y el router. address= limita desde dónde se acepta el inicio de sesión; eso no lo cambia.

Véase también

• Modelo de seguridad: cada pieza, a qué llega y qué credencial guarda.
• Capa de la API de RouterOS: lo que lee el colector con este usuario, y los perfiles off, slow y full.
• Acceso por red: los transportes directo y relay, y cuándo necesita test el relay.