# Modo privilegiado

Qué hace legible privileged=yes en el contenedor RouterOS del agente, qué deja fuera de su alcance y qué cuesta funcionar sin él.

Source: https://docs.jmrp.io/mikroscope/es/limits/privileged/

`install` crea el contenedor del agente con `privileged=yes`. El ajuste decide qué fuentes del
agente le deja leer el kernel; no abre ningún acceso a la red ni ninguna vista de los procesos de
RouterOS.

## Valor por defecto

El contenedor se ejecuta con `privileged=yes` salvo que pases `--privileged=false` a `install` o a
`upgrade`, que recrea el contenedor. Es una opción booleana, así que se escribe `=false`; un
argumento `false` separado no se lee como su valor. El ajuste necesita RouterOS 7.24 o
posterior: RouterOS añadió el modo privilegiado para contenedores en la 7.24, como recoge su
[registro de cambios](https://download.mikrotik.com/routeros/7.24/CHANGELOG).

Leer el estado interno del equipo es para lo que existe mikroscope, y privileged es lo que hace
legibles los ficheros del kernel reservados a root. Un contenedor normal de RouterOS se coloca en
un [espacio de nombres de usuario](https://man7.org/linux/man-pages/man7/user_namespaces.7.html) en el que su root corresponde al uid 32768 del host ([leído en una sola placa](https://docs.jmrp.io/mikroscope/es/about/status/#not-tested)),
así que `/proc/slabinfo` y `/dev/kmsg` devuelven `EACCES`. `privileged=yes` elimina ese espacio de
nombres de usuario.

Sigue siendo una concesión real de privilegios, y por eso `plan` e `install --dry-run` lo
muestran junto con el resto de ajustes del contenedor antes de escribir nada.

## Lo que habilita

`privileged=yes` hace legibles estas fuentes, y el agente lee cada una salvo donde la tabla indica
otra cosa:

| Fuente                             | Lo que da                                                                                                                               | Dónde aparece                                                                  |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| `/dev/kmsg`                        | el búfer circular del kernel como eventos con marca de tiempo, con los nombres reales de las interfaces del router                      | `mikroscope_kmsg_records_total{level}`, `mikroscope_kmsg_port_records_total{port,kind,level}`, y Loki |
| `/proc/slabinfo`                   | las cachés slab globales: `nf_conntrack` (el número real de conexiones del router), `skbuff_*`, sockets `TCP`/`UDP`, `kmalloc-1k`/`-2k` | `mikroscope_slab_active_objects{cache}`                                        |
| contadores ECC de `/sys/class/mtd` | `corrected_bits` y `ecc_failures` por partición NAND                                                                                    | `mikroscope_mtd_ecc_corrected_bits_total`, `mikroscope_mtd_ecc_failures_total` |
| la PMU, vía `perf_event_open`      | ciclos, instrucciones, referencias y fallos de caché, fallos de predicción de saltos, ciclos de bus, por núcleo, a nivel de sistema     | `mikroscope_perf_events_total{counter,cpu}`                                    |
| `/proc/pagetypeinfo`               | legible, pero el agente no lo lee                                                                                                       | en ningún sitio                                                                |

La PMU necesita privileged por una razón distinta a la de los ficheros: sus contadores se abren a
nivel de sistema (`pid = -1`), lo que según [`perf_event_open(2)`](https://man7.org/linux/man-pages/man2/perf_event_open.2.html) requiere
`CAP_SYS_ADMIN` frente al host, `CAP_PERFMON` en Linux 5.8 o posterior, o un `perf_event_paranoid`
menor que 1. Un contenedor privilegiado conserva `CAP_SYS_ADMIN` frente al host, así que un
`perf_event_paranoid` de 2 no lo bloquea ([medido](https://docs.jmrp.io/mikroscope/es/about/status/#reference-hardware)). Lo
que la PMU muestra y ningún contador de ticks puede mostrar está en
[Límites de resolución](https://docs.jmrp.io/mikroscope/es/limits/).

El log del kernel se lee sin bloquear y con un tope de 64 registros por tick. Se abre al final del
búfer, así que un atasco de registros del arranque nunca se reproduce como si acabara de ocurrir.
`mikroscope_kmsg_dropped_total` cuenta episodios de pérdida, no registros: uno por cada tick que
llegó al tope de 64 registros (la lectura de más de ese tick se descarta, y el resto de la cola se
lee en ticks posteriores), y uno por cada desbordamiento del búfer circular del kernel, que puede
suponer muchos registros. Mientras no sea cero, la cuenta por severidad se queda corta.

Si este despliegue las obtuvo no se deja a la deducción. `/capabilities` lleva
`"privileged": true` solo cuando se abrieron tanto `/proc/slabinfo` como `/dev/kmsg`, y
`mikroscope_device_info{privileged="true"}` dice lo mismo en `/metrics` y en el flujo de datos del
equipo de cada destino. Sin privileged, las familias de slab, PMU y MTD están ausentes, no a cero.
La familia del log del kernel solo aparece cuando se ha visto un registro, así que su ausencia por
sí sola no distingue un despliegue sin privilegios de un kernel tranquilo; el indicador
`privileged` sí.

## Lo que no habilita

No añade **ningún** acceso a la red ni **ninguna** vista de los procesos de RouterOS. Privileged
elimina el espacio de nombres de usuario y deja en su sitio los de red y de PID ([verificado](https://docs.jmrp.io/mikroscope/es/about/status/#campaign-netns-2026-09-12)).
Así que los contadores por interfaz siguen viniendo de la API de RouterOS, y la CPU por proceso
queda fuera de alcance incluso con el `/proc` del host montado en el contenedor. Ambas cosas están
en [Visibilidad del contenedor](https://docs.jmrp.io/mikroscope/es/limits/namespaces/).

Tampoco añade capacidades: un contenedor sin privilegios ya tiene el conjunto completo que define
el kernel ([leído en una sola placa](https://docs.jmrp.io/mikroscope/es/about/status/#not-tested)). Lo que cambia es el
espacio de nombres de usuario al que esas capacidades quedan confinadas, no el conjunto.

Y no puede darte más sensores de los que tiene la placa. El agente lee las zonas térmicas, que no
necesitan privileged, y nada de `/sys/class/hwmon`. En la placa medida, `hwmon` está vacío incluso
con privilegios, así que sus zonas térmicas son todo su conjunto de sensores del kernel ([medido](https://docs.jmrp.io/mikroscope/es/about/status/#reference-hardware)).
En una placa que sí tenga sensores de tensión, corriente o ventilador, la capa de la API de
RouterOS los sigue añadiendo.

## Ejecutar sin privilegios

`--privileged=false` conserva todo lo que se puede leer desde un contenedor normal: todos los
ficheros globales de `/proc` en las muestras, las zonas térmicas, `scaling_cur_freq`,
`/proc/yaffs`, `/proc/buddyinfo`, `/proc/diskstats` y el coste del propio agente. Lo que se pierde:

- El log del kernel. Un [bucle de capa 2](https://docs.jmrp.io/mikroscope/es/playbooks/loop/) puede verse solo ahí.
- El número de conexiones del router desde la caché slab. El recorrido de tabla `count-only` de
  la API de RouterOS es la fuente que queda, y el colector solo lo ejecuta cuando se indica
  `--conntrack-every`.
- Los contadores ECC de la NAND. Los contadores de desgaste de YAFFS se mantienen.
- La PMU, y con ella todo lo que queda por debajo del tick de 10 ms.

Lo que se queda callado con ellos: la sección `health` de `doctor` solo puede informar de
`softnet-drops`. Su línea `ok` no significa que no haya bucle, porque las comprobaciones de bucle,
churn de STP y flap de enlace leen el log del kernel. Las reglas de alerta `mikroscope-l2-loop` y
`mikroscope-port-link-down` (log del kernel), `mikroscope-conntrack-near-limit` (caché slab;
`--conntrack-every` alimenta otra serie que esta regla no lee) y `mikroscope-ecc-failure` (MTD) se
quedan sin datos y en OK. Comprueba `mikroscope_device_info{privileged}` antes de fiarte de su
silencio.

> **Privileged no es un montaje**
>
> Un contenedor privilegiado con el `/` del host montado lee la configuración entera de RouterOS,
> secretos incluidos ([probado](https://docs.jmrp.io/mikroscope/es/about/status/#verified-host-mounts)). El instalador no monta ninguna
> ruta del host en el contenedor del agente, y nada de lo que hay aquí la necesita.

## Véase también

- [Visibilidad del contenedor](https://docs.jmrp.io/mikroscope/es/limits/namespaces/): los dos espacios
  de nombres que privileged deja en su sitio, fichero a fichero.
- [Modelo de seguridad](https://docs.jmrp.io/mikroscope/es/security/): el contenedor del agente y lo que puede
  alcanzar, desde el lado de la seguridad.
- [Conntrack sin la API](https://docs.jmrp.io/mikroscope/es/playbooks/conntrack/): la cuenta del slab que privileged
  hace legible, y cómo comprobarla.
- [Desgaste de la flash](https://docs.jmrp.io/mikroscope/es/playbooks/flash-wear/): los contadores de YAFFS que no
  necesitan privilegios y los contadores ECC que sí.