Vault is an intricate system with numerous distinct components. This page details the system architecture and hopes to assist Vault users and developers to build a mental model while understanding the theory of operation.
~> **Note:** This page covers the technical details of Vault. The descriptions and elements contained within are for users that wish to learn about Vault without having to reference the source code. Although not required, we encourage all users and operators to review the provided information before using Vault due to its significance in an environment.
Vault’s encryption layer, referred to as the _barrier_, is responsible for encrypting and decrypting Vault data. When the Vault server starts, it writes data to its storage backend. Since the storage backend resides outside the barrier, it’s considered untrusted so Vault will encrypt the data before it sends them to the storage backend. This mechanism ensures that if a malicious attacker attempts to gain access to the storage backend, the data cannot be compromised since it remains encrypted, until Vault decrypts the data. The storage backend provides a durable data persistent layer where data is secured and available across server restarts.
The configuration of the audit devices, auth methods, and secrets engines are security sensitive and are stored in Vault. Users with permissions can modify them and cannot be specified outside of the barrier. By storing them in Vault, changes are protected by the ACL system and tracked by audit logs.
and permits access to all resources. You may create any number of named policies
with fine-grained control over paths. Vault operates in an allowed-access mode, meaning the action is not allowed unless access is granted via a policy explicitly. Since a user may have multiple policies associated, actions are allowed when policy permits. Policies are stored and managed by an internal
policy store. This internal store is affected through the system backend,
This token method is similar to a cookie sent by a website when a user logs in. Depending on the auth method configuration, the client
token may have a lease associated with it, and may need to be renewed periodically to avoid invalidation.
Once authenticated, requests are made by providing the client token. The client token is
used to verify the client, ensuring they are authorized while loading the relevant policies. The
policies are used to authorize the client request. The request is then routed to the secrets engine, which is processed depending on its type. When the secrets engine returns the secret, the core registers it with the expiration manager and attaches a lease ID. Clients use the lease ID to renew or revoke their
secret. The expiration manager automatically revokes the secret if a client allows the lease to expire.
The core logs requests and responses to the audit broker, distributing the requests to all configured audit devices. Outside of the request
flow, the core performs specific background activities. Lease management is critical, allowing expired client tokens or secrets to be revoked automatically. Additionally, Vault handles specific partial-failure cases by using write-ahead logging with a rollback manager. This is managed transparently within the core and is not user-visible.
