Skip to content

Aislamiento de Máquinas Virtuales por Inquilino en PPN

El pool de recursos de la Red Privada de PointSav (PPN) permite que múltiples inquilinos ejecuten máquinas virtuales en un conjunto compartido de nodos físicos y en la nube. Este artículo describe el modelo de aislamiento: qué separación se proporciona, qué no, y el camino planificado hacia un aislamiento más sólido a nivel de red.

La pila

Cada solicitud de máquina virtual atraviesa tres capas antes de que un proceso QEMU se inicie en un nodo físico:

  • Proxy de inquilino — autentica al llamante, aplica el espacio de nombres y la cuota, y es el único punto de entrada externo
  • Controlador de flota — gestiona la colocación y delega en el agente de host; acepta conexiones únicamente del proxy de inquilino y de los participantes internos de la malla
  • Agente de host — inicia el proceso QEMU en el nodo seleccionado; no es accesible por llamantes externos

Un llamante que disponga de la dirección del controlador de flota pero no de una credencial de inquilino válida no puede alcanzar el controlador de flota directamente — la capa de autenticación no puede eludirse.

Qué proporciona el aislamiento de inquilinos

Aislamiento de espacio de nombres

Un inquilino autenticado puede crear, listar y destruir únicamente sus propias máquinas virtuales. La identidad del inquilino es inyectada por el proxy de inquilino en cada solicitud reenviada al controlador de flota; un inquilino no puede suministrar una identidad diferente en el cuerpo de una solicitud. El listado de VMs devuelve únicamente los registros pertenecientes al inquilino autenticado. Las solicitudes de destrucción se validan contra la propiedad antes de ser reenviadas.

Este aislamiento sobrevive a los reinicios del controlador de flota: la identidad del inquilino se almacena en el registro de la VM, se repite en cada latido de corazón del nodo y se restaura en el registro en memoria al arrancar. La propiedad no reside únicamente en la memoria del proxy de inquilino.

Aislamiento de proceso

Cada máquina virtual es un proceso QEMU separado en el nodo físico. Los sistemas operativos invitados se ejecutan en espacios de direcciones aislados por hardware (en nodos con aceleración KVM) o en espacios de direcciones aislados por software (en nodos solo con TCG). La máquina virtual de un inquilino no puede leer la memoria ni el disco de la máquina virtual de otro inquilino a través de rutas de software normales.

Contención de red por VM

Las máquinas virtuales utilizan redes en modo usuario SLIRP: cada invitado recibe una pila de direcciones NAT privada sin ninguna ruta entrante desde la red del host ni desde otras VMs. Un proceso invitado que abra un socket de servidor no es alcanzable a menos que se haya configurado una regla de reenvío al host en el momento de la creación. La respuesta de creación de la VM incluye la lista de puertos del host reenviados para que los llamantes sepan cómo acceder a su VM.

Seguridad del token portador

Las credenciales de inquilino son tokens portadores opacos que se asignan a una identidad de inquilino en la configuración del proxy. Conocer la cadena de identidad de un inquilino no es suficiente para autenticarse; el llamante debe presentar el token asociado. Los tokens no se registran en ningún registro de auditoría.

Registro de auditoría

Cada operación del ciclo de vida de un inquilino — crear VM, destruir VM — queda registrada en dos lugares: un archivo de solo adición local en el proxy de inquilino, y el libro WORM. El registro WORM incluye la identidad del inquilino, el tipo de operación, el identificador de la VM, la marca de tiempo y el resultado. Las entradas WORM no pueden sobrescribirse ni eliminarse.

Qué no proporciona el aislamiento de inquilinos

Sin subred de red por inquilino

Todas las máquinas virtuales en un nodo físico dado salen a través de la misma interfaz de red del host. Un observador de red que monitorice el tráfico saliente del nodo no puede distinguir el tráfico de la VM de un inquilino del tráfico de la VM de otro inquilino en la capa de transporte. Los inquilinos están aislados en la capa de aplicación mediante pilas de red separadas, pero no en la capa de red.

Sin aislamiento del operador del nodo

Cualquier persona con acceso administrativo a la máquina física que aloja una VM puede leer la imagen de disco y la memoria del invitado. Esto es una propiedad del modelo de virtualización basado en QEMU actual, no una limitación del plano de control de la PPN.

La respuesta prevista a ambas limitaciones es la capa de aislamiento seL4, descrita a continuación.

