Vault o el gestor de secretos de tu nube

Los dos fracasos no se parecen en nada y cuestan más o menos lo mismo. El primero es un equipo de plataforma de cinco personas operando un clúster de Vault de tres nodos, con almacenamiento Raft, desellado automático, un clúster de Consul que nadie recuerda por qué se desplegó y un atraso de once versiones menores en actualizaciones, todo para guardar noventa secretos estáticos que no cambian nunca. El segundo es una empresa que apostó todo por el gestor de secretos de AWS, después compró un negocio que corría sobre Azure y una planta de fábrica con servicios en local, y ahora tiene tres almacenes de secretos, tres modelos de acceso y ningún rastro de auditoría unificado.

Los dos equipos preguntaron "qué producto es mejor". Esa pregunta no tiene respuesta. Hay cuatro que sí la tienen.

Las cuatro preguntas que lo deciden

¿Eres multinube de verdad, o solo lo dices? De verdad significa cargas en producción en dos o más nubes que necesitan el mismo secreto, o una hoja de ruta de adquisiciones que va a producir eso dentro de un año. Si todo corre en una nube y va a seguir así, el gestor gestionado gana solo por coste operativo, y no está ni cerca.

¿Necesitas credenciales dinámicas de vida corta? No "estaría bien tenerlas". ¿Tienes bases de datos donde una contraseña de larga vida comprometida es un incidente serio, y tus aplicaciones toleran una credencial que caduca? Este es el argumento más fuerte a favor de Vault y volvemos a él más abajo.

¿Tienes cargas fuera de cualquier nube? Hierro desnudo, equipamiento industrial, portátiles de desarrollo, un armario en un centro de datos, ejecutores de integración continua que alojas tú. Los gestores de secretos de las nubes pueden servirlos, pero la parte de autenticación se pone incómoda rápido: acabas con una credencial de nube de larga vida en la máquina para poder ir a buscar los secretos, que es el problema que querías resolver. Los métodos de autenticación de Vault se diseñaron exactamente para esto.

¿Quién lo opera a las tres de la madrugada? Vault es un sistema distribuido con estado que guarda las llaves de todo. Eso es superficie de guardia real. Si tu equipo de plataforma son tres personas que además son dueñas de los clústeres de Kubernetes y de la integración continua, añadir Vault es una decisión sobre sus próximos dos años, no una comparativa de producto.

Lo que cuesta operar Vault de verdad

La instalación es una tarde. La operación es permanente.

Sellado y desellado. Un Vault reiniciado arranca sellado y no sirve nada hasta que se desella. Repartir fragmentos de clave entre cinco personas es un modelo de seguridad precioso y un modelo de disponibilidad terrible a las tres de la madrugada. En la práctica todo el mundo usa desellado automático respaldado por el servicio de claves de una nube, que es lo correcto, y que significa que tu almacén de secretos "independiente de la nube" tiene ahora una dependencia dura de una clave gestionada por una nube. Protege esa clave con una política de protección contra borrado y replícala si tu proveedor lo permite, porque perderla es perder el vault.

Alta disponibilidad y almacenamiento. El almacenamiento Raft integrado eliminó la dependencia de Consul, que fue la mayor mejora operativa que ha tenido Vault. Sigues ejecutando un número impar de nodos repartidos entre zonas, sigues tomando y probando copias de la instantánea de Raft, y sigues necesitando saber cómo recuperar un quórum perdido antes de necesitar saberlo.

Actualizaciones. Vault publica con frecuencia y la diferencia de versión entre tu clúster y tus librerías cliente importa. Los equipos que se quedan atrás se quedan atrás, porque la actualización da miedo en proporción al tiempo que lleva sin hacerse.

Proliferación de políticas. El lenguaje de políticas de Vault es potente y no está gobernado por defecto. Sin un proceso de revisión, en seis meses tienes un comodín en una ruta de una política.

Presupuesta un ingeniero entre un quinto y la mitad de su tiempo para operar esto bien, más la licencia empresarial si necesitas espacios de nombres, replicación o soporte de módulos de hardware. Ese número es el punto de comparación honesto, no el coste del software.

Lo que cuesta lo gestionado, y dónde sorprende

Los servicios gestionados cobran más o menos por dos ejes: un cargo mensual por secreto almacenado y un cargo por llamada a la API. Los dos son números pequeños. Ninguno lo es a escala.

