ProxMate lleva el autoservicio a Proxmox sin entregar acceso al panel del clúster

Proxmox VE ofrece prácticamente todo lo necesario para administrar máquinas virtuales y contenedores, pero su interfaz está pensada principalmente para administradores. ProxMate propone colocar una capa de autoservicio encima del clúster, de forma que desarrolladores, alumnos o usuarios internos puedan crear y administrar sus propios recursos sin recibir acceso al panel administrativo de Proxmox. El proyecto es self-hosted, su Community Edition es de código abierto y puede desplegarse con Docker sobre Linux.

Las claves de ProxMate en 30 segundos

  • ProxMate utiliza la API de Proxmox VE para ofrecer un portal multiusuario independiente del panel administrativo.
  • Permite asignar cuotas de vCPU, RAM y almacenamiento y crear VM y contenedores LXC mediante autoservicio.
  • Incorpora consola web, snapshots, backups, firewall por VM, migraciones, monitorización y autenticación 2FA.
  • Se ejecuta en infraestructura propia mediante Docker y dispone de instalador para las principales distribuciones Linux.
  • La Community Edition utiliza AGPLv3, mientras el proyecto prepara ediciones EDU y comerciales.

Para un administrador de sistemas la propuesta resulta interesante porque ProxMate no intenta sustituir a Proxmox VE. El hipervisor continúa administrando los nodos, KVM, LXC, redes y almacenamiento. ProxMate utiliza su API para añadir una capa de usuarios, permisos y aprovisionamiento más cercana a la que se encontraría en una pequeña plataforma cloud.

La consecuencia práctica es sencilla: el equipo de sistemas continúa administrando Proxmox mientras los usuarios reciben un portal mucho más limitado desde el que consumir los recursos que previamente se les hayan asignado.

Proxmox como backend, ProxMate como portal de autoservicio

El punto de partida de ProxMate es un clúster Proxmox VE ya operativo. Sobre él proporciona una interfaz web desde la que el administrador puede crear invitaciones acompañadas de límites de CPU, memoria y almacenamiento.

Una vez registrado, cada usuario puede desplegar máquinas virtuales y contenedores LXC sin necesidad de conocer la estructura completa del clúster.

El proyecto admite diferentes métodos de creación. Puede utilizar una ISO, clonar una plantilla o recurrir a su catálogo de imágenes cloud. La documentación actual recoge 20 imágenes preparadas, 16 para x86-64 y cuatro para ARM64.

También permite introducir una clave pública SSH durante el aprovisionamiento. Esto resulta especialmente útil para entornos Linux donde el objetivo es disponer rápidamente de una VM accesible por SSH sin tener que pasar primero por una instalación interactiva.

Después del despliegue, el usuario dispone de operaciones habituales como redimensionar, renombrar, reconstruir, iniciar o detener máquinas, crear snapshots y programar horarios de encendido.

ProxMate incorpora además una consola gráfica mediante noVNC y otra de texto accesible desde el navegador, con funciones como copiar y pegar y scrollback. De esta forma, no es obligatorio publicar SSH ni otros puertos únicamente para solucionar un problema desde consola.

También existe un sistema para compartir una VM con otro usuario. Se proporcionan tres perfiles, Viewer, Operator y Manager, aunque ninguno permite eliminar, reconstruir, migrar o volver a compartir el recurso.

Para el administrador existe una vista global del clúster con utilización de CPU, memoria, almacenamiento, nodos y máquinas virtuales agrupadas por propietario.

Cómo instalar ProxMate en Linux

El proyecto proporciona un instalador que prepara las dependencias y construye el entorno Docker.

La instalación comienza descargando el script:

curl-fsSLO https://raw.githubusercontent.com/r0073d-l053r/ProxMate/main/install.sh

Antes de ejecutarlo, los desarrolladores recomiendan explícitamente revisarlo:

less install.sh

Y posteriormente:

bash install.sh

Este detalle resulta especialmente acertado para una herramienta que posteriormente almacenará credenciales con capacidad para operar sobre un clúster de virtualización.

ProxMate evita deliberadamente recomendar algo como:

curl https://servidor/install.sh | sudobash

El instalador comprueba la presencia de Docker, Docker Compose v2, Git, curl y OpenSSL y puede ofrecer la instalación de las dependencias que falten. También genera ENCRYPTION_KEY, prepara .env y construye los contenedores.