Aplicación de cuota

Cada inquilino tiene configurado un recuento máximo de VMs en el proxy de inquilino. El proxy aplica las cuotas mediante una compuerta serializada en solicitudes de creación concurrentes: dos solicitudes simultáneas del mismo inquilino superan ambas la comprobación de cuota solo si existe cuota suficiente para las dos.

Camino hacia el aislamiento a nivel de red

El aislamiento a nivel de red — subredes WireGuard por inquilino de modo que las VMs de los inquilinos sean criptográficamente inaccesibles para otros inquilinos, no solo separadas por API — requiere dos hitos futuros:

Fase S3 del plano de control de red de la PPN (planificada): El plano de control adquiere la capacidad de gestionar tablas de pares WireGuard programáticamente. Cuando un nuevo nodo se une a la malla, está previsto que el plano de control actualice automáticamente las configuraciones de enrutamiento de todos los nodos. Esta es la base prevista para asignar a cada inquilino una subred distinta con sus propias claves WireGuard.

Modo B de seL4 (planificado/previsto): Está previsto que el propio plano de control de red se ejecute como una VM de primera clase dentro de la PPN, aislada por un microkernel formalmente verificado. En el Modo B, se prevé que incluso un operador de nodo con acceso administrativo a la máquina física no pueda inspeccionar la configuración del plano de control de red ni extraer las claves de los inquilinos.

Hasta que se alcancen estos hitos, el límite de aislamiento se describe con precisión como aislamiento a nivel de API: los inquilinos no pueden acceder a los recursos de los demás a través del plano de control, pero comparten las rutas de red física en la capa de transporte, y los operadores de nodo mantienen el acceso administrativo a las máquinas físicas que administran.

Véase también


Woodfine Capital Projects™, MCorp™, PointSav Digital Systems™, Totebox Orchestration™, Totebox Archive™ y Capability Geometry™ son marcas comerciales de Woodfine Capital Projects Inc., utilizadas en Canadá, los Estados Unidos, América Latina y Europa. Todas las demás marcas comerciales son propiedad de sus respectivos propietarios.

Important Information

Important Information

Corporate structure. PointSav Digital Systems ("PointSav") is a trade name of Woodfine Capital Projects Inc. ("Woodfine"). PointSav does not itself offer, sell, or solicit any security. Any securities offering associated with Woodfine's real-property direct-hold solutions is made exclusively by Woodfine, and only by means of the applicable Private Placement Memorandum.

No investment advice. This wiki's content is provided for engineering, operational, research, and development purposes. Nothing on this wiki constitutes investment advice or a solicitation to invest in any Woodfine partnership or direct-hold solution.

Intellectual property. The PointSav name, trade name, wordmark, and marks, together with all current and future PointSav- and Totebox-branded products, services, and offerings — and the software, source code, documentation, design system, and all related materials — are proprietary to Woodfine and its affiliates, except for components identified as open source. No rights are granted except as expressly set out in a written license or agreement. See TRADEMARK.md in this repository for the full trademark notice.

Open source components. Portions of the platform are made available under permissive open-source licenses identified in the accompanying repository. Use of those components is governed by their respective license terms.

No warranty; informational use. Content on this wiki is provided for general informational purposes only and does not constitute a representation, warranty, or commitment with respect to product functionality, availability, pricing, or roadmap. Some articles describe planned or intended features, capabilities, and milestones — language such as "planned," "intended," "targeted," "may," and "expected" marks this forward-looking content, which is subject to change and does not constitute a commitment regarding future performance.

Confidentiality. Where an article describes an operational or deployment detail that is not intended for public disclosure, that article is not published on this wiki. Content here is general-purpose engineering documentation, not customer-specific configuration.

Jurisdiction. Woodfine Capital Projects Inc. is organized in British Columbia, Canada. References to the Sovereign Data Foundation on this wiki describe a planned or intended initiative only, not a current equity holder or active governance body.

Changes to this notice. PointSav may update this notice from time to time; the version posted on this page governs.

Not a filing system. This wiki is not a securities filing system, an electronic disclosure repository, or a substitute for SEDAR+ or any other regulatory filing system. Formal securities filings are made through the applicable regulatory filing system, not through this wiki.

Full disclaimer. This notice supplements, and does not replace, the full Disclaimers article. In the event of any conflict, the full Disclaimers article governs.

Read the full disclaimer →