Cómo usar OpenBao en la empresa: guía práctica y alternativas

Cuando una empresa empieza a tomarse en serio la seguridad de sus credenciales, enseguida descubre que tener contraseñas, tokens y certificados repartidos por mil sitios (ficheros, variables de entorno, wikis internas…) es una receta perfecta para el desastre. Ahí es donde entra en juego OpenBao, el fork comunitario de Vault que ha llegado para cubrir el hueco que deja el cambio de licencia de HashiCorp sin renunciar al modelo open source de verdad.

Si estás desplegando OpenBao con Argo CD y Helm y quieres llevar la filosofía GitOps hasta el extremo (incluyendo políticas, configuración, inicialización y des‑sellado como código), es normal sentirse un poco perdido: hay muchas piezas (selos, backends de almacenamiento, HA, métodos de autenticación, plugins…) y varias alternativas para automatizarlo todo sin intervención humana. Vamos a ordenar ese rompecabezas y, de paso, a poner OpenBao en contexto frente a otras bóvedas de contraseñas y gestores de secretos que también pueden encajar en tu organización.

Qué es OpenBao y por qué existe

OpenBao nace como una bifurcación (fork) de HashiCorp Vault impulsada por la comunidad y respaldada por la Linux Foundation. El detonante fue el cambio de licencia de HashiCorp a BSL 1.1, que limita el uso de su código en plataformas que compiten comercialmente con sus servicios en la nube, algo incompatible con los requisitos de la propia Linux Foundation y con muchos modelos de negocio basados en open source tradicional.

En lugar de abandonar por completo el ecosistema Vault, varias empresas y contribuidores —incluido personal de IBM que trabaja en Open Horizon— decidieron tomar como base la rama 1.14.x de Vault, con todo lo que estaba todavía bajo licencia MPL 2.0, y continuar el desarrollo bajo un modelo de gobernanza comunitaria abierto, sin dependencia de un único proveedor. El objetivo declarado es mantener compatibilidad máxima con Vault (comandos, API, SDKs, plugins) mientras se garantiza un futuro realmente libre al proyecto.

OpenBao hereda de Vault su filosofía: un servicio centralizado que te permite gestionar secretos, certificados, claves, tokens y políticas de acceso desde un único punto, con auditoría, rotación dinámica y control granular. Pero a partir de aquí el roadmap pone el foco, en una primera fase, en consolidar y mejorar las funciones heredadas (almacenamiento seguro, rotación, control de acceso detallado) y reforzar las capacidades de auditoría y cumplimiento normativo para que encaje mejor en organizaciones reguladas.

En fases posteriores, la comunidad de OpenBao planea ampliar el soporte para distintas nubes y arquitecturas distribuidas, mejorar APIs y sistema de plugins, y facilitar integraciones profundas con otras herramientas de DevOps, observabilidad y seguridad, para que conectarlo con tu ecosistema no sea una odisea.

OpenBao frente a Vault y otros gestores de secretos

Uno de los grandes atractivos de OpenBao es que, si ya conoces Vault, prácticamente sabes usarlo: la CLI bao mantiene la mayoría de comandos y patrones de uso de vault, los backends de almacenamiento y los engines (KV, PKI, Transit, SSH, bases de datos) se comportan de forma muy similar, y las integraciones con Kubernetes, Terraform o Ansible siguen el mismo modelo mental.

Comparado con un gestor de contraseñas clásico como KeePassXC, Bitwarden, Passbolt o Psono, OpenBao juega en otra liga: está diseñado para secretos de aplicación y de infraestructura (tokens, credenciales de BBDD, certificados, claves de cifrado, SSH CA…), no tanto para las contraseñas «humanas» del día a día del usuario. Su fuerte está en integrarse con pipelines CI/CD, Kubernetes, herramientas de automatización y sistemas de identidad corporativos.

