Vault Associate key terms

Vault starts in a sealed state where it cannot read its own storage. Unsealing supplies the key material, either Shamir key shares or a cloud KMS key, needed to reconstruct the master key and begin serving requests.

An algorithm that splits a secret into several shares so that any threshold number of them can rebuild the original value, while fewer than the threshold reveal nothing. Vault uses it to protect the master key.

A configuration in which Vault delegates unsealing to a trusted external service such as a cloud KMS or HSM, so operators never handle key shares and restarts recover without manual steps.

The cryptographic layer between Vault's core and its storage. Everything written to storage is encrypted with keys protected by the master key, so the raw storage contents are useless without unsealing.

The system Vault uses to persist data, such as integrated storage or Consul. It holds only ciphertext produced by the security barrier and performs no encryption of its own.

Vault's built-in Raft-based storage backend that keeps data on the Vault nodes themselves, removing the need for an external Consul cluster and supporting high availability and snapshots.

A highly available Vault cluster where one node is active and serves all requests while the others forward clients to it, ready to take over if the active node fails.

A plugin mounted at a path that verifies a caller's identity, for example a username and password or cloud credentials, and issues a Vault token when verification succeeds.

A machine-oriented auth method where a role_id and secret_id pair is exchanged for a token, well suited to CI pipelines and applications that cannot perform an interactive login.

An auth method that validates credentials against an LDAP or Active Directory server and can map directory group membership to Vault policies through external group configuration.

An auth method that lets pods or service accounts authenticate by presenting their Kubernetes service account token, which Vault verifies against the cluster's token review API.

An auth method that lets AWS workloads authenticate using IAM credentials, instance identity documents, or signed requests, with Vault validating them against AWS.

A document that grants or denies access to specific paths and operations. Every token carries one or more policies that determine which paths it may use and what it may do there.

Vault's human-readable policy format, in which path blocks list allowed capabilities such as read or create. JSON is also accepted for the same structure.

The pattern inside a policy that is matched against incoming request paths. It supports wildcards such as secret/* and templated segments to cover many secrets with one rule.

The permitted operations a policy grants on a path: create, read, update, patch, delete, list, sudo, and deny. Several can be combined in a single list.

When several policies attach to a token their grants are combined, but an explicit deny in any policy blocks access. Within a single policy, a more specific path rule overrides a broader wildcard.

The credential Vault issues after successful authentication. It carries policies, a time to live, and metadata, and every API request must present one.

The default token type. It has an accessor, can be renewed or have its time to live extended, can create child tokens, and is tracked in Vault's storage.

A lightweight token whose contents are encrypted into the token string itself rather than stored. It cannot be renewed or listed and is cheap to create but less flexible.

A token carrying the root policy, giving full privileges including the ability to manage every other token. Best practice is to create one only when needed and revoke it afterward.

A token created without a parent token, so revoking the parent does not revoke it. Useful for long-lived service credentials, though harder to clean up in bulk.

An identifier for a token that allows looking up its properties, renewing it, or revoking it without ever exposing the token value, which makes safe administration possible.

The lifetime of a token, set at creation from the auth method or role configuration. When it expires Vault revokes the token and its children unless it has been renewed.

A private key/value store scoped to a single token and destroyed with it, often used to pass data between steps or to hold a response-wrapping token securely.

Instead of returning a secret directly, Vault returns a single-use wrapping token that can be unwrapped later by its holder, allowing safe delivery through an untrusted channel.

A plugin mounted at a path that stores, generates, or encrypts data, such as the KV store, database credential generator, or certificate authority. Each mount is an isolated API namespace.

The key/value store for static secrets. Version 2 adds versioning, metadata, soft deletes, and undelete, and writes new data under the secret/data/ prefix of its mount.

Credentials Vault generates on demand with a limited lifetime, such as database users, so no long-lived password is stored and access expires automatically when the lease ends.

A secrets engine that creates short-lived database users from configured roles and removes them when their leases end, and that can also rotate the root connection credential.

A secrets engine that acts as a certificate authority, issuing and revoking X.509 certificates on demand with role-based constraints and configurable time to live.

The location where an engine is enabled, for example secret/ or database/. Policies, API calls, and CLI commands all reference this prefix when addressing the engine.

A record of how long Vault guarantees a secret or token stays valid. Dynamic secrets and tokens carry leases, and Vault revokes the underlying resource when a lease ends.

Extending a lease so that a token or dynamic credential remains valid longer, up to any maximum time to live set on the role. Renewal is requested through the leases or token API.

Ending a lease before it expires, which deletes the credential and its underlying resource immediately. Leases can be revoked one at a time, by path prefix, or all together.

The absolute ceiling on how long a token or lease may live, regardless of how often it is renewed. Once reached, Vault revokes it and refuses any further renewal.

A configured sink that records every request and response, hashing sensitive values. If an enabled device cannot be written to, Vault blocks requests rather than serve them unaudited.

A client-side daemon that handles authentication, token renewal, and secret caching for applications, and can render secrets into files from templates.

A single-node, in-memory configuration started with vault server -dev that is automatically initialized and unsealed with a root token. Convenient for testing, never appropriate for production.