«Arquitectura

Vault es un sistema complejo que tiene muchas piezas diferentes. Para ayudar a los usuarios y desarrolladores de Vault a construir un modelo mental de cómo funciona, esta página documenta la arquitectura del sistema.

Antes de describir la arquitectura, proporcionamos un glosario de términos para ayudar a aclarar lo que se está discutiendo:

• Storage Backend – Un backend de almacenamiento es responsable del almacenamiento duradero de los datos cifrados. Vault no confía en los backends y sólo se espera que proporcionen durabilidad. El backend de almacenamiento se configura al iniciar el Vaultserver.

• Barrera – La barrera es de acero criptográfico y de hormigón alrededor del Vault. Todos los datos que fluyen entre Vault y el backend de almacenamiento pasan por la barrera. La barrera asegura que sólo los datos encriptados se escriben, y que los datos se verifican y descifran al entrar. Al igual que una bóveda bancaria, la barrera debe ser «desprecintada» antes de que se pueda acceder a todo lo que hay dentro.

• Motor de secretos – Un motor de secretos es responsable de gestionar los secretos.Los motores de secretos simples, como el motor de secretos «kv», simplemente devuelven el mismo secreto cuando se les consulta. Algunos motores de secretos soportan el uso de políticas para generar dinámicamente un secreto cada vez que son consultados. Esto permite que se utilicen secretos únicos, lo que permite a Vault realizar revocaciones y actualizaciones de políticas muy precisas. Como ejemplo, un motor de secretos de MySQL podría configurarse con una política «web». Cuando se lee el secreto «web», se genera un nuevo par usuario/contraseña de MySQL con un conjunto limitado de privilegios para el servidor web.

• Dispositivo de auditoría – Un dispositivo de auditoría es responsable de gestionar los registros de auditoría. Esto proporciona una forma sencilla de integrar Vault con múltiples destinos de registro de auditoría de diferentes tipos.

• Método de autenticación – Un método de autenticación se utiliza para autenticar a los usuarios o aplicaciones que se conectan a Vault. Una vez autenticado, el método auth devuelve la lista de políticas aplicables que deben aplicarse. Vault toma un usuario autenticado y devuelve un token de cliente que puede ser utilizado para futuras solicitudes. Por ejemplo, el método auth userpass utiliza un nombre de usuario y una contraseña para autenticar al usuario. Alternativamente, el método github auth permite a los usuarios autenticarse a través de GitHub.

• Token de cliente – Un token de cliente (también conocido como «Vault Token») es conceptualmente similar a una cookie de sesión en un sitio web. Una vez que el usuario se autentifica, Vault devuelve un token de cliente que se utiliza para futuras solicitudes. El token es utilizado por Vault para verificar la identidad del cliente y hacer cumplir las políticas ACL aplicables. Este token se pasa a través de las cabeceras HTTP.

• Secreto – Un secreto es el término para cualquier cosa devuelta por Vault que contenga material confidencial o criptográfico. No todo lo que devuelve Vault es un secreto, por ejemplo, la configuración del sistema, la información de estado o las políticas no se consideran secretos. Los secretos siempre tienen un contrato de arrendamiento asociado, lo que significa que los clientes no pueden asumir que el contenido del secreto puede ser utilizado indefinidamente. Vault revocará un secreto al final del contrato de arrendamiento, y un operador puede intervenir para revocar el secreto antes de que termine el contrato. Este contrato entre Vault y sus clientes es crítico, ya que permite cambios en las claves y políticas sin intervención manual.

• Servidor – Vault depende de una instancia de larga duración que opera como servidor. El servidor de Vault proporciona una API con la que los clientes interactúan y gestiona la interacción entre todos los motores de secretos, la aplicación de las ACL y la revocación del alquiler de secretos. Tener una arquitectura basada en el servidor desvincula a los clientes de las claves y políticas de seguridad, permite un registro de auditoría centralizado y simplifica la administración para los operadores.

«Visión general de alto nivel

Una visión general de muy alto nivel de Vault se ve así:

Empecemos a desglosar esta imagen. Hay una clara separación de los componentes que están dentro o fuera de la barrera de seguridad. Sólo el backend de almacenamiento y la API HTTP están fuera, todos los demás componentes están dentro de la barrera.

El backend de almacenamiento no es de confianza y se utiliza para almacenar de forma duradera los datos encriptados.Cuando se inicia el servidor de Vault, se le debe proporcionar un backend de almacenamiento para que los datos estén disponibles en los reinicios. La API HTTP también debe ser iniciada por el servidor de Vault en el arranque para que los clientes puedan interactuar con ella.

