OpenBao 2.5 en pymes: secretos, tokens y auditoria
OpenBao separa secretos de planillas y scripts. Como instalarlo, sellarlo, registrar auditoria, definir permisos y probar recuperacion sin exponer credenciales.
Un token que vive en un script puede seguir firmando pedidos meses despues de que cambio el proveedor. OpenBao 2.5 guarda secretos, certificados y llaves, entrega accesos con politica y registra cada pedido de la API. En una concesionaria sobre Ruta 40, ese control separa soporte, administracion y proveedores sin recorrer carpetas viejas. Esta guia explica donde vive el secreto, quien lo lee y como se prueba una salida.
Donde aparece el secreto copiado
La cifra que corrige la costumbre esta en el motor KV: la documentacion 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 version, politica, 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 mas 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 tecnicos 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, administracion 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 mas de 6.000 estrellas y licencia MPL-2.0. Esa informacion no convierte al producto en solucion terminada; solo confirma que hay un proyecto activo que conviene instalar con controles propios.
Como funciona por dentro
El flujo minimo 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 metodos de autenticacion para administradores, proveedores y aplicaciones. Cuarto, carga secretos en KV v2 con rutas por area. Quinto, las politicas dicen quien lee, escribe, lista, borra o destruye versiones. Sexto, el audit device registra pedidos y respuestas. Septimo, el backup copia almacenamiento, configuracion y claves de recuperacion, y se prueba en una maquina aislada.
OpenBao recibe credenciales, consulta politica y entrega un secreto, token o certificado. El almacenamiento fisico conserva datos cifrados y metadatos. El audit device recibe cada operacion de API y escribe registros JSON; segun la guia de auditoria, los strings sensibles se registran con HMAC-SHA256 por defecto. El proceso de sellado bloquea el acceso a datos cifrados hasta que 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 auditoria, 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 version requiere permiso separado y acta breve.
Que se instala o configura primero
La pila inicial usa OpenBao 2.5.x, almacenamiento persistente, HTTPS, autenticacion 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 dolar vendedor oficial de $1.409 informado por Bluelytics. Incluye instalacion, rutas, politicas, carga inicial, auditoria, salida de proveedor y restauracion.
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 restauracion que lea una version 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 revision y prueba de rotacion. Ese listado evita que una baja laboral quede atada a una cuenta tecnica.
Donde se rompe y como probarlo
Primer riesgo: partes de desbloqueo guardadas por una sola persona. La senal aparece cuando una ausencia impide levantar el servicio. La prueba pide desbloqueo con responsables distintos y registra hora. Segundo riesgo: politicas amplias. La senal es un usuario de compras leyendo secretos de backups. La prueba usa perfiles reales y fuerza lectura permitida, lectura rechazada y rotacion.
Tercer riesgo: audit device bloqueado. La documentacion advierte que OpenBao puede dejar de responder si ningun dispositivo de auditoria registra pedidos. La prueba llena el destino de log en ambiente aislado y confirma alerta. Cuarto riesgo: backup sin configuracion. La prueba restaura almacenamiento y politicas, abre un secreto versionado y revisa el log. Un secreto ordenado deja una accion visible cuando alguien se va.