scottk/vault
1
0
Fork 0
mirror of https://github.com/optim-enterprises-bv/vault.git synced 2025-11-02 03:27:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

Vault Documentation: Added Glossary (#12324)

Browse Source 
* added glossary

* Update website/content/docs/glossary.mdx

Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>

* Update website/content/docs/glossary.mdx

Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>

* modified secrets and barrier content based on feedback

Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
This commit is contained in:
Loann Le
2021-08-16 13:08:44 -07:00
committed by GitHub
parent 33de5e2663
commit 9ba8b90dc4
3 changed files with 97 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files

61
website/content/docs/internals/architecture.mdx
View File

@@ -17,67 +17,6 @@ spelunking through the source code. However, if you're an operator of Vault, we
recommend learning about the architecture due to the importance of Vault in an
environment.
# Glossary
Before describing the architecture, we provide a glossary of terms to help
clarify what is being discussed:
- **Storage Backend** - A storage backend is responsible for durable storage of
_encrypted_ data. Backends are not trusted by Vault and are only expected to
provide durability. The storage backend is configured when starting the Vault
server.
- **Barrier** - The barrier is cryptographic steel and concrete around the
Vault. All data that flows between Vault and the storage backend passes
through the barrier. The barrier ensures that only encrypted data is written
out, and that data is verified and decrypted on the way in. Much like a bank
vault, the barrier must be "unsealed" before anything inside can be accessed.
- **Secrets Engine** - A secrets engine is responsible for managing secrets.
Simple secrets engines like the "kv" secrets engine simply return the same
secret when queried. Some secrets engines support using policies to
dynamically generate a secret each time they are queried. This allows for
unique secrets to be used which allows Vault to do fine-grained revocation and
policy updates. As an example, a MySQL secrets engine could be configured with
a "web" policy. When the "web" secret is read, a new MySQL user/password pair
will be generated with a limited set of privileges for the web server.
- **Audit Device** - An audit device is responsible for managing audit logs.
Every request to Vault and response from Vault goes through the configured
audit devices. This provides a simple way to integrate Vault with multiple
audit logging destinations of different types.
- **Auth Method** - An auth method is used to authenticate users or applications
which are connecting to Vault. Once authenticated, the auth method returns the
list of applicable policies which should be applied. Vault takes an
authenticated user and returns a client token that can be used for future
requests. As an example, the `userpass` auth method uses a username and
password to authenticate the user. Alternatively, the `github` auth method
allows users to authenticate via GitHub.
- **Client Token** - A client token (aka "Vault Token") is conceptually
similar to a session cookie on a web site. Once a user authenticates, Vault
returns a client token which is used for future requests. The token is used by
Vault to verify the identity of the client and to enforce the applicable ACL
policies. This token is passed via HTTP headers.
- **Secret** - A secret is the term for anything returned by Vault which
contains confidential or cryptographic material. Not everything returned by
Vault is a secret, for example system configuration, status information, or
policies are not considered secrets. Secrets always have an associated lease.
This means clients cannot assume that the secret contents can be used
indefinitely. Vault will revoke a secret at the end of the lease, and an
operator may intervene to revoke the secret before the lease is over. This
contract between Vault and its clients is critical, as it allows for changes
in keys and policies without manual intervention.
- **Server** - Vault depends on a long-running instance which operates as a
server. The Vault server provides an API which clients interact with and
manages the interaction between all the secrets engines, ACL enforcement, and
secret lease revocation. Having a server based architecture decouples clients
from the security keys and policies, enables centralized audit logging and
simplifies administration for operators.
# High-Level Overview
A very high level overview of Vault looks like this: