« Architecture

Vault est un système complexe qui comporte de nombreuses pièces différentes. Pour aider les utilisateurs et les développeurs de Vault à construire un modèle mental de son fonctionnement, cette page documente l’architecture du système.

Avant de décrire l’architecture, nous fournissons un glossaire de termes pour aider à clarifier ce qui est discuté:

• Storage Backend – Un backend de stockage est responsable du stockage durable des données cryptées. Les backends n’ont pas la confiance de Vault et sont seulement censés fournir la durabilité. Le backend de stockage est configuré lors du démarrage du Vaultserver.

• Barrière – La barrière est de l’acier cryptographique et du béton autour duVault. Toutes les données qui circulent entre Vault et le backend de stockage passent par la barrière. La barrière garantit que seules les données cryptées sont écrites à la sortie, et que les données sont vérifiées et décryptées à l’entrée. Un peu comme un coffre-fort bancaire, la barrière doit être « descellée » avant que l’on puisse accéder à quoi que ce soit à l’intérieur.

• Moteur de secrets – Un moteur de secrets est responsable de la gestion des secrets.Les moteurs de secrets simples comme le moteur de secrets « kv » renvoient simplement le même secret lorsqu’ils sont interrogés. Certains moteurs de secrets permettent d’utiliser des politiques pour générer dynamiquement un secret à chaque fois qu’ils sont interrogés. Cela permet d’utiliser des secrets uniques, ce qui permet à Vault d’effectuer des révocations et des mises à jour de politiques à grain fin. Par exemple, un moteur de secrets MySQL pourrait être configuré avec une politique « web ». Lorsque le secret « web » est lu, une nouvelle paire utilisateur/mot de passe MySQL sera générée avec un ensemble limité de privilèges pour le serveur web.

• Dispositif d’audit – Un dispositif d’audit est responsable de la gestion des journaux d’audit.Chaque demande à Vault et réponse de Vault passe par les dispositifs d’audit configurés. Cela fournit un moyen simple d’intégrer Vault avec plusieurs destinations de journalisation d’audit de différents types.

• Méthode d’authentification – Une méthode d’authentification est utilisée pour authentifier les utilisateurs ou les applications qui se connectent à Vault. Une fois authentifiée, la méthode auth renvoie la liste des politiques applicables qui doivent être appliquées. Vault prend un utilisateur authentifié et renvoie un jeton client qui peut être utilisé pour les demandes futures. À titre d’exemple, la méthode userpass auth utilise un nom d’utilisateur et un mot de passe pour authentifier l’utilisateur. Alternativement, la méthode github authpermet aux utilisateurs de s’authentifier via GitHub.

• Tocken client – Un token client (alias « Vault Token ») est conceptuellementsimilaire à un cookie de session sur un site web. Une fois qu’un utilisateur s’est authentifié, Vault renvoie un jeton client qui est utilisé pour les futures demandes. Le jeton est utilisé par Vault pour vérifier l’identité du client et pour appliquer les politiques ACL applicables. Ce jeton est transmis via les en-têtes HTTP.

• Secret – Un secret est le terme pour tout ce qui est renvoyé par Vault et qui contient du matériel confidentiel ou cryptographique. Tout ce qui est renvoyé parVault n’est pas un secret, par exemple la configuration du système, les informations d’état ou les politiques ne sont pas considérées comme des secrets. Les secrets sont toujours associés à un bail, ce qui signifie que les clients ne peuvent pas supposer que le contenu du secret peut être utilisé indéfiniment. Vault révoque un secret à la fin du bail, et un opérateur peut intervenir pour révoquer le secret avant la fin du bail. Ce contrat entre Vault et ses clients est critique, car il permet de modifier les clés et les politiques sans intervention manuelle.

• Serveur – Vault dépend d’une instance à long terme qui fonctionne comme serveur. Le serveur Vault fournit une API avec laquelle les clients interagissent et gère l’interaction entre tous les moteurs de secrets, l’application des ACL et la révocation des baux de secrets. Le fait d’avoir une architecture basée sur un serveur découple les clients des clés et des politiques de sécurité, permet une journalisation centralisée des audits et simplifie l’administration pour les opérateurs.

« Vue d’ensemble de haut niveau

Une vue d’ensemble de très haut niveau de Vault ressemble à ceci:

Commençons à décomposer cette image. Il y a une séparation claire des composants qui sont à l’intérieur ou à l’extérieur de la barrière de sécurité. Seuls le backend de stockage et l’API HTTP sont à l’extérieur, tous les autres composants sont à l’intérieur de la barrière.

Le backend de stockage n’est pas fiable et est utilisé pour stocker durablement des données cryptées.Lorsque le serveur Vault est démarré, il doit être fourni avec un backend de stockage afin que les données soient disponibles lors des redémarrages. De même, l’API HTTP doit être lancée par le serveur Vault au démarrage pour que les clients puissent interagir avec elle.

