Cómo convertir un solo nodo de Proxmox en una nube multinquilino de autoservicio

Hay un momento muy concreto al que toda pequeña infraestructura llega tarde o temprano.

Ocurre cuando un nodo de Proxmox se convierte en el nodo de Proxmox de la empresa.

Empieza de forma inocua, con una máquina potente, núcleos de sobra, muchísima RAM y un par de VM para servicios internos. Quizá un entorno de pruebas. Luego otro equipo pide «solo una VM» y poco después arranca otro proyecto. De repente ese único nodo aloja la mitad del entorno de desarrollo de la empresa, y todo el mundo quiere acceso.

Ahí es donde la situación suele ponerse incómoda.

Proxmox, por defecto, es muy tajante con respecto a quién manda. O eres root o básicamente eres un espectador. Y en cuanto concedes acceso real a alguien en la GUI, puede verlo todo: las VM de otros equipos, el almacenamiento, los objetos de red y el árbol completo del Datacenter. El radio de impacto resulta evidente.

Por eso se suele recurrir a malos compromisos:

• Repartir accesos de root porque «total, es interno».
• Recurrir a la virtualización anidada para simular aislamiento.
• Levantar hosts independientes para cada equipo y ver cómo el aprovechamiento se desploma.
• O cerrarlo todo bajo llave y convertirse en una API humana para peticiones de encendido, apagado o snapshots.

Una guía reciente de la comunidad de Proxmox muestra que existe una opción mejor, una alternativa que parece obvia a posteriori pero que se aprovecha sorprendentemente poco.

El resultado es un nodo físico de Proxmox dividido en laboratorios aislados por proyecto, donde los equipos gestionan sus propias VM mediante la GUI de Proxmox sin recibir permisos de root y sin ver nada que no les pertenezca. No hay magia ni forks de por medio: solo SDN, RBAC y algo de método.

La idea central: tratar los proyectos como inquilinos (sin pretender ser una nube pública)

El montaje arranca con un simple cambio de perspectiva. Los «inquilinos» en este caso son equipos de proyectos internos, pruebas de concepto, grupos de formación o entornos efímeros, y no clientes desconocidos de alojamiento web. Son personas que necesitan autonomía, pero no soberanía sobre el sistema.

Por ejemplo:

• Equipos de desarrollo dentro de una empresa de software pequeña
• Laboratorios de pruebas gestionados por un MSP
• Entornos para cursos o talleres formativos
• Laboratorios de seguridad con separación estricta

En todos esos escenarios, entregar a cada equipo un servidor dedicado con acceso root es un despilfarro, y conceder permisos de root a todos en una máquina compartida es una temeridad.

En su lugar, este método construye el aislamiento de cada proyecto en torno a dos ejes:

• Aislamiento de red: cada proyecto habita en su propia zona SDN y su respectiva VNet
• Aislamiento en la GUI: RBAC garantiza que los usuarios solo vean y controlen sus propios recursos

Ambos principios se aplican directamente dentro de Proxmox.

Construir la ilusión: un solo nodo, muchos mundos invisibles

En el centro de esta configuración se encuentra un único nodo de Proxmox VE que ejecuta varios «laboratorios de proyecto» totalmente aislados.

Cada proyecto recibe:

• Su propia zona SDN (devpj01, devpj02, etc.)
• Su propia VNet dentro de esa zona
• Su propio punto de entrada por VPN
• Su propio pool de recursos en Proxmox

La capa SDN garantiza que el tráfico no pueda cruzar los límites del proyecto. Los usuarios conectados por VPN aterrizan directamente dentro de la VNet de su proyecto y nada más, sin artificios de enrutamiento ni malabares de firewall posteriores.

Aquí es donde destaca la SDN de Proxmox. Con las zonas y las VNet, el aislamiento queda integrado en el propio diseño de red en vez de depender de buenas intenciones.

Sin embargo, el aislamiento de red por sí solo no resuelve el factor humano. Los usuarios no solo quieren conectividad: también necesitan botones donde hacer clic.

Convertir la GUI de Proxmox en un portal de autoservicio

La pregunta audaz que responde este montaje es si puedes permitir que los usuarios de VPN inicien sesión en la GUI de Proxmox sin arrepentirte al día siguiente.

La respuesta resulta ser un sí rotundo, pero solo si aprovechas el RBAC de Proxmox del modo para el que fue diseñado. El secreto reside en los pools.

Cada proyecto cuenta con su propio pool:

• pj01
• pj02
• etcétera

A continuación:

• Se crea un grupo por cada proyecto (Pj01Admins)
• Se añaden los usuarios a ese grupo
• Se asigna al grupo un rol únicamente sobre el pool, nunca sobre el Datacenter ni sobre el nodo

Ese rol es PVEAdmin. Suena arriesgado hasta que comprendes que el alcance importa más que el rol. PVEAdmin dentro de un pool permite:

