# Usuario de la API Crea el usuario dedicado de RouterOS con el que entra el colector, con la política que necesita cada orden, y consulta lo que esa política le deja leer. Source: https://docs.jmrp.io/mikroscope/es/security/api-user/ 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](https://docs.jmrp.io/mikroscope/es/about/status/#verified-test-policy)). 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](https://docs.jmrp.io/mikroscope/es/sinks/api-tier/). 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 : …`. ## 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](https://help.mikrotik.com/docs/spaces/ROS/pages/8978504/User): ```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: ```routeros /user/add name=mikroscope group=mikroscope password= address=/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](https://docs.jmrp.io/mikroscope/es/security/api-user/#cómo-se-lo-pasa-la-cli). 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](https://docs.jmrp.io/mikroscope/es/about/status/#verified-read-user-envlist)). Si puede leer también los valores de las entradas de la envlist en `/container/envs` está [sin probar](https://docs.jmrp.io/mikroscope/es/about/status/#not-tested); 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`](https://github.com/jmrplens/mikroscope/blob/main/.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](https://docs.jmrp.io/mikroscope/es/security/): cada pieza, a qué llega y qué credencial guarda. - [Capa de la API de RouterOS](https://docs.jmrp.io/mikroscope/es/sinks/api-tier/): lo que lee el colector con este usuario, y los perfiles `off`, `slow` y `full`. - [Acceso por red](https://docs.jmrp.io/mikroscope/es/install/reaching-the-agent/): los transportes directo y relay, y cuándo necesita `test` el relay.