El token de Proxmox no se introduce mediante parámetros en la línea de comandos. Se proporciona posteriormente mediante el asistente web para reducir el riesgo de que termine almacenado en el historial del shell.

Para realizar el proceso de construcción se recomiendan aproximadamente 4 GB de RAM y 5 GB de almacenamiento disponible.

El instalador contempla Debian, Ubuntu, Fedora, RHEL, CentOS, Rocky Linux, openSUSE y Alpine. Para Arch Linux proporciona las instrucciones necesarias en lugar de actualizar automáticamente el sistema.

Quien prefiera realizar el despliegue manualmente puede utilizar directamente Docker Compose:

cp .env.docker.example .envopenssl rand -hex32nano .envdocker compose up -d--build

Aquí aparece uno de los detalles que conviene revisar antes de llevar ProxMate a producción.

El .env de ejemplo utiliza inicialmente proxmate.example.com dentro de su configuración de producción. Hay que sustituir ese dominio o utilizar la configuración local correspondiente. NEXT_PUBLIC_API_URL queda incorporada al frontend durante la construcción, por lo que cambiarla posteriormente requiere reconstruir su imagen.

ENCRYPTION_KEY es una clave que no conviene perder

Otro elemento importante para cualquier sysadmin es ENCRYPTION_KEY.

ProxMate utiliza esta clave para proteger secretos almacenados por la aplicación, incluidos el token de Proxmox, secretos JWT, credenciales SMTP y secretos TOTP.

Por tanto, no basta con respaldar la base de datos.

El administrador debe conservar también una copia segura de ENCRYPTION_KEY fuera del servidor. Si el host desaparece y con él se pierde la clave, disponer posteriormente de una copia de la base de datos no permitirá recuperar correctamente esos secretos.

Un gestor de contraseñas o un sistema corporativo de gestión de secretos puede servir para conservarla.

Además, la clave debe permanecer constante durante actualizaciones y reinicios.

Las actualizaciones se realizan contra versiones publicadas en lugar de seguir directamente la rama main:

./deploy/update.sh

También puede fijarse una versión determinada:

./deploy/update.sh v0.8.6

Las migraciones de base de datos se ejecutan automáticamente cuando arranca el contenedor backend. La documentación desaconseja lanzarlas manualmente.

El firewall de Proxmox forma parte del aislamiento

En una herramienta multiusuario el apartado más delicado probablemente sea la separación entre tenants.

ProxMate puede generar reglas de firewall por VM para evitar que los usuarios alcancen el host, otros invitados o determinadas redes internas. Sin embargo, existe una condición imprescindible: el firewall del clúster Proxmox tiene que estar activado para que esas reglas proporcionen el aislamiento previsto.

El propio proyecto advierte de este requisito durante la configuración.

Esto merece especial atención porque instalar el portal y crear usuarios no convierte automáticamente un clúster existente en una infraestructura multi-tenant segura. La topología de red, bridges, VLAN, firewall y permisos de Proxmox siguen siendo responsabilidad del administrador.

En escenarios que requieran un aislamiento más fuerte pueden seguir siendo necesarias VLAN independientes, bridges separados o las funciones de Software Defined Networking (SDN) disponibles en Proxmox.

Algo parecido ocurre con el token de API.

Uno de los errores de configuración documentados por ProxMate está relacionado con Privilege Separation. Proxmox crea los API tokens con esta opción habilitada y eso puede dejar al token sin los permisos esperados. El resultado resulta confuso: la prueba de conexión puede funcionar mientras la consulta de almacenamiento devuelve resultados vacíos o la creación de VM termina con un error 403.

La solución no debería consistir simplemente en proporcionar permisos ilimitados. En producción resulta preferible crear un usuario y un rol adecuados para la integración y conceder únicamente los privilegios necesarios.

2FA, passkeys, OIDC y auditoría

ProxMate incluye varias funciones interesantes para instalaciones compartidas.

El sistema admite autenticación de dos factores mediante TOTP, passkeys con WebAuthn y proveedores de identidad externos mediante OpenID Connect (OIDC). También puede exigir 2FA desde la propia invitación enviada al usuario.

Para recuperar contraseñas puede utilizar SMTP.

