OpenBao – Fork FOSS de HashiCorp Vault

Artículo original ↗ Discusión en Hacker News ↗

Ha surgido un nuevo proyecto de código abierto, OpenBao, como fork de HashiCorp Vault tras el cambio de licencia de HashiCorp, con el objetivo de ofrecer un gestor de secretos gobernado por la comunidad y menos ligado a las prioridades comerciales de un único proveedor. Los comentaristas celebran el fork y su comunidad basada en Matrix, pero señalan que está en una fase muy temprana y todavía no listo para producción, lo que plantea preocupaciones sobre estabilidad, confianza y el riesgo de fragmentación en herramientas de seguridad críticas. Junto con comparaciones con las funciones empresariales, el precio y la complejidad operativa de Vault, la conversación examina enfoques alternativos para la gestión de secretos —incluidos SOPS, EnvKey e Infisical— y destaca necesidades específicas como la integración con HSM, el cumplimiento FIPS y la generación dinámica de credenciales que OpenBao tendría que abordar para ser un reemplazo completo.

Estado del proyecto y comunidad

  • OpenBao se describe como un fork de Vault en una etapa muy temprana y todavía no listo para producción.
  • Los contribuyentes invitan a participar a través de varias salas de Matrix y una lista de correo; la federación desde otros servidores de Matrix parece funcionar.
  • Quedan algunos bordes ásperos (por ejemplo, referencias residuales a “Vault” en la documentación y en el texto de seguridad).

Motivaciones para el fork y gobernanza

  • El principal motor declarado: el cambio de licencia de HashiCorp; algunos quieren una versión menos alineada con las necesidades de negocio de una sola empresa.
  • Debate sobre los modelos de negocio de OSS:
    • Un lado sostiene que las empresas que publican bajo licencias liberales deben aprender a competir con los revendedores en la nube y aun así pueden ganar controlando la hoja de ruta y la calidad.
    • El otro lado subraya el alto coste de mantener software complejo y afirma que los revendedores SaaS tienen una gran ventaja al no financiar el desarrollo del núcleo.

Discusión sobre el logo y la marca

  • Varios comentaristas señalan que el logo se parece mucho a la mascota bao de Bun; otros argumentan que hay poco margen de diseño para un “bao bun lindo con cara”.
  • Algunos ven la similitud como de mal gusto; otros creen que es irrelevante porque los productos no tienen relación.

Experiencias de usuarios con Vault, Consul y Nomad

  • Opiniones mixtas:
    • Algunos dicen que Vault y Consul les complican la vida, citando la complejidad operativa y la inestabilidad pasada de Consul (elecciones, problemas de estado).
    • Otros informan de despliegues grandes y estables de Vault (especialmente con un equipo DevOps dedicado) y lo consideran bien diseñado en lugar de “sobrediseñado”.
    • Nomad se califica en broma como “perfecto”, pero no se da una crítica detallada.

Alternativas a Vault

  • Las sugerencias incluyen:
    • Mozilla SOPS (más herramientas como Step CA y Teleport) para secretos KV y algunos casos de uso de autenticación/SSH; se elogia su simplicidad, pero se reconoce que no reemplaza completamente los motores dinámicos de Vault.
    • Infisical y EnvKey como gestores de secretos/configuración más fáciles con ofertas de código abierto.
  • Debate en torno al marketing de EnvKey: los críticos dicen que su comparación con Vault minimiza el conjunto de funciones mucho más amplio de Vault; los defensores sostienen que la comparación se centra en la gestión de secretos, no en las capacidades de infraestructura completas de Vault.

Funciones empresariales: HSM y FIPS

  • Un usuario depende de Vault de pago para la integración HSM on‑prem y el funcionamiento certificado FIPS y no ve OpenBao como sustituto actual.
  • Otros esperan que OpenBao pueda acabar ofreciendo soporte HSM, pero señalan que el trabajo de cumplimiento es caro y necesitaría financiación (se menciona la participación de IBM, pero no se confirma claramente).

Seguridad, confianza y auditorías

  • A algunos les incomodan las vibras de “guerra santa” alrededor de los forks y temen inestabilidad o cambios maliciosos en una herramienta crítica para la seguridad.
  • Las respuestas enfatizan:
    • HashiCorp Vault no se considera más vulnerable después del fork; el conflicto gira en torno a la licencia y la gobernanza.
    • La garantía final proviene de auditorías, revisión de código y/o pagar a un proveedor para que asuma las garantías de seguridad.
  • La frase hecha “nos tomamos la seguridad muy en serio” se ve por algunos como algo que reduce la confianza en lugar de tranquilizar.