--- title: "OpenBao frente a Vault y los gestores cloud: qué ofrece este proyecto open source" description: "OpenBao se está consolidando como una alternativa open source para gestionar secretos, certificados y claves cuando una organización quiere mantener esta pieza de seguridad dentro de su propia infraes..." url: https://revistacloud.com/openbao-frente-a-vault-y-los-gestores-cloud-que-ofrece-este-proyecto-open-source/ date: 2026-10-06 modified: 2026-10-01 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2026/10/openbao-secrets.jpg categories: ["Cloud", "Seguridad"] tags: ["aws", "Openbao", "secretos"] type: post lang: es --- # OpenBao frente a Vault y los gestores cloud: qué ofrece este proyecto open source **[OpenBao](https://github.com/openbao/openbao)** se está consolidando como una alternativa open source para gestionar secretos, certificados y claves cuando una organización quiere mantener esta pieza de seguridad dentro de su propia infraestructura. El proyecto nació como un fork de HashiCorp Vault y actualmente se desarrolla bajo OpenSSF, dentro de la Linux Foundation, con una arquitectura centrada en políticas de acceso, credenciales dinámicas, cifrado y auditoría. **Las claves de OpenBao en 30 segundos** - OpenBao nació a partir de un fork de HashiCorp Vault y mantiene una orientación compatible con su modelo de gestión de secretos. - Puede almacenar secretos cifrados y generar credenciales temporales para servicios compatibles. - Incluye políticas de acceso, renovación y revocación de credenciales y auditoría. - También ofrece servicios de cifrado mediante Transit y funciones para trabajar con PKI. - Su principal diferencia frente a Secrets Manager o Key Vault es el modelo: la organización despliega y administra OpenBao. La gestión de secretos suele empezar con algo tan sencillo como una contraseña de base de datos o una clave de API. El problema aparece cuando esos datos se multiplican entre aplicaciones, servidores, contenedores y servicios cloud. Guardarlos en archivos de configuración o variables de entorno puede funcionar a pequeña escala, pero dificulta saber quién tiene acceso, cuándo se utilizó una credencial y cómo retirarla cuando deja de ser necesaria. OpenBao plantea una capa central para resolver esa gestión. El sistema puede almacenar secretos arbitrarios, cifrarlos antes de escribirlos en el 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 es inevitable porque OpenBao nació como un fork de ese proyecto. Pero su propuesta actual tiene una diferencia importante: OpenBao se desarrolla bajo un modelo de gobernanza comunitaria dentro de OpenSSF y la Linux Foundation. Frente a los servicios gestionados de los grandes proveedores cloud, la diferencia está principalmente en el modelo de operación. AWS Secrets Manager y Azure Key Vault son servicios integrados en sus respectivas nubes. OpenBao, en cambio, está pensado para que el equipo técnico despliegue y administre el sistema. | Característica | OpenBao | HashiCorp Vault | AWS Secrets Manager | Azure Key Vault | | --- | --- | --- | --- | --- | | Modelo | Open source y autogestionado | Open source/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 sirve para situar las alternativas, pero no significa que todas las funciones sean equivalentes en cada producto. En AWS y Azure, por ejemplo, muchas capacidades dependen de la integración con otros servicios de sus respectivas plataformas. La diferencia práctica para un equipo es clara: **con OpenBao también hay que operar OpenBao**. Eso implica encargarse del 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 que permanece válida durante meses, un sistema puede solicitar credenciales cuando las necesita. OpenBao puede generar esas credenciales para determinados servicios y asociarlas a un *lease*, es decir, un periodo de validez. Cuando el *lease* termina, 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é utilizar necesariamente una credencial estática compartida durante toda su vida útil. OpenBao también permite revocar credenciales de forma individual o actuar sobre grupos de secretos. Esto puede ser útil cuando hay que retirar el acceso asociado a una identidad o responder a un incidente de seguridad. ## Transit permite separar el cifrado de las aplicaciones OpenBao incluye además **Transit**, un motor que permite utilizar funciones criptográficas sin que la aplicación tenga que gestionar directamente las claves. El planteamiento es sencillo: la aplicación envía los datos que necesita cifrar a OpenBao y recibe el resultado. Las claves permanecen bajo el control del sistema de gestión de secretos. Esto evita que cada equipo tenga que crear desde cero su propia infraestructura para proteger claves criptográficas. También permite centralizar determinadas políticas sobre cómo se utilizan esas claves. Las capacidades de OpenBao se extienden además a la infraestructura de clave pública (PKI). El proyecto incluye funciones relacionadas con certificados, mientras que versiones recientes han añadido mecanismos para utilizar claves externas mediante plugins de gestión de claves. En OpenBao 2.7, por ejemplo, se incorporó soporte para claves externas utilizadas por los motores PKI y Transit a través de plugins KMS. El objetivo es permitir operaciones criptográficas utilizando material de clave respaldado por sistemas externos, incluidos módulos compatibles con PKCS#11. ### El precio del control es la operación La principal ventaja de una solución autogestionada también es uno de sus principales requisitos. Con AWS Secrets Manager o Azure Key Vault, buena parte de la infraestructura subyacente queda en manos del proveedor. Con OpenBao, el equipo controla dónde se ejecuta el sistema y cómo se integra con el resto de la infraestructura, pero también tiene que mantenerlo. Eso incluye diseñar el almacenamiento, configurar alta disponibilidad cuando sea necesaria, proteger el acceso administrativo, mantener las copias de seguridad, actualizar las versiones y preparar procedimientos de recuperación. Para una organización que ya opera Kubernetes, servidores propios o una infraestructura híbrida, este modelo puede encajar con una estrategia de control sobre los datos y las herramientas de seguridad. Para un equipo que busca simplemente un servicio de secretos sin añadir otro sistema que mantener, un servicio gestionado puede tener un encaje operativo diferente. OpenBao está escrito en Go y el repositorio incluye el código del servidor, la interfaz web y documentación para desplegarlo y desarrollarlo. También permite compilar el binario `bao` directamente desde el código fuente. El proyecto, por tanto, no intenta competir únicamente por la función de guardar una contraseña. Su propuesta cubre un conjunto más amplio de tareas: **almacenar secretos, generar credenciales temporales, aplicar políticas, revocar accesos, gestionar certificados y proporcionar operaciones criptográficas** desde una infraestructura que la propia organización controla. ## Preguntas frecuentes ### ¿Qué diferencia a OpenBao de AWS Secrets Manager? OpenBao está diseñado para desplegarse y administrarse en la infraestructura de la organización. AWS Secrets Manager es un servicio gestionado de AWS integrado con su ecosistema cloud. ### ¿OpenBao es lo mismo que HashiCorp Vault? No. OpenBao nació como un fork de HashiCorp Vault, pero actualmente se desarrolla como un proyecto independiente con gobernanza comunitaria bajo OpenSSF y la Linux Foundation. ### ¿Puede OpenBao generar credenciales temporales? Sí. Puede generar secretos dinámicos para determinados sistemas y asociarlos a periodos de validez. Esas credenciales pueden renovarse o revocarse. ### ¿Para qué sirve Transit en OpenBao? Transit permite utilizar funciones de cifrado y descifrado sin que las aplicaciones tengan que gestionar directamente las claves criptográficas. Esto permite centralizar parte de la gestión criptográfica en OpenBao.