El acceso también puede limitarse temporalmente. Una invitación puede concederse durante un periodo determinado y, cuando termina, ProxMate suspende el acceso y detiene las VM correspondientes, pero no elimina automáticamente los recursos.

Los administradores disponen además de registro de auditoría y métricas mediante /metrics para integrarlas con Prometheus.

El sistema de monitorización proporciona información en tiempo real de CPU, memoria y red de las VM y añade funciones operativas como migración en vivo, drenaje de nodos durante tareas de mantenimiento y un balanceador de memoria inspirado en el funcionamiento de DRS.

Backups, snapshots y recuperación

ProxMate incorpora su propio sistema denominado MateStates.

Permite configurar copias programadas, políticas diferentes por VM, retención rotativa, restauraciones y snapshots rápidos. También realiza copias nocturnas de su propia base de datos hacia un directorio del host.

Aquí vuelve a ser importante distinguir entre comodidad y estrategia de backup.

La existencia de estas funciones no elimina la necesidad de diseñar copias externas, comprobar restauraciones y mantener fuera del host tanto la información necesaria como ENCRYPTION_KEY.

Para un homelab puede ser suficiente una configuración sencilla. En producción deberían seguir aplicándose las mismas prácticas utilizadas con cualquier infraestructura de virtualización.

Un IDE y agentes de IA dentro de las propias VM

Una de las funciones más curiosas es ProxMate IDE, todavía etiquetada como beta.

Permite ejecutar code-server, la versión web basada en VS Code, dentro de la VM del propio usuario. El proyecto añade además OpenCode como agente de programación y permite que el administrador determine los modelos disponibles.

El planteamiento mantiene el entorno de desarrollo dentro de la máquina asignada al tenant en lugar de convertir el propio servidor ProxMate en una estación compartida de ejecución.

También existe un procedimiento de instalación asistida mediante agentes.

El repositorio contiene DEPLOY_WITH_CLAUDE.md, preparado para proporcionarlo a Claude Code y pedir al agente que siga el proceso de despliegue. El runbook contempla HTTPS, creación del token de API, aislamiento de tenants y configuración inicial, solicitando confirmación antes de realizar determinados cambios sobre producción.

Para un administrador experimentado probablemente resulte más interesante como ejemplo de infraestructura administrada mediante agentes que como sustituto de revisar manualmente qué modificaciones se aplicarán al sistema.

ProxMate todavía es un proyecto joven y conviene tratarlo como tal antes de situarlo delante de infraestructura crítica. Aun así, aborda un problema bastante reconocible para quienes administran Proxmox: permitir que otras personas utilicen el clúster sin convertirlas en administradores del clúster.

Para laboratorios Linux, homelabs, universidades, equipos de desarrollo o infraestructuras internas pequeñas, esa capa intermedia puede ahorrar bastante trabajo manual. El administrador mantiene Proxmox debajo; los usuarios reciben arriba algo mucho más parecido a un pequeño portal cloud.

Preguntas frecuentes

¿ProxMate sustituye al panel de Proxmox VE?

No. ProxMate utiliza Proxmox VE como plataforma de virtualización y consume su API. Su función es proporcionar una interfaz de autoservicio y multiusuario sin entregar acceso administrativo completo al clúster.

¿En qué distribuciones Linux puede instalarse ProxMate?

El instalador contempla Debian, Ubuntu, Fedora, RHEL, CentOS, Rocky Linux, openSUSE y Alpine, además de instrucciones específicas para Arch Linux. El despliegue utiliza Docker y Docker Compose.

¿Es necesario activar el firewall de Proxmox?

Sí para obtener el modelo de aislamiento por VM previsto por ProxMate. La instalación de la aplicación por sí sola no sustituye una configuración adecuada de firewall, redes, VLAN o SDN.

¿ProxMate es software libre?

La Community Edition está disponible bajo GNU Affero General Public License v3.0 (AGPLv3). El proyecto sigue un modelo open core y contempla también ediciones EDU y comerciales.

Suscríbete al boletín SysAdmin

Este es tu recurso para las últimas noticias y consejos sobre administración de sistemas, Linux, Windows, cloud computing, seguridad de la nube, etc. Lo enviamos 2 días a la semana.

¡Apúntate a nuestro newsletter!


– patrocinadores –

Noticias destacadas

– patrocinadores –

¡SUSCRÍBETE AL BOLETÍN
DE LOS SYSADMINS!

Scroll al inicio
×