Frente a alternativas empresariales como CyberArk Conjur OSS, OpenBao es por lo general más sencillo de entender y desplegar, manteniendo un buen equilibrio entre flexibilidad y complejidad. Conjur empuja mucho la idea de «política como código» con un DSL propio y control de acceso extremadamente granular pensado para entornos con exigencias de compliance muy altas y equipos dedicados de seguridad; OpenBao llega a un punto similar con políticas HCL/JSON y modelos RBAC, pero con una curva de entrada algo más amable.

Si lo que buscas es un gestor de secretos centrado en developer experience y UX moderna (por ejemplo, Infisical o Phase), OpenBao te exigirá algo más de trabajo inicial, pero a cambio te da un diseño de seguridad probado en producción durante años gracias al legado de Vault y una comunidad que lo impulsa en modo vendor‑neutral.

Configurar OpenBao en la empresa: archivo de configuración y opciones clave

Fuera del modo desarrollo, OpenBao se configura mediante archivo. Puedes usar HCL o JSON, y en lugar de un único fichero también puedes tener un directorio de configuración: cualquier archivo que termine en .hcl o .json se cargará por orden alfabético. Si una misma clave «de nivel superior» aparece en varios ficheros y no es una lista, prevalece el valor del último archivo; en el caso de listas (por ejemplo, varios listener), los elementos se agregan a la configuración.

La forma habitual de arrancar el servidor es indicando bao server -config=/ruta/al/config. A partir de ahí, las secciones más importantes que tendrás que definir para un despliegue empresarial son:

• storage: backend donde se guardan los datos persistentes.
• ha_storage: backend que coordina el modo HA, si el de storage no soporta alta disponibilidad.
• listener: cómo y dónde escucha OpenBao las peticiones HTTP(s).
• seal: tipo de sello (auto‑unseal, HSM, KMS on‑prem, etc.).
• parámetros globales como cluster_name, TTL de leases, logging, UI, auditoría y plugins.

storage marca qué backend utilizarás para persistir el estado (por ejemplo, un almacenamiento integrado tipo Raft, Consul, etc.). Si ese backend soporta coordinación HA, podrás definir opciones de alta disponibilidad directamente ahí; si no, podrás recurrir a ha_storage para señalar un backend específico solo para la coordinación de nodos en cluster.

En la sección listener definirás protocolo, dirección y puerto, certificados TLS si corresponde, tiempo máximo de cada petición (o dejarás que tome el default_max_request_duration global), etc. En entornos corporativos es habitual contar con uno o más listeners detrás de un balanceador que haga terminación TLS o autenticación adicional.

Otra pieza crítica es el bloque seal, donde eliges cómo se va a cifrar la «barrera de seguridad». En modo muy resumido: puedes confiar en el esquema de claves dividido (Shamir) con des‑sellado manual, o bien configurar un auto‑unseal mediante un KMS o HSM. Más adelante entraremos en cómo automatizar esto en entornos sin conectividad a nubes públicas.

A nivel global, OpenBao permite ajustar parámetros como:

• default_lease_ttl y max_lease_ttl: tiempos por defecto y máximos para tokens y secretos, expresados con sufijos tipo «30s» o «1h».
• default_max_request_duration: tiempo máximo por petición antes de que el servidor la corte.
• log_level, formato y rotación de logs, incluso rotación por tamaño o por tiempo.
• activación del ui web, telemetría, endpoints internos de inspección o de acceso raw a almacenamiento (estos últimos muy sensibles).
• opciones de user_lockout para bloquear usuarios tras varios intentos fallidos.

Seguridad de ficheros, plugins y auditoría

En producción conviene habilitar los controles de permisos de ficheros; OpenBao puede verificar que el directorio y los archivos de configuración sean propiedad del usuario que ejecuta el proceso y que no tengan permisos de escritura o ejecución para grupo u otros. Esto se activa con la variable de entorno VAULT_ENABLE_FILE_PERMISSIONS_CHECK.

