OpenBao 2.5 en pymes: secretos, tokens y auditoría
OpenBao separa secretos de planillas y scripts. Como instalarlo, sellarlo, registrar auditoría, definir permisos y probar recuperacion sin exponer credenciales.
Un token que vive en un script puede seguir firmando pedidos meses después de que cambio el proveedor. OpenBao 2.5 guarda secretos, certificados y llaves, entrega accesos con política y registra cada pedido de la API. En una concesionaria sobre Ruta 40, ese control separa soporte, administración y proveedores sin recorrer carpetas viejas. Esta guía explica donde vive el secreto, quién lo lee y cómo se prueba una salida.
Dónde aparece el secreto copiado
La cifra que corrige la costumbre esta en el motor KV: la documentación de OpenBao indica que KV v2 conserva por defecto 10 versiones de cada entrada. Una planilla compartida conserva todas las copias que nadie puede ver. Un gestor de secretos muestra versión, política, lectura y borrado con permisos distintos. El secreto pegado en un chat dura mas que el proveedor. La escala global ayuda a medir el tamano del problema. Octoverse 2025 informo más de 180 millones de desarrolladores y 630 millones de repositorios. La pyme cuyana tiene menos repositorios, pero comparte la misma friccion: scripts, integraciones, API keys, certificados y usuarios técnicos cambian de manos sin dejar rastro suficiente.
La planilla de passwords pierde dueño
El antagonista es la planilla donde cada fila mezcla servicio, usuario, proveedor, fecha y una nota escrita a mano. En una concesionaria de Tunuyan, compras puede necesitar acceso a portales de repuestos, administración a facturacion y sistemas a backups. Una etiqueta adhesiva con el nombre del proveedor queda pegada en una carpeta de garantias; el sistema debe decir si ese proveedor conserva permiso. OpenBao v2.5.3, publicado el 20 de abril de 2026, corrigio fallas de seguridad sobre tokens, certificados, namespaces y rutas. El repositorio publico muestra más de 6.000 estrellas y licencia MPL-2.0. Esa información no convierte al producto en solución terminada; solo confirma que hay un proyecto activo qué conviene instalar con controles propios.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, IT instala OpenBao desde paquete, contenedor o binario y define almacenamiento persistente. Segundo, inicializa el servidor y guarda las partes de desbloqueo con responsables separados. Tercero, crea métodos de autenticación para administradores, proveedores y aplicaciones. Cuarto, carga secretos en KV v2 con rutas por área. Quinto, las políticas dicen quién lee, escribe, lista, borra o destruye versiones. Sexto, el audit device registra pedidos y respuestas. Septimo, el backup copia almacenamiento, configuración y claves de recuperacion, y se prueba en una maquina aislada. OpenBao recibe credenciales, consulta política y entrega un secreto, token o certificado. El almacenamiento físico conserva datos cifrados y metadatos. El audit device recibe cada operación de API y escribe registros JSON; segun la guía de auditoría, los strings sensibles se registran con HMAC-SHA256 por defecto. El proceso de sellado bloquea el acceso a datos cifrados hasta qué se reconstruye la llave necesaria. Si falla OpenBao, las aplicaciones que piden secretos nuevos quedan sin respuesta. Si falla el almacenamiento, se pierde el historial. Si falla auditoría, OpenBao puede bloquear pedidos. Los permisos se disenan por ruta. Soporte lee secretos de mesa de ayuda. Compras lee portales de proveedores. Sistemas rota tokens. Gerencia solo lee reportes. Destruir una versión requiere permiso separado y acta breve.
Qué se instala o configura primero
La pila inicial usa OpenBao 2.5.x, almacenamiento persistente, HTTPS, autenticación de administradores, KV v2, dos audit devices, backup diario y monitoreo de salud. El piloto cuesta entre USD 1.400 y USD 3.800, entre ARS 1,97 y 5,35 millones al dólar vendedor oficial de $1.409 informado por Bluelytics. Incluye instalación, rutas, políticas, carga inicial, auditoría, salida de proveedor y restauración. El plazo va de tres a cinco semanas. UMSA suele pedir un entregable verificable: treinta secretos migrados, cinco rutas, cuatro perfiles, dos proveedores con vencimiento, audit log descargable, un secreto rotado y una restauración que lea una versión anterior. El costo no incluye HSM ni reemplazo de sistemas de identidad. El primer entregable debe cortar el secreto de uso mas frecuente. Si el portal de repuestos usa una API key, el valor se carga en OpenBao, se asigna a compras y sistemas, y se prueba un acceso denegado con un usuario ajeno. El segundo entregable revisa vencimientos. Cada secreto de proveedor queda con dueno, fecha de revisión y prueba de rotación. Ese listado evita que una baja laboral quede atada a una cuenta técnica.
Dónde se rompe y cómo probarlo Primer riesgo: partes de desbloqueo guardadas por una sola persona.
La señal aparece cuando una ausencia impide levantar el servicio. La prueba pide desbloqueo con responsables distintos y registra hora. Segundo riesgo: políticas amplias. La señal es un usuario de compras leyendo secretos de backups. La prueba usa perfiles reales y fuerza lectura permitida, lectura rechazada y rotación. Tercer riesgo: audit device bloqueado. La documentación advierte que OpenBao puede dejar de responder si ningun dispositivo de auditoría registra pedidos. La prueba llena el destino de log en ambiente aislado y confirma alerta. Cuarto riesgo: backup sin configuración. La prueba restaura almacenamiento y políticas, abre un secreto versionado y revisa el log. Un secreto ordenado deja una acción visible cuando alguien se va.