FAQ — Hardpipe

¿Por qué no usar simplemente VMware o Nutanix?

Las checklists STIG DISA existen para ambos: Nutanix Acropolis STIG (NCP #1325, 03/2026) y varias versiones de VMware vSphere. Es la lista de reglas. Pero ni Nutanix ni VMware publica su informe de scan efectivo contra ese STIG: las puntuaciones anunciadas (90 %, 95 %) son cifras de marketing, no auditables. Hardpipe publica su informe HTML OpenSCAP completo — cada regla, cada PASS, cada FAIL es inspectable. Puede rejugar el scan sobre su propio ISO y confirmar.

Además, VMware Government / DoD es una edición US. Los banners, la documentación y los mapeos regulatorios están alineados con las exigencias federales estadounidenses — no con el marco UE (RGPD, NIS2, RGS, HDS).

¿Por qué Harvester y no oVirt, Proxmox o un stack a medida?

Harvester v1.8 combina en un único producto:

• Kubernetes nativo (RKE2) — mismo plano de control para VMs y contenedores
• SL Micro 6.2 — SO inmutable con rootfs firmado, ideal para conformidad
• SUSE upstream — proveedor europeo (alemán), soberanía
• KubeVirt + Longhorn — stack CNCF probada, sin lock-in

oVirt está en modo mantenimiento. Proxmox no es K8s-nativo. Un stack a medida cuesta años de desarrollo y no tiene soporte comercial UE.

¿Cómo cualificar para ANSSI (RGS / SecNumCloud)?

Hardpipe proporciona la base técnica (SO reforzado, K8s reforzado, scan reproducible). La cualificación RGS exige adicionalmente:

• Auditoría externa por un CESTI
• Documentación de seguridad formal (objetivo de seguridad, perfil de protección)
• Tests de penetración
• Proceso de respuesta a incidentes

Tenemos previsto presentar Hardpipe a la cualificación ANSSI «Standard» en 2027, con objetivo «Reforzado» a medio plazo.

¿Cómo contribuir?

• Upstream SUSE SSG: nuestras recetas OVAL-strict pueden backportearse. Issue tracker: https://github.com/ComplianceAsCode/content
• Harvester upstream: los fixes SELinux sobre KubeVirt / Longhorn son relevantes para toda la comunidad Harvester. Issues abiertas: https://github.com/harvester/harvester/issues
• Nuestro repo: acceso bajo demanda vía Gitea.

¿Qué diferencia con Talos Linux o Flatcar?

Talos y Flatcar son SO Kubernetes inmutables, pero no proporcionan un stack HCI (sin KubeVirt + Longhorn integrados, sin orquestador de VMs). Hardpipe apunta al caso «VM + contenedor» sobre la misma infraestructura — reemplazo drop-in para vSphere.

¿Puedo usarlo en producción hoy?

Hardpipe v29 es beta. Para producción crítica, validar:

1. Tests de carga en su hardware
2. Validación de sus cargas (drivers GPU, vGPU, SR-IOV, etc.)
3. Procedimiento de upgrade probado en su objetivo

Para PoC, tests de conformidad o labs: listo para usar.

¿Qué costes?

• Software: open source (SUSE Virtualization bajo EULA SUSE; la capa Hardpipe será MIT/Apache)
• Soporte: opcional vía SUSE (soporte Harvester)
• Hardware: servidores x86_64 estándar (32+ threads, 128+ GB RAM, SSD/NVMe). Sin licencia por socket o por VM como VMware.

¿Cuál es el impacto en rendimiento?

El reforzamiento del SO añade < 2 % de overhead (medido en benchmarks sintéticos). SELinux enforcing añade 1-3 % según la carga. La auditoría del kernel (auditd) puede añadir 3-8 % según el número de reglas.

Para cargas típicas (web, bases de datos, ML), el impacto es despreciable. Para trading HFT, preferir un stack no reforzado.

¿Cómo se gestionan las actualizaciones?

Harvester utiliza Fleet + Elemental para upgrades atómicos (SO + K8s + operadores en una transacción). Los bundles firmados se distribuyen vía registry OCI. Rollback automático en caso de fallo.

Por el lado de conformidad, cada upgrade vuelve a disparar un scan OpenSCAP para confirmar que la puntuación se mantiene ≥ 95 %.

¿Hay soporte comercial?

Aún no. Hardpipe es un proyecto de investigación / demostración. Si le interesa una colaboración (hoster, integrador, consultora de seguridad), contáctenos vía Gitea.