Cuando ese chequeo está activo, si necesitas que el directorio de plugins o los binarios de plugin pertenezcan a otro usuario distinto (por motivos de empaquetado o políticas de seguridad), puedes ajustar plugin_file_uid y plugin_file_permissions en la configuración. Así OpenBao sabrá qué UID y permisos octales son aceptables, aunque no coincidan con el usuario del proceso.

En cuanto a plugins, OpenBao soporta registro declarativo y descarga desde imágenes OCI. Puedes activar plugin_auto_download y plugin_auto_register para que el servidor descargue y registre automáticamente plugins según los necesite, y controlar el comportamiento en caso de error con plugin_download_behavior (por ejemplo, hacer que el fallo al descargar un plugin sea fatal).

La auditoría es otro punto delicado: OpenBao permite definir dispositivos de auditoría (archivos, sockets, syslog, etc.) durante el arranque y, opcionalmente, habilitar la capacidad de crear nuevos dispositivos vía API estableciendo unsafe_allow_api_audit_creation. Lo razonable es activarlo solo de manera puntual cuando tengas que automatizar cambios específicos y volver a desactivarlo después para reducir la superficie de riesgo.

OpenBao, GitOps y Argo CD: políticas y configuración como código

Cuando despliegas OpenBao mediante el chart oficial de Helm y lo gestionas con Argo CD, lo habitual es tratar TODO como código: manifiestos de Kubernetes, valores de Helm, configuración del servidor, políticas, métodos de autenticación, incluso la inicialización y el proceso de des‑sellado. La parte complicada está en decidir qué se hace desde Kubernetes/Argo, qué se define en ficheros HCL/JSON y qué se ejecuta mediante scripts o Jobs de inicialización.

Un patrón muy extendido es incluir en tu repositorio Git una carpeta con la configuración de OpenBao (en HCL o JSON) montada como ConfigMap/Secret en el Pod del servidor. Ahí defines storage, listener, seal, TTLs, logging y parámetros como la UI o la telemetría. Esta capa es puramente infra y encaja muy bien en GitOps.

Sobre esa base, muchas organizaciones gestionan las políticas, habilitado de engines, roles y métodos de autenticación con una segunda capa de código: scripts idempotentes (shell, Go, Python) o herramientas IaC (Terraform u OpenTofu) que aplican la configuración a OpenBao hablando con la API. Estos scripts se lanzan desde:

• Jobs de Kubernetes que Argo CD despliega tras el propio servidor.
• pipelines de CI/CD que se ejecutan cuando cambia el repositorio de políticas.
• o una mezcla de ambos, según el entorno (dev, pre, prod).

Los recursos que suelen versionarse como código incluyen:

• Policies en HCL/JSON, con sus paths y capacidades (read, list, update, sudo…).
• Auth methods (Kubernetes, approle, OIDC, LDAP) con su configuración.
• Mounts de secretos (KV v2, PKI, Transit, BBDD, SSH) y sus parámetros de rotación.
• Roles y vínculos entre identidades (service accounts, grupos de AD) y policies.

En un enfoque maduro de GitOps, cada cambio en esas definiciones pasa por revisión, se aplica de forma reproducible y puedes auditar la historia completa de políticas y accesos. Esto es especialmente útil si tienes certificaciones como ISO 27001 u otros estándares que exigen trazabilidad y control de cambios.

Automatizar el sellado y des‑sellado de OpenBao

El gran quebradero de cabeza cuando se quiere operar OpenBao sin intervención humana es el proceso de sellado/des‑sellado. Por diseño, la «barrera de seguridad» de OpenBao se cifra con una clave que, en el modo clásico, se divide en varias partes siguiendo el esquema de Shamir. Para arrancar el servidor y acceder a los secretos, necesitas un número mínimo de esas partes, generalmente introducidas por operadores humanos.