Une fois démarrée, la chambre forte est dans un état scellé. Avant que toute opération puisse être effectuée sur la chambre forte, elle doit être descellée. Ceci est fait en fournissant les unsealkeys. Lorsque la chambre forte est initialisée, elle génère une clé de chiffrement qui est utilisée pour protéger toutes les données. Cette clé est protégée par une clé principale. Par défaut,Vault utilise une technique connue sous le nom d’algorithme de partage de secret de Shamir pour diviser la clé maîtresse en 5 parts, dont 3 quelconques sont nécessaires pour reconstruire la clé maîtresse.

Le nombre de parts et le seuil minimum requis peuvent tous deux être spécifiés.La technique de Shamir peut être désactivée, et la clé maîtresse utilisée directement pour le descellement. Une fois que Vault a récupéré la clé de chiffrement, il est capable de déchiffrer les données dans le backend de stockage, et entre dans l’état non scellé. Une fois descellé,Vault charge tous les dispositifs d’audit, méthodes d’authentification et moteurs de secrets configurés.

La configuration de ces dispositifs d’audit, méthodes d’authentification et moteurs de secrets doit être stockée dans Vault car ils sont sensibles à la sécurité. Seuls les utilisateurs disposant des autorisationscorrectes doivent pouvoir les modifier, ce qui signifie qu’ils ne peuvent pas être spécifiés en dehors de la barrière. En les stockant dans Vault, toute modification de ceux-ci est protégée par le système ACL et suivie par les journaux d’audit.

Après que Vault soit descellé, les demandes peuvent être traitées depuis l’API HTTP vers leCore. Le noyau est utilisé pour gérer le flux de demandes à travers le système,appliquer les ACL et s’assurer que la journalisation des audits est effectuée.

Lorsqu’un client se connecte pour la première fois à Vault, il doit s’authentifier. Vault fournit des méthodes d’authentification configurables offrant une flexibilité dans le mécanisme d’authentification utilisé. Des mécanismes conviviaux tels que nom d’utilisateur/mot de passe ou GitHub peuvent être utilisés pour les opérateurs, tandis que les applications peuvent utiliser des clés publiques/privées ou des jetons pour s’authentifier. Une demande d’authentification traverse le noyau et entre dans une méthode d’authentification, qui détermine si la demande est valide et renvoie une liste de politiques associées.

Les politiques sont simplement une règle ACL nommée. Par exemple, la politique « root » est intégrée et permet l’accès à toutes les ressources. Vous pouvez créer un nombre quelconque de politiques nomméesavec un contrôle fin sur les chemins. Vault fonctionne exclusivement en mode liste blanche, ce qui signifie que si l’accès n’est pas explicitement accordé par une politique, l’action n’est pas autorisée. Étant donné qu’un utilisateur peut être associé à plusieurs politiques, une action est autorisée si l’une d’entre elles le permet. Les politiques sont stockées et gérées par un magasin de politiques interne. Ce magasin interne est manipulé par le backend du système, qui est toujours monté à sys/.

Une fois que l’authentification a lieu et qu’une méthode d’authentification fournit un ensemble de politiques applicables, un nouveau jeton client est généré et géré par le magasin de jetons. Ce jeton client est renvoyé au client, et est utilisé pour effectuer de futures demandes.Cela est similaire à un cookie envoyé par un site Web après qu’un utilisateur se soit connecté. Le jeton client peut être associé à un bail en fonction de la configuration de la méthode d’authentification. Cela signifie que le jeton client peut devoir être renouvelé périodiquement pour éviter l’invalidation.

Une fois authentifié, les demandes sont faites en fournissant le jeton client. Le jeton est utilisé pour vérifier que le client est autorisé et pour charger les politiques pertinentes. Les politiques sont utilisées pour autoriser la demande du client. La demande est ensuite acheminée vers le moteur de secrets, qui est traité en fonction de son type. Si le moteur de secrets renvoie un secret, le noyau l’enregistre auprès du gestionnaire d’expiration et y joint un ID de location. L’ID de bail est utilisé par les clients pour renouveler ou révoquer leur secret. Si un client permet au bail d’expirer, le gestionnaire d’expiration révoque automatiquement le secret.

Le noyau gère la journalisation des demandes et des réponses au courtier d’audit, qui diffuse la demande à tous les dispositifs d’audit configurés. En dehors du flux de demandes, le noyau effectue certaines activités de fond. La gestion des baux est essentielle, car elle permet de révoquer automatiquement les jetons ou les secrets des clients arrivés à expiration. En outre, Vault gère certains cas d’échec partiel en utilisant la journalisation en écriture anticipée avec un gestionnaire de retour en arrière. Ceci est géré de manière transparente au sein du noyau et n’est pas visible par l’utilisateur.

« Getting in Depth

Ceci a été un bref aperçu de haut niveau de l’architecture de Vault. Il y a plus de détails disponibles pour chacun des sous-systèmes.

Pour d’autres détails, consultez le code, demandez sur IRC ou adressez-vous à la liste de diffusion.