Vault Glossary

Sakshi . -

Introduction

The world of data security and encryption can be intricate and daunting without a grasp of essential terms and principles.

Explore our comprehensive Vault Glossary where we elucidate the vital concepts related to secure data storage, access control, and cryptographic mechanisms. Elevate your comprehension of Vault and fortify your expertise in data security effortlessly.

Vault Terms

A

Audit Device: An audit device is responsible for overseeing and managing the audit logs. Every request sent to Vault and every response received from Vault is routed through the configured audit devices. This allows for a straightforward integration of Vault with various types of audit logging destinations.

Auth method: Auth methods are employed to authenticate users or applications attemptMng to connect to Vault. Upon successful authentication, the auth method provides a list of applicable policies that should be applied. Vault then utilizes the authenticated user and returns a client token that can be utilized for subsequent requests. For instance, the userpass auth method relies on a username and password for user authentication. Conversely, the github auth method enables users to authenticate using their GitHub credentials.

B

Barrier: Nearly all data written by Vault to storage undergoes encryption using the keyring, safeguarded by the seal, a practice known as 'the barrier'. However, there are some exceptions to this rule; for instance, the seal configuration is stored in an unencrypted file as it is essential for unsealing the barrier. Additionally, the keyring is encrypted with the root key, which in turn is encrypted using the seal.

C

Client token: A client token (also referred to as a “Vault Token”) is conceptually analogous to a session cookie on a website. After a user successfully authenticates, Vault provides them with a client token that can be utilized for subsequent requests. This token serves two key purposes: it allows Vault to verify the identity of the client, and it enables the enforcement of the applicable access control list (ACL) policies. The client token is passed along with requests via HTTP headers.

P

Plugin: Plugins are a feature of Vault that can be enabled, disabled, and customized to a certain extent. All of Vault's authentication methods and secrets engines are classified as plugins.

  • Built-in plugin: Included plugins are packaged with Vault, typically for widely used functionalities, and operate without the need for additional operator involvement. These included plugins function similarly to any other backend code integrated within Vault.
  • External plugin: External plugins are not included in the standard Vault distribution and necessitate operator intervention to operate. These external plugins in Vault are distinct, independent applications that Vault runs and interacts with via RPC. Whenever a Vault secret engine or authentication method is mounted, a new process is initiated.
  • External multiplexed plugin: External plugins have the capability to utilize plugin multiplexing. With multiplexing, a single plugin process can serve multiple mounts of the same type.

R

Request: When a request is sent to Vault, it includes all necessary parameters and context for Vault to respond appropriately. Vault internally interprets this request in a manner that comprehends:

  • Mount Point: Used to generate relative paths.
  • Mount Type: The type of mount the request is interacting with.
  • Namespace: The namespace the request is taking place within.
  • Operation: The request's operation can be one of the following: alias-lookahead, create, delete, header, help, list, patch, read, renew, resolve-role, revoke, rollbackupdate.
  • Path: The full path of the request.
💡
Request's Namespace: The namespace targeted by a request can be specified either within the path or through the Vault namespace header.

S

Secret: A secret in Vault refers to any data containing confidential or cryptographic material. Not all information returned by Vault qualifies as a secret; for instance, system configurations, status details, or policies are not classified as secrets. Dynamic secrets come with an associated lease, while static secrets do not. This implies that clients cannot assume perpetual use of dynamic secret contents. Vault automatically revokes dynamic secrets upon lease expiration, and operators have the ability to revoke dynamic secrets prematurely. This contractual agreement between Vault and its clients is crucial, enabling key and policy changes without manual intervention.

Secrets engine: A secrets engine is responsible for managing secrets. Basic secrets engines, like the 'kv' secrets engine, return the same secret when queried. Some secrets engines support the use of policies to dynamically generate a unique secret each time they are accessed. This allows for fine-grained revocation and policy updates by Vault. For instance, a MySQL secrets engine could be configured with a 'web' policy. When the 'web' secret is read, a new MySQL user/password pair with a limited set of privileges for the web server will be generated.

Server: Vault relies on a persistent server instance to function. This server instance hosts an API that clients use to interact with Vault, overseeing the coordination among secrets engines, ACL enforcement, and secret lease revocation. Adopting a server-based architecture separates clients from security keys and policies, facilitates centralized audit logging, and streamlines administration for operators.

Storage backend: A storage backend is responsible for the persistent storage of encrypted data. Vault does not trust the backends and expects them solely to provide durability. The storage backend is configured when initializing the Vault server.