En entornos on‑premise o en «appliances» que se despliegan en instalaciones de clientes, donde no tienes control directo y no puedes asumir que alguien vaya a introducir claves manualmente, esto es inviable. Además, si el entorno debe ser completamente autónomo, no puedes depender de KMS de nube pública como AWS KMS o GCP KMS para el auto‑unseal.

En estas situaciones, los patrones más habituales para automatizar el des‑sellado de OpenBao pasan por:

• Usar un HSM o KMS local (on‑prem, hardware o software) integrado con OpenBao como sello automático.
• Montar un servicio de unseal interno que almacene las claves de Shamir cifradas y las suministre a OpenBao de forma controlada.
• Optar por herramientas alternativas que integren auto‑unseal de serie y tengan menos requisitos de interacción humana.

Si eliges HSM/KMS local, el patrón es similar al de la nube: configuras el bloque seal con el proveedor correspondiente (HSM, módulo de seguridad hardware, KMS de un tercero instalado en local), y a partir de ahí el servidor se des‑sellará automáticamente siempre que pueda hablar con ese sistema. Es una opción sólida, pero implica invertir en hardware específico o software de seguridad adicional.

El enfoque del «servicio de unseal» interno suele basarse en guardar las claves de Shamir en un almacenamiento que controle tu organización (por ejemplo, otra bóveda o un HSM), cifradas con una clave de máquina, y exponer un pequeño servicio que, al detectar que OpenBao está sellado, envía las partes necesarias a la API de des‑sellado. Esto añade complejidad arquitectónica pero evita la intervención humana en el día a día.

Por último, si tu requisito principal es un appliance totalmente autónomo y auto‑gestionado, quizá te interese valorar gestores de secretos diseñados desde el principio para despliegues on‑prem simples, donde el auto‑unseal viene más «empaquetado» y no necesitas tanta orquestación. En estos casos, algunas soluciones específicas de software/hardware empotrado pueden ser más adecuadas que OpenBao.

Cómo usar el cliente de OpenBao en tus aplicaciones

Además de gestionarlo como servicio central, necesitas integrar OpenBao con tus aplicaciones para que dejen de almacenar secretos en código o en ficheros de configuración. El flujo básico es siempre el mismo: arrancas OpenBao, te autenticas desde tu aplicación, escribes un secreto y luego lo lees cuando lo necesitas.

Para experimentar, puedes iniciar OpenBao en modo desarrollo con un comando tipo:

bao server -dev -dev-root-token-id=dev-only-token

En este modo, OpenBao escucha en HTTP en el puerto 8200 y genera un token raíz con acceso completo. Es perfecto para pruebas locales, pero absolutamente inadecuado para producción. El siguiente paso es instalar la librería cliente en el lenguaje que uses (por ejemplo, Go o Bash via curl) e importar los paquetes adecuados en tu código.

En tu aplicación inicializas el cliente apuntando a la URL del servidor y configurando el método de autenticación. En un ejemplo sencillo usarás token estático (el root token de desarrollo, o un token de servicio en un entorno más real), pero en producción lo normal es autenticarse mediante Kubernetes auth, approle, OIDC o LDAP, de forma que no haya secretos fijos enterrados en la aplicación.

Para almacenar un secreto típico (por ejemplo, la contraseña de acceso a una base de datos) utilizarás el engine KV v2 con una llamada a la API o a la librería cliente, enviando clave y valor, más metadatos si te hacen falta. En la ruta que elijas (p. ej. secret/data/app/backend) podrás guardar pares como password: «OpenBao123». Si la operación tiene éxito, la aplicación recibe confirmación y el secreto queda protegido dentro de la bóveda.

Cuando la aplicación necesite usar esa credencial, realiza una operación de lectura sobre la misma ruta, obtiene la respuesta de OpenBao, extrae el valor de la clave (por ejemplo, la contraseña) y lo utiliza en memoria, sin escribirlo en disco ni loguearlo. Si todo va bien, el secreto leído debería coincidir exactamente con el que se guardó en su momento.