• Iniciar y apagar VM
• Abrir consolas
• Modificar ajustes de las VM
• Tomar snapshots
• Ejecutar backups
• Crear y eliminar VM

Todo eso aplica exclusivamente a los recursos que residen dentro de ese pool. Fuera de él, los demás objetos son completamente invisibles para ellos.

Cuando un administrador de proyecto inicia sesión, el árbol de Proxmox se reduce a una vista despejada y ordenada:

• Sin panel general del Datacenter
• Sin rastro de otros proyectos
• Sin ajustes globales del clúster
• Solo su pool, sus VM y el almacenamiento asignado explícitamente

Da la sensación de ser una instancia dedicada de Proxmox, sin serlo en realidad.

El almacenamiento y las formas sutiles en que RBAC puede fallar

Aquí es donde la mayoría de las pruebas con RBAC tropiezan sin previo aviso.

Si no añades de forma explícita el almacenamiento al pool, la creación de VM fallará de forma desconcertante. Te quedas sin discos, sin ISOs, sin almacenamiento EFI y con una ristra de errores.

La solución es sencilla aunque poco evidente:

• El almacenamiento de disco para las VM debe añadirse al pool
• El almacenamiento de imágenes ISO debe añadirse
• El almacenamiento ligado al arranque y a EFI debe añadirse

Solo entonces se sostiene el aislamiento. Una vez completado este paso, los administradores de proyecto pueden crear VM de principio a fin sin tocar ningún ajuste global.

Permisos de SDN: el detalle crítico

La selección de red al crear una VM es el punto más delicado. Si olvidas los permisos de SDN, los usuarios chocarán contra un muro al intentar asociar una interfaz de red. Si los configuras mal, podrían acceder a las redes de otros proyectos.

La solución más limpia pasa por definir zonas SDN individuales por proyecto. Cada proyecto cuenta con su propia zona, y al grupo de administradores del proyecto solo se le otorgan permisos sobre ella. De ese modo:

• Pueden conectar interfaces de red a su propia VNet
• No pueden ver ni modificar las VNet de otros proyectos
• No pueden crear nuevas zonas ni VNet a nivel global

Existe un método alternativo para entornos que ya emplean una zona compartida, consistente en asignar permisos directamente sobre rutas de VNet ocultas. Aun así, la dirección idónea es clara: las zonas dedicadas por proyecto escalan mejor y son más seguras ante errores.

Esta es la pieza que transforma una demostración curiosa en un entorno multinquilino de verdad.

Acceso por VPN sin abrir el entorno al mundo

Por último, el acceso. Los usuarios de la VPN solo tienen permitido alcanzar la GUI de Proxmox a través de la IP de la puerta de enlace SDN de su proyecto, en el puerto 8006. Las reglas de firewall unen todas las piezas mediante conjuntos de IP (ipsets), de modo que el acceso queda restringido tanto por red como por identidad.

No hace falta exponer la GUI a internet, ni hacen falta servidores de salto o túneles SSH frágiles. Te conectas a la VPN, abres el navegador y Proxmox aparece delante, pero solo con tu parcela correspondiente.

Transmite una sensación de modernidad que no siempre se le reconoce a Proxmox.

Lo que esto todavía no resuelve (y por qué no pasa nada)

Este esquema es potente, pero no busca fingir que es AWS.

No existen cuotas estrictas de CPU, RAM ni recuento de VM. Los identificadores VMID son globales. Las convenciones de nombres siguen dependiendo de la disciplina del equipo, y el acceso a la GUI por usuario individual resulta complejo sin IPs de VPN estáticas.

Para el público al que va dirigido, nada de eso supone un obstáculo grave, porque lo que ganas es claridad operativa:

• Los responsables de infraestructura conservan root y el control del Datacenter
• Los equipos de proyecto obtienen autonomía
• El aislamiento se impone por diseño y no por confianza
• El aprovechamiento del hardware se mantiene alto

Muchas organizaciones pequeñas nunca se percatan de que este punto de equilibrio está a su alcance.

Una perspectiva más amplia

Lo más llamativo de este patrón es la poca complejidad a medida que requiere. No hay parches, planos de control externos ni apaños que se desmoronen con las actualizaciones. Solo utiliza Proxmox tal y como fue diseñado, aplicando pools, RBAC y SDN con coherencia.

También recuerda que el modelo multinquilino no tiene por qué reservarse a las grandes nubes públicas. A veces basta con dejar que la gente haga su trabajo sin estorbarse mutuamente, en un único nodo y sin repartir privilegios de root. Cuando lo ves en marcha, resulta muy difícil volver atrás.

Si hoy utilizas Proxmox y tienes que lidiar con varios equipos a la vez, esta configuración plantea una duda inevitable: ¿por qué seguimos haciéndolo por el camino difícil?