Qué ha cambiado

Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.

Versión 1 → 2

Corrección menor

3 lecciones actualizadas

Correcciones menores como erratas o traducciones. No se notifica a los estudiantes.

El aislamiento entre clientes empieza con una pregunta: ¿a qué tenant pertenece esta petición? ### Monopam Desde v2026.09 Monopam obtiene el tenant **solo del nombre de host y el puerto de la petición**. Cada tenant tiene sus nombres de host; una dirección que no es host de ningún tenant no llega a ningún tenant. No se tiene en cuenta una cabecera de tenant enviada por el cliente. Una sesión iniciada queda ligada al tenant para el que se emitió. Usada contra la dirección de otro tenant se rechaza (HTTP 401) y la persona es enviada al cierre de sesión. Una sesión no puede actuar en varios tenants. ### Monosign Monosign mantiene todos los tenants en una base de datos y filtra por tenant cada tabla de ámbito de tenant. Determina el tenant en este orden: una cabecera de tenant indicada por quien llama a la API, después el nombre de host y el puerto, después el tenant predeterminado activo. Los navegadores se resuelven por host. ::diagram msp-tenant-resolution ### Qué significa para su diseño - Dé a cada cliente su propio nombre de host, en ambos productos. Host y puerto deben ser únicos entre todos los tenants. - Delante de Monopam, su proxy debe pasar la cabecera `Host` original y `X-Forwarded-Proto`. Una instalación responde 404 en todas las páginas para un host que no conoce. - No planifique una dirección compartida con selector de cliente. En Monopam no existe. > Nota: Tras actualizar a Monopam v2026.09 todos los usuarios inician sesión una vez más, porque las claves de las cookies pasaron a la base de datos.

Repartir tenants entre servidores de aplicación

Una instalación de Monopam significa una base de datos de instalación, un Redis y una clave de Vault. Puede funcionar en varios servidores de aplicación. Dos ajustes de entorno en cada servidor deciden su parte: - `MONOPAM_SERVED_TENANTS`: los tenants a los que responde este servidor. Las direcciones de otros tenants reciben la página de tenant no encontrado. - `MONOPAM_JOB_TENANTS`: los tenants para los que este servidor ejecuta trabajos en segundo plano (rotación, descubrimiento, sincronización de usuarios, trabajos de certificados, alertas). ``` # servidor principal: responde a todos los tenants, ejecuta solo sus trabajos MONOPAM_SERVED_TENANTS=* MONOPAM_JOB_TENANTS=default # servidor de cliente: responde y ejecuta trabajos para un tenant MONOPAM_SERVED_TENANTS=tenant-a MONOPAM_JOB_TENANTS=tenant-a ``` Sin ninguno de los dos ajustes, un único servidor atiende a todos los tenants y ejecuta todos los trabajos. ::diagram msp-app-servers ### Reglas para el plan - **Cada nombre de tenant aparece en la lista de trabajos de un solo servidor.** Un tenant listado en dos servidores recibe sus rotaciones, alertas y sincronizaciones dos veces. - Sobre una base de datos nueva arranca primero el servidor principal; es el que crea el tenant predeterminado. - Un servidor que atiende a un tenant con base de datos dedicada necesita acceso de red a esa base de datos y a la de la instalación. - A un tenant dedicado lo atiende mejor su propio servidor de aplicación. ### Lo que un servidor no aísla Dentro de un bucle de trabajos, un tenant que falla detiene ese bucle en esa vuelta; primero se ejecutan los tenants compartidos y después los dedicados. Por eso una base de datos dedicada caída no retiene a los tenants de la base de datos de la instalación.

La instalación propia del cliente: tenants remotos

Algunos clientes no colocan sus datos privilegiados en el entorno de un proveedor. Un **tenant remoto** les permite operar Monopam ellos mismos y seguir siendo su cliente gestionado. ### Cómo funciona el enlace 1. Usted crea el tenant remoto y obtiene un código de inscripción de un solo uso, válido 24 horas y mostrado una vez. 2. El cliente inscribe su instalación con la dirección de usted y el código. Crea sus propias claves; las claves privadas nunca salen de ella. 3. La instalación del cliente mantiene **un único WebSocket saliente** hacia usted. Usted nunca se conecta al cliente y el cliente no necesita ninguna regla de entrada. Cada mensaje va firmado y es de un solo uso. Puede entregar al cliente archivos de despliegue listos (Docker Compose, Kubernetes u OpenShift). Sus secretos se generan en sus propias máquinas; nada sobre su base de datos se guarda en el lado de usted. ### Quién decide qué - Usted **propone** quiénes de su equipo pueden entrar, con un rol. - El cliente **aprueba a cada persona** y elige las políticas que deciden lo que ve. Cualquier cambio de usted vuelve a pedir aprobación. - **Disconnect Provider** es el interruptor del cliente: sus sesiones terminan en segundos y nadie de su equipo puede entrar hasta que el cliente reconecte. - **Offline tolerance** (1 hora, 4 horas, 24 horas por defecto o 7 días) fija cuánto tiempo sigue funcionando su acceso sin una nueva sincronización. ::diagram msp-remote-tenant-link ### Lo que usted no puede hacer - Gestionar los hosts, usuarios, preparación inicial o ajustes del tenant remoto, ni ver sus políticas. - Usar accesos de grupo o elegir usted las políticas. - Llegar a la dirección web del cliente a través del enlace. Su personal usa la vía que el cliente le dé, por ejemplo una VPN. > Advertencia: Emitir un nuevo código de inscripción corta definitivamente la instalación enlazada; tendrá que inscribirse de nuevo.