Skip to main content
In this lesson, we’ll examine HashiCorp Vault’s core architecture, how it secures data, and the path-based routing that directs requests to the appropriate internal component. Understanding these fundamentals will help you design, operate, and troubleshoot Vault more effectively.

​
Vault Architecture

Vault exposes its functionality exclusively through an HTTPS API. Clients—whether humans or applications—authenticate and interact with Vault over secure TLS connections. Internally, Vault consists of:
  • Storage Backend
    A durable, encrypted storage layer. Vault supports Consul, DynamoDB, AWS S3, and more. In development mode, an in-memory backend is used. Vault always writes encrypted data to the backend.
  • Core Components
    These include the policy store, audit devices, system backend, secrets engines, authentication methods, and the path-routing logic that connects them.
  • Cryptographic Barrier
    This barrier ensures that all data crossing the boundary between the untrusted storage/network and Vault’s trusted core is automatically encrypted or decrypted. Only authenticated requests carrying valid tokens or credentials may traverse this barrier.
The image illustrates the architecture of a Vault system, showing components like the core, token store, audit devices, and storage backend, along with API interaction and encrypted storage.
Vault does not trust external storage or transport. Before any data is written to the backend, it passes through the cryptographic barrier and is encrypted. Likewise, data fetched from storage or received over the network is decrypted only if the caller is properly authenticated.

​
Vault Paths and Routing

Every Vault request is routed based on its path prefix. The path determines which component handles the request:
  • Secrets Engines (e.g., kv, database, aws)
  • Auth Methods (e.g., userpass, github, aws)
  • Audit Devices (e.g., file, syslog)
  • System Backend (mounted at /sys)
The image is a slide titled "Vault Paths," explaining that everything in Vault is path-based, with components like secret engines and auth methods mounted at specified paths. It also mentions that available paths depend on enabled features and that the system backend is mounted at the /sys endpoint.

​
Mounting Engines and Auth Methods

When enabling a component, you can specify a custom mount path with the -path flag. If you omit the flag, Vault uses the component’s name as the path: 
# Enable the database secrets engine at the default path "database/"
vault secrets enable database

# Enable the Azure auth method at a custom path "my-azure/"
vault auth enable -path=my-azure azure
The Vault UI provides a simple text field to specify custom mount paths, mirroring the CLI’s -path behavior.

​
System-Reserved Paths

Vault reserves certain paths that are integral to its operation. You cannot disable or remove these:
PathPurpose
auth/Configure and manage authentication methods
cubbyhole/Token-scoped private key/value storage
identity/Manage identity entities, groups, and aliases
secret/Default KV v2 secrets engine in development mode
sys/System backend for policies, audit devices, and mount points
The image is a slide titled "Vault Paths," explaining that Vault components can be enabled at any path with a default path option, and lists system reserved paths with descriptions.
In production, Vault does not enable the secret/ KV v2 engine by default. Always explicitly enable and configure the KV engine paths you need.

Watch Video