Para entornos más avanzados, OpenBao ofrece engines como Transit (cifrado y descifrado como servicio), PKI (emisión de certificados), motores de secretos dinámicos para bases de datos (MySQL, PostgreSQL…), o como autoridad de certificación SSH, además de integración estrecha con Kubernetes, Terraform, Ansible, clouds públicas, Consul y otros componentes de infraestructura.

Panorama de bóvedas de contraseñas y secretos en el ecosistema open source

OpenBao no vive en el vacío; forma parte de un ecosistema muy amplio de bóvedas de contraseñas y gestores de secretos, cada uno con su enfoque. Entender ese panorama ayuda a decidir qué papel debe jugar OpenBao en tu empresa y qué otras piezas pueden complementarlo.

Si hablamos de contraseñas puramente «humanas» (logins de usuarios, acceso a paneles, etc.), hay herramientas que destacan por su simplicidad:

• KeePassXC: un fichero cifrado .kdbx, sin servidor ni base de datos. Se comparte dejando el archivo en un recurso compartido (Nextcloud, Samba, Syncthing…). Es ideal como punto de entrada o fallback offline, con integración con navegadores y apps móviles, soporte para YubiKey y TOTP, y cero complejidad de infraestructura.
• Vaultwarden: reimplementación en Rust del servidor de Bitwarden para self‑hosting ligero. Corre en un único contenedor Docker, consume muy poca memoria y desbloquea funciones de Bitwarden Enterprise (organizaciones, colecciones, grupos) sin coste adicional. Es totalmente compatible con los clientes oficiales de Bitwarden.
• Padloc: gestor con una interfaz moderna y cuidada, diseñado para compartir secretos en grupos pequeños con cifrado de extremo a extremo. Se puede autohospedar con Docker Compose y está orientado a equipos que priorizan la experiencia de usuario por encima de la complejidad de las integraciones empresariales clásicas.
• Bitwarden self‑hosted oficial: probablemente el gestor open source más auditado, con una experiencia de cliente muy pulida. Requiere más recursos que Vaultwarden, pero ofrece SSO empresarial, SCIM, integración con LDAP/AD y políticas avanzadas, lo que lo hace muy adecuado cuando compliance y soporte oficial pesan más que la simplicidad.

Para equipos que necesitan compartir credenciales con controles más finos, hay soluciones como:

• Passbolt Community Edition: centrado en equipos, con cifrado end‑to‑end basado en OpenPGP donde la clave privada nunca sale del dispositivo del usuario. Permite compartir contraseñas con permisos muy granulares, tiene edición comunitaria 100 % libre y cumple bien con GDPR y normativa europea.
• Psono Community Edition: orientado a empresas, con cifrado multinivel (cliente + TLS + almacenamiento), MFA, informes de seguridad e integraciones con LDAP, SAML y OIDC. Además, permite definir callbacks HTTP cuando cambia un secreto, ideal para automatizar acciones de reinicio o despliegues.
• Teampass: gestor colaborativo en PHP y MySQL, muy práctico si ya tienes ese stack. Ofrece una estructura de carpetas con roles y permisos detallados, exportación cifrada offline y auditoría de acciones de usuario, aunque su interfaz sea algo clásica.

Si miramos de nuevo hacia secretos de aplicación, hay proyectos claramente comparables a OpenBao:

• Infisical: plataforma MIT pensada para DevOps y Kubernetes, con soporte nativo para decenas de entornos (Terraform, Ansible, GitHub Actions, AWS…). Cubre gestión de secretos de aplicación, PKI, escaneo de credenciales y prevención de fugas, con modalidad cloud, self‑hosted o híbrida.
• Phase: gestor de secretos moderno con UI muy trabajada y enfoque developer‑first. Ofrece cifrado E2E por entorno (dev/staging/prod) y se integra con Kubernetes, GitHub Actions, Vercel o Docker. Algunas funciones empresariales (SAML/OIDC) requieren licencia.
• CyberArk Conjur OSS: plataforma muy empresarial con foco en «política como código», RBAC granular y autenticación nativa de cargas de trabajo (Kubernetes, AWS IAM, OIDC). La edición OSS proporciona el núcleo y SDKs; la parte de alta disponibilidad, UI web y streaming de auditoría se reserva para la edición enterprise.