Una vez iniciado, el Vault se encuentra en un estado sellado. Antes de poder realizar cualquier operación en el Vault, éste debe ser desprecintado. Esto se hace proporcionando las llaves de desprecintado. Cuando el Vault se inicializa, genera una clave de cifrado que se utiliza para proteger todos los datos. Esa clave está protegida por una clave maestra. Por defecto, Vault utiliza una técnica conocida como algoritmo de compartición de secretos de Shamir para dividir la clave maestra en 5 partes, 3 de las cuales son necesarias para reconstruir la clave maestra.

El número de partes y el umbral mínimo requerido pueden ser especificados.La técnica de Shamir puede ser desactivada, y la clave maestra utilizada directamente para el desprecintado. Una vez que Vault recupera la clave de cifrado, es capaz de descifrar los datos en el backend de almacenamiento, y entra en el estado de desprecintado. Una vez desprecintado, Vault carga todos los dispositivos de auditoría, métodos de autentificación y motores de secretos configurados.

La configuración de estos dispositivos de auditoría, métodos de autentificación y motores de secretos debe almacenarse en Vault, ya que son sensibles desde el punto de vista de la seguridad. Sólo los usuarios con los permisos correctos deben ser capaces de modificarlos, lo que significa que no pueden ser especificados fuera de la barrera. Al almacenarlos en Vault, cualquier cambio en ellos está protegido por el sistema ACL y es rastreado por los registros de auditoría.

Después de que la Vault es desprecintada, las solicitudes pueden ser procesadas desde la API HTTP hasta elCore. El núcleo se utiliza para gestionar el flujo de solicitudes a través del sistema, hacer cumplir las ACL y garantizar el registro de auditoría.

Cuando un cliente se conecta por primera vez a Vault, necesita autenticarse. Vault proporciona métodos de autenticación configurables que proporcionan flexibilidad en el mecanismo de autenticación utilizado. Mecanismos amigables como nombre de usuario/contraseña o GitHub pueden ser utilizados por los operadores, mientras que las aplicaciones pueden utilizar claves públicas/privadas o tokens para autenticarse. Una solicitud de autenticación fluye a través del núcleo y en un método de autenticación, que determina si la solicitud es válida y devuelve una lista de políticas asociadas.

Las políticas son sólo una regla ACL con nombre. Por ejemplo, la política «root» está incorporada y permite el acceso a todos los recursos. Se puede crear cualquier número de políticas con nombre con un control detallado de las rutas. Vault funciona exclusivamente en modo de lista blanca, lo que significa que a menos que el acceso se conceda explícitamente a través de una política, la acción no está permitida. Dado que un usuario puede tener varias políticas asociadas, una acción se permite si cualquier política lo permite. Las políticas se almacenan y gestionan en un almacén interno de políticas. Este almacén interno se manipula a través del backend del sistema, que siempre está montado en sys/.

Una vez que la autenticación se lleva a cabo y un método de autenticación proporciona un conjunto de políticas aplicables, un nuevo token de cliente es generado y gestionado por el almacén de tokens. Este token de cliente se devuelve al cliente y se utiliza para realizar futuras solicitudes, de forma similar a una cookie enviada por un sitio web después de que un usuario inicie sesión. El token de cliente puede tener un contrato de arrendamiento asociado, dependiendo de la configuración del método de autenticación. Esto significa que el token de cliente puede necesitar ser renovado periódicamente para evitar su invalidación.

Una vez autenticado, las solicitudes se realizan proporcionando el token de cliente. El token se utiliza para verificar que el cliente está autorizado y para cargar las políticas pertinentes. Las políticas se utilizan para autorizar la solicitud del cliente. A continuación, la solicitud se dirige al motor de secretos, que se procesa en función de su tipo. Si el motor de secretos devuelve un secreto, el núcleo lo registra en el gestor de caducidad y le asigna un ID de arrendamiento. El ID de arrendamiento es utilizado por los clientes para renovar o revocar su secreto. Si un cliente permite que el contrato de arrendamiento caduque, el gestor de caducidad revoca automáticamente el secreto.

El núcleo maneja el registro de las solicitudes y las respuestas al agente de auditoría, que envía la solicitud a todos los dispositivos de auditoría configurados. Fuera del flujo de solicitudes, el núcleo realiza ciertas actividades de fondo. La gestión de los contratos de arrendamiento es crítica, ya que permite revocar automáticamente los tokens o secretos de los clientes que hayan expirado. Además, Vault gestiona ciertos casos de fallos parciales utilizando el registro de escritura anticipada con un gestor de reversión. Esto se gestiona de forma transparente dentro del núcleo y no es visible para el usuario.

«Profundizando en el tema

Esta ha sido una breve descripción de alto nivel de la arquitectura de Vault. Hay más detalles disponibles para cada uno de los subsistemas.

Para otros detalles, consulte el código, pregunte en el IRC o llegue a la lista de correo.