OpenBao se afianza como una alternativa de código abierto para gestionar secretos, certificados y claves cuando una organización desea mantener esta seguridad en su propia infraestructura. El proyecto surgió como un fork de HashiCorp Vault y actualmente se desarrolla bajo el paraguas de OpenSSF, dentro de la Linux Foundation, con una arquitectura enfocada en políticas de acceso, credenciales dinámicas, cifrado y auditoría.
Las claves de OpenBao en 30 segundos
- OpenBao nació como un fork de HashiCorp Vault y mantiene compatibilidad con su modelo de gestión de secretos.
- Puede almacenar secretos cifrados y generar credenciales temporales para servicios compatibles.
- Incluye políticas de acceso, mecanismos de renovación y revocación de credenciales, además de funciones de auditoría.
- Ofrece servicios de cifrado mediante Transit y capacidades para trabajar con PKI.
- Su principal diferencia frente a Secrets Manager o Key Vault radica en el modelo: la organización despliega y administra OpenBao.
La gestión de secretos suele comenzar con elementos simples como una contraseña de base de datos o una clave de API. El problema surge cuando estos datos se multiplican entre aplicaciones, servidores, contenedores y servicios en la nube. Guardarlos en archivos de configuración o variables de entorno puede ser suficiente a pequeña escala, pero dificulta rastrear quién tiene acceso, cuándo se utilizó una credencial y cómo retirarla una vez que ya no es necesaria.
OpenBao propone una capa central para resolver esa dificultad. El sistema puede almacenar secretos arbitrarios, cifrarlos antes de guardarlos en almacenamiento persistente y aplicar políticas que determinen qué usuarios o aplicaciones pueden acceder a ellos.
OpenBao, Vault y los servicios de AWS y Azure
La comparación con HashiCorp Vault resulta inevitable pues OpenBao nació como un fork de aquel. Sin embargo, su enfoque actual implica una diferencia clave: OpenBao se desarrolla bajo un modelo de gobernanza comunitaria dentro de OpenSSF y la Linux Foundation.
Frente a los servicios gestionados de los principales proveedores cloud, la diferencia radica principalmente en el modo de operación. AWS Secrets Manager y Azure Key Vault son servicios integrados en sus respectivas plataformas en la nube. OpenBao, en cambio, está diseñado para que el equipo técnico despliegue y gestione el sistema por sí mismo.
| Característica | OpenBao | HashiCorp Vault | AWS Secrets Manager | Azure Key Vault |
|---|---|---|---|---|
| Modelo | Código abierto y autogestionado | Código abierto / comercial | Servicio gestionado | Servicio gestionado |
| Secretos | Sí | Sí | Sí | Sí |
| Credenciales dinámicas | Sí | Sí | Sí (según servicio) | Sí (según integración) |
| Renovación y revocación | Sí | Sí | Sí | Sí |
| Políticas de acceso | Sí | Sí | IAM | Azure RBAC / políticas |
| Cifrado como servicio | Transit | Transit | KMS + integraciones | Key Vault |
| PKI | Sí | Sí | Integración con otros servicios | Sí |
| Despliegue propio | Sí | Sí | No como servicio equivalente | No como servicio equivalente |
| Almacenamiento controlado por el usuario | Sí | Sí | No | No |
| Gobernanza comunitaria | OpenSSF / Linux Foundation | HashiCorp | AWS | Microsoft |
La tabla ayuda a situar las alternativas, aunque no indica que todas sus funciones sean exactamente equivalentes en cada producto. Por ejemplo, en AWS y Azure, muchas capacidades dependen de la integración con otros servicios de sus plataformas.
Desde una perspectiva práctica, la principal diferencia para un equipo es clara: con OpenBao también hay que gestionar OpenBao. Esto implica encargarse de su despliegue, disponibilidad, almacenamiento, actualizaciones, políticas y recuperación ante incidentes.
Credenciales temporales en lugar de secretos permanentes
Una de las funciones más interesantes de OpenBao es la generación de secretos dinámicos.
En lugar de proporcionar a una aplicación una contraseña válida por meses, un sistema puede solicitar credenciales cuando las necesita. OpenBao puede generar esas credenciales para servicios específicos y asocarlas a un lease, es decir, un período de validez.
Al finalizar el lease, las credenciales pueden revocarse automáticamente. También pueden renovarse mientras sigan siendo necesarias.
Este mecanismo resulta especialmente útil en arquitecturas con múltiples servicios y cargas de trabajo efímeras. Una aplicación que necesita conectarse temporalmente a una base de datos no tiene por qué usar una credencial estática compartida durante toda su vida útil.
OpenBao también permite revocar credenciales de forma individual o en grupos, lo que facilita retirar accesos relacionados con una identidad o responder a incidentes de seguridad.
Transit: separar el cifrado de las aplicaciones
OpenBao incluye Transit, un motor que permite realizar funciones criptográficas sin que la aplicación tenga que gestionar directamente las claves.
El concepto es sencillo: la aplicación envía los datos a cifrar a OpenBao y recibe el resultado cifrado, manteniendo las claves bajo control del sistema de gestión de secretos.
Esto evita que cada equipo cree su propia infraestructura para proteger claves criptográficas y permite centralizar políticas sobre su uso.
Además, OpenBao extiende sus capacidades a la infraestructura de clave pública (PKI). Incluye funciones relacionadas con certificados y, en versiones recientes, mecanismos para utilizar claves externas mediante plugins de gestión de claves.
Por ejemplo, en OpenBao 2.7 se agregó soporte para claves externas usadas por los motores PKI y Transit mediante plugins KMS, con el fin de realizar operaciones criptográficas usando material clave respaldado por sistemas externos, incluyendo módulos compatibles con PKCS#11.
El valor del control: la operación
La principal ventaja de una solución autogestionada también implica una responsabilidad clave.
Mientras que con AWS Secrets Manager o Azure Key Vault gran parte de la infraestructura subyacente la maneja el proveedor, con OpenBao el equipo controla dónde se ejecuta y cómo se integra en su infraestructura, asumiendo también su mantenimiento.
Esto incluye diseñar el almacenamiento, configurar alta disponibilidad si se requiere, proteger accesos administrativos, hacer copias de seguridad, actualizar versiones y definir procedimientos de recuperación.
Para organizaciones que ya operan Kubernetes, servidores propios o infraestructuras híbridas, este modelo puede ajustarse a sus estrategias de control de datos y seguridad. Para equipos que solo buscan un servicio de secretos sin gestionar otra infraestructura, una solución gestionada puede ser más conveniente.
OpenBao está desarrollado en Go y en su repositorio se incluye el código del servidor, la interfaz web y documentación para desplegarlo y desarrollarlo. También se puede compilar el binario bao directamente desde el código fuente.
El proyecto, por tanto, no aspira únicamente a gestionar contraseñas. Su propuesta abarca un conjunto ampliado de tareas: almacenar secretos, generar credenciales temporales, aplicar políticas, revocar accesos, gestionar certificados y realizar operaciones criptográficas, todo desde una infraestructura controlada por la organización.
Preguntas frecuentes
¿En qué se diferencia OpenBao de AWS Secrets Manager?
OpenBao se despliega y gestiona en la infraestructura propia de la organización, mientras que AWS Secrets Manager es un servicio gestionado por AWS integrado en su ecosistema cloud.
¿Es OpenBao lo mismo que HashiCorp Vault?
No. Aunque OpenBao surgió como un fork de HashiCorp Vault, actualmente se desarrolla como un proyecto independiente con gobernanza comunitaria bajo OpenSSF y la Linux Foundation.
¿Puede OpenBao generar credenciales temporales?
Sí. Puede crear secretos dinámicos para determinados sistemas y asociarlos a períodos de validez, con capacidad de renovarlos o revocarlos.
¿Qué hace Transit en OpenBao?
Transit permite realizar funciones de cifrado y descifrado sin que las aplicaciones gestionen directamente las claves criptográficas, centralizando la gestión criptográfica en OpenBao.