Existen también herramientas con filosofías bastante distintas, pero que pueden encajar como complemento:

• AliasVault: gestor de contraseñas privacy‑first con servidor de correo integrado, que genera identidades alternativas (nombre, email, password) para cada web. Es completamente autohospedable y está escrito en .NET + Blazor.
• Password Store (pass): el estándar Unix. Cada contraseña es un fichero .gpg cifrado, versionado con Git y organizado en directorios, lo que permite compartir secretos añadiendo claves públicas GPG a la configuración. Cero servidor y máxima auditabilidad, a costa de una curva de aprendizaje mayor.
• LessPass: paradigma sin estado. No guarda una bóveda cifrada, sino que regenera cada contraseña localmente a partir de un master password y el dominio/login, sin necesidad de sincronización. Muy interesante para reducir la superficie de datos sensibles almacenados.

Por último, no hay que olvidar que, aunque muchas empresas delegan el almacenamiento de contraseñas en servicios remotos fuertemente securizados, hay organizaciones que prefieren mantener la bóveda en local, sin Internet o con acceso muy restringido. Esto aporta control, pero obliga a estar muy encima de las actualizaciones de seguridad: si hay un bug explotable y no parcheas rápido, puedes comprometer la caja fuerte donde guardas todas las claves de la empresa.

OpenBao como pieza clave en una plataforma interna segura

Dentro de una plataforma moderna basada en Kubernetes y GitOps, OpenBao suele convivir con otros componentes como Keycloak, Kong o un gateway de API, sistemas de monitorización y observabilidad, y una capa de infraestructura definida con Terraform/OpenTofu. El rol de la persona de plataforma o SRE es precisamente hacer que el camino más sencillo para los desarrolladores sea también el más seguro.

Ese «camino feliz» pasa por que los servicios se desplieguen en Kubernetes (GKE u otros clústeres) con manifiestos gestionados por Argo CD, y obtengan sus secretos de OpenBao mediante autenticación automática (por ejemplo, el método Kubernetes auth que mapea ServiceAccounts a policies). Así los desarrolladores no tienen que preocuparse de cómo se almacenan ni rotan las credenciales, solo de declarar qué permisos necesita su aplicación.

En este contexto, un equipo con experiencia en Python y Go puede desarrollar tanto la propia infraestructura como servicios de negocio, y al mismo tiempo construir pequeños operadores o controladores que automaticen la gestión de políticas, roles o engines de OpenBao. Se trata de un modelo en el que la plataforma es un «habilitador» que hace de puente entre las necesidades de desarrollo y los requisitos de seguridad y compliance.

Además, OpenBao encaja bien con arquitecturas de seguridad de confianza cero (zero trust), donde nada ni nadie se da por confiable de inicio. Cada solicitud a la API, cada carga de trabajo en Kubernetes o cada pipeline de CI/CD se autentica y autoriza explícitamente, idealmente usando identidades cortas y secretos con TTL contenido, lo que reduce el impacto de fugas o compromisos puntuales.

Mirando todo el panorama —desde la creación de OpenBao como fork de Vault y su alineación con la Linux Foundation, hasta su integración con Kubernetes, GitOps y el resto de bóvedas y gestores de contraseñas open source— queda claro que se ha convertido en una opción muy sólida cuando se busca una gestión de secretos centralizada, extensible y realmente abierta. Si se diseña bien la estrategia de sellado/des‑sellado, se versionan como código políticas y configuración, y se acompaña con buenas prácticas de actualización y auditoría, OpenBao puede convertirse sin problema en la piedra angular de la seguridad de secretos en la empresa.