AWS tiene Secrets Manager y Microsoft Azure cuenta con Key Vault, pero las empresas que gestionan su propia infraestructura también necesitan un lugar centralizado para guardar credenciales, claves y certificados. OpenBao ofrece una alternativa open source para esa tarea, con almacenamiento cifrado, credenciales temporales, políticas de acceso, renovación y revocación de secretos y registro de actividad. El proyecto está gestionado bajo el paraguas de OpenSSF en la Linux Foundation.
Las claves de OpenBao en 30 segundos
- OpenBao es un gestor open source de secretos nacido como fork de HashiCorp Vault.
- Permite almacenar secretos, certificados y claves y cifrarlos antes de guardarlos.
- Puede generar credenciales temporales para servicios como bases de datos o Kubernetes.
- Los secretos pueden tener permisos, caducidad, renovación y revocación.
- El proyecto mantiene una gobernanza comunitaria dentro de OpenSSF, en la Linux Foundation.
La idea de OpenBao es bastante directa: sacar los secretos sensibles de archivos de configuración, variables de entorno dispersas o sistemas creados específicamente para cada aplicación y centralizar su gestión. El proyecto está pensado para credenciales de bases de datos, claves de API, certificados y otros datos que aplicaciones y servicios necesitan utilizar sin que tengan que quedar expuestos permanentemente.
Su origen también explica por qué resulta familiar para quienes ya han trabajado con Vault. OpenBao nació como un fork de HashiCorp Vault y busca mantener una alternativa gobernada por una comunidad con licencia de código abierto aprobada por la Open Source Initiative (OSI). Actualmente el proyecto forma parte de OpenSSF, dentro de la Linux Foundation.
Más que una caja fuerte para contraseñas
OpenBao no se limita a guardar pares de clave y valor. El sistema cifra los secretos antes de escribirlos en el almacenamiento persistente, de modo que acceder directamente al backend donde se encuentran los datos no proporciona automáticamente acceso al contenido de esos secretos. Puede utilizar diferentes sistemas de almacenamiento, entre ellos disco y PostgreSQL.
La otra pieza importante son los secretos dinámicos. En lugar de entregar a una aplicación una credencial permanente, OpenBao puede generar credenciales bajo demanda para determinados sistemas. Su documentación pone como ejemplos Kubernetes y bases de datos SQL.
El mecanismo permite asociar esas credenciales a un periodo de validez. Cuando termina el lease, OpenBao puede revocarlas automáticamente. Los clientes también pueden renovar los leases mediante las API disponibles.
Ese modelo cambia la forma de gestionar una credencial. Una aplicación puede solicitar acceso cuando lo necesita, utilizar unas credenciales con una duración limitada y dejar que el sistema las retire posteriormente. La ventaja no está en eliminar las credenciales, sino en reducir la necesidad de mantenerlas activas indefinidamente.
OpenBao también permite revocar secretos de forma individual o actuar sobre grupos completos. La documentación contempla, por ejemplo, la revocación de todos los secretos asociados a un usuario o de todos los secretos de un determinado tipo.
Políticas, identidades y auditoría centralizadas
En una infraestructura con muchos servicios, saber qué aplicación puede acceder a cada credencial puede ser tan importante como almacenar el secreto de forma segura. OpenBao utiliza autenticación y políticas de control de acceso para determinar qué usuarios y aplicaciones pueden acceder a determinados recursos. Además, mantiene un registro de las acciones realizadas por los clientes.
El proyecto plantea así un punto común para gestionar identidades y permisos en entornos que pueden combinar distintos proveedores y servicios. Su documentación describe un sistema de control de acceso basado en políticas y una capa de identidad que permite centralizar el acceso a secretos y otros recursos.
Otra capacidad es Transit, el sistema de cifrado como servicio de OpenBao. Permite que una aplicación envíe datos para cifrar o descifrar sin que el sistema que consume la API tenga que almacenar directamente las claves utilizadas por OpenBao. La documentación lo plantea como una forma de centralizar parámetros criptográficos y evitar que cada aplicación tenga que construir su propio sistema de cifrado.
La evolución reciente del proyecto también está llevando esta parte más lejos. OpenBao 2.7.0, publicada el 23 de septiembre de 2026, añadió soporte para claves externas mediante plugins de KMS. Con esta función, los motores PKI y Transit pueden realizar operaciones criptográficas utilizando claves respaldadas por sistemas externos, incluidos módulos compatibles con PKCS#11, sin almacenar el material de clave dentro de OpenBao.
Un proyecto que ya tiene una evolución propia
OpenBao no se ha quedado en ser simplemente una copia mantenida de Vault. Su desarrollo está incorporando funciones propias y una arquitectura de gobernanza diferente, aunque conserva una compatibilidad importante con conceptos y APIs procedentes del proyecto del que nació.
La versión 2.6, por ejemplo, incorporó namespace sealing, que permite configurar mecanismos de sellado independientes por espacio de nombres, y añadió plugins de KMS para mecanismos de auto-unseal. La versión 2.7 continuó esa línea con las claves externas para PKI y Transit y soporte para ML-DSA, el algoritmo de firma digital estandarizado por NIST en FIPS 204.
Para un equipo técnico, la diferencia frente a un servicio gestionado de AWS o Azure está precisamente en dónde se ejecuta el sistema. OpenBao está pensado para desplegarse como parte de la infraestructura que controla la organización, en lugar de depender exclusivamente de un servicio de gestión de secretos proporcionado por el proveedor cloud.
Eso también implica asumir la operación del propio sistema: despliegue, almacenamiento, alta disponibilidad, actualizaciones, control de accesos y respuesta ante incidentes pasan a formar parte de las responsabilidades del equipo. Open source no significa que desaparezca esa carga operativa.
El proyecto se desarrolla en Go y permite compilar el binario bao directamente desde el repositorio. También proporciona documentación, interfaz web y diferentes mecanismos de despliegue.
Para organizaciones que trabajan con Kubernetes, bases de datos, API externas, certificados o varias plataformas de infraestructura, OpenBao plantea una alternativa para concentrar la gestión de secretos en una capa propia. Su principal diferencia frente a los servicios equivalentes de los grandes proveedores cloud está en el control sobre dónde se ejecuta y cómo se administra.
Preguntas frecuentes
¿Qué es OpenBao?
OpenBao es un gestor open source para almacenar y distribuir secretos, certificados y claves. Nació como fork de HashiCorp Vault y actualmente está gestionado bajo OpenSSF en la Linux Foundation.
¿Qué puede almacenar OpenBao?
Puede almacenar secretos arbitrarios de tipo clave-valor y trabajar también con certificados y claves. Los datos se cifran antes de escribirse en el almacenamiento persistente.
¿Puede OpenBao generar contraseñas temporales?
Sí. OpenBao puede generar credenciales dinámicas para determinados sistemas, como bases de datos SQL o Kubernetes, y revocarlas automáticamente cuando termina su periodo de validez.
¿OpenBao sustituye a AWS Secrets Manager o Azure Key Vault?
Puede cubrir una necesidad similar de gestión centralizada de secretos, pero con un modelo de despliegue propio. OpenBao está diseñado para que la organización ejecute y administre el gestor dentro de su propia infraestructura.