El cargo por secreto pilla a los equipos que generan secretos por programa: una credencial por inquilino, por entorno, por despliegue de vista previa efímero. Diez mil secretos a una tarifa mensual por secreto es una línea sobre la que alguien va a preguntar. El cargo por llamada pilla a los equipos cuyas aplicaciones piden el secreto en cada petición en vez de cachearlo, y cuyo controlador de almacenamiento en Kubernetes relee a intervalos cortos. Comprueba las páginas de precios actuales antes de modelar esto, porque las tarifas y los niveles gratuitos cambian, pero modélalo: el modo de fallo es que nadie se da cuenta hasta que llega la factura.

El otro coste es la portabilidad. Los secretos en sí se mueven con facilidad; lo que no se mueve es todo lo cableado alrededor. Las políticas de identidad que dan acceso, las políticas de recurso, la función de rotación automática, la clave que los cifra, la configuración del controlador de almacenamiento, las referencias incrustadas en cien definiciones de tarea. Migrar hacia fuera es un trimestre de trabajo, no un fin de semana.

Las credenciales dinámicas de base de datos son el argumento real

Todo lo anterior es un intercambio. Esta es la capacidad sin equivalente gestionado que funcione igual.

El motor de secretos de base de datos de Vault guarda una credencial privilegiada, y cuando una aplicación se autentica, Vault crea un usuario de base de datos nuevo con un tiempo de vida definido, se lo entrega y lo elimina cuando el arrendamiento caduca. Cada instancia de aplicación recibe una credencial distinta. No existe nada de larga vida que robar, no hay nada que rotar, y el registro de auditoría te dice qué identidad pidió qué credencial y cuándo. Revocar el acceso de una carga comprometida es revocar un arrendamiento, no cambiar una contraseña y coordinar un reinicio.

El mismo patrón existe para credenciales de nube, SSH, certificados de infraestructura de clave pública y sistemas de mensajería. El motor de certificados en particular es la forma en que muchas organizaciones acaban teniendo certificados TLS internos de vida corta sin comprar un producto aparte.

La trampa es que tu aplicación tiene que poder reconectar con una credencial nueva cuando el arrendamiento rota, y tu base de datos tiene que tolerar la rotación de usuarios. Las librerías de agrupación de conexiones que leen la contraseña una vez al arrancar se van a romper, y averiguar cuáles de tus servicios hacen eso es el trabajo real de la migración.

Lo que se olvida

• El gestor de secretos no es la frontera; la identidad sí. Un secreto perfectamente cifrado que puede leer un rol que media organización puede asumir no está protegido. Acota el acceso de lectura por carga de trabajo y comprueba quién lo lee de verdad.
• Los registros de auditoría necesitan destino. Vault se niega a servir peticiones si no puede escribir su registro de auditoría, que es el comportamiento correcto y una caída sorprendente la primera vez que se llena el disco. Envíalos fuera de la máquina.
• Acceso de emergencia. Deja escrito, y prueba, cómo sacas un secreto cuando el proveedor de identidad o el clúster están caídos. Si la respuesta es "no podemos", ese es tu próximo incidente.
• Las aplicaciones que van a buscar secretos necesitan una identidad primero. Resuelve eso con federación de identidad en la integración continua e identidad de carga de trabajo en el clúster, no con una contraseña de arranque en una variable de entorno.
• Un almacén de secretos no rota nada por sí mismo. Eso es otro programa de trabajo y es donde está la mayor parte del valor; está en la rotación que sí funciona.

La respuesta que desplegamos más a menudo

Para un entorno de una sola nube con secretos mayoritariamente estáticos: el servicio gestionado, con identidad por carga de trabajo, cifrado con clave propia y replicación configurada. No construyas una plataforma para evitar un problema que no tienes.

Para un entorno multinube o híbrido, o uno donde comprometer una credencial de base de datos sea un riesgo principal: Vault, operado en serio, con los servicios gestionados usados igualmente como ancla de confianza para el desellado automático. Dimensionamos el compromiso operativo con honestidad durante el proyecto de seguridad, antes de que nadie instale nada.

Qué hacer esta semana

Cuenta tus secretos y clasifica cada uno como estático, rotable o apto para dinámico. Exporta la lista del almacén que uses hoy, etiqueta cada entrada y suma la columna de aptos para dinámico. Si está cerca de cero, el argumento más fuerte de Vault no te aplica y la decisión acaba de volverse fácil.