Vault Enterprise Service Glossary
Published: 2020-09-24 02:28:38

---
title: Vault Enterprise Service Glossary
published: true
description: This is a glossary for technical terms related to the HashiCorp Vault Enterprise Service, and the important topics of Secrets Management in general, rather than concepts related to deploying the Vault Enterprise application to its host infrastructure.
tags: 
cover_image: https://res.cloudinary.com/practicaldev/image/fetch/s--qct7SMbA--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/p3kk0l2oxzvumayi6b1g.png
---

Post installation of Vault Enterprise servers, clusters, storage backends, supporting Cloud Resources, and Load Balancers, there's still much to be done in the Vault API! 

And much to be said. When documenting any of the many integrations of Vault with other services and systems, you could use the following glossary of terms: 

**Vault Enterprise Service** - The overall Secrets Management service offered to your developers and other users, as implemented by Vault Enterprise (Or the open source version too). Example: "The Rupture Vault Enterprise Service" offered at secrets.internal.ruptureranch.co, supported by the skilled Vault SREs of Rupture Ranch Inc.

**Vault Plugins** - These augment Vault's core functionality beyond what the Vault Enterprise Binary can do. Each Vault Plugin enables a new "Vault Secrets Engine" or a new "Vault Auth Method." You install a Vault Plugin by putting the plugin's binary into a folder in the same system that the Vault Binary runs in, and configuring Vault to look for plugins inside that folder. This functionality can be restricted, but by default is available to all Vault Namespaces once installed. Example: The [`vault-btc`](https://github.com/immutability-io/vault-btc) plugin uses Vault to implement a Bitcoin wallet, and can be installed by copying one of its release binaries to the `/etc/vault.d/plugins/` directory, and adding that `/etc/vault.d/plugins/` directory to your vault.hcl configuration file.

**Vault Namespace** - A "Vault within a Vault" that can be used for delegation of authority, separation of duties, reducing the blast radius of a change, confidentiality levels, GPDR compliance, or self service. Example: The `pci` Vault Namespace is separate from the `dbtest` Vault Namespace, within the Vault Enterprise Service.
 
**Vault Mount** - At the top level of Vault, or at the top level of a Vault Namespace within Vault, this is an endpoint like a Secrets Engine or another namespace that can be enabled by the user.

**Vault Secrets Engine** - A type of "mount" at the top level of a Vault Namespace, which stores Secrets or generates them on behalf of the API Consumers of the Vault Enterprise Service. These either store "Static Secrets" from static secret paths or generate "Dynamic Secrets" from Secret Engine Roles, to be described later.

**Vault API Consumers** - Clients that make HTTP requests to the Vault Enterprise API. Example: A Python script running in an AWS lambda sending an HTTP request to a Vault Enterprise Service to generate a Dynamic Secret.

**Vault Auth Method** - An authentication method for Vault, at the root of the Vault, or within a Vault Namespace, preceded by `/auth/`. Example: A TLS Auth Method was enabled within the `pci` namespace at `v1/pci/auth/cert`.

**Vault Auth Method Role** - A Role, within an Authentication Method for Vault, against which a given Vault API Consumer or consumers may authenticate. These grant Vault Tokens tied to a set of one or more Vault ACL Policies.

**Vault Secrets Engine Role** - These are created within Secrets Engines, and will generate Dynamic Secrets on demand. Example: The `vgdbx001` Vault Secrets Engine Role was created within the `postgres02` Vault Secrets Engine within the `pci` Vault Namespace at `v1/pci/postgres02/roles/vgdbx001`.

**Vault Tokens** - Vault API Tokens used to authenticate HTTP Requests to Vault.

**Vault ACL Policies** - Lists of API paths or, within a Vault Namespace, relative API paths, each with another list of the operations allowed against the API endpoints that correspond to those API paths or relative API paths.  Example: The `pci-namespace-admin` Vault ACL policy grants permission to do any operation against any of paths within the `pci` Vault Namespace.

**Vault API Request** - An HTTP request to the Vault Enterprise Service's ReST API. Typically includes the header `X-Vault-Token`, and the header `X-Vault-Namespace`.

## Advanced Vault Identity Terms

This section has some more details on concepts related to the Vault Identity store. More details are in the documentation at vaultproject.io: 

[vaultproject.io: Vault Identity Concepts](https://www.vaultproject.io/docs/secrets/identity#concepts)

**Vault Identity Store** - A system that keeps track of all of the Vault Clients.

**Vault Entity** - A *Vault Entity* is a given recognized client in Vault's client identity model, and may have multiple **Vault Aliases** associated with it.

**Vault Aliases** - Any of the various authentication leases from roles to which a given *Vault Entity* is associated.

**Vault Entity Group** - A *Group* of *Vault Entities*

## Examples of Using the Terms

Here are some more examples stringing these together: 

> I enabled & configured an **Auth Method**, but I didn't add any **Auth Method Roles** in it yet!

> In the `dbtest` **Namespace**, I made a **API Request** to make a new **Auth Method Role** in the `aws` **Auth Method**, and added the `pci-readonly` **ACL Policy** to that role.

> We may have had higher load on the Vault Servers because we got so many **Vault API Requests** against our new **Vault Secrets Engine Role** in the `PostGreSQL` **Vault Secrets Engine**.

> If you want to see all of the **Secrets Engines** in your `dbtest/` **Vault Namespace**, you should list all of the **Vault Mounts** in `dbtest/`.

When writing documentation that's focused on people who do not have deep experience with Vault Enterprise, it may be wise to put the word "Vault" in front of the specific term, in case it may be confused with another system. For instance, saying **Vault Namespace** rather than just **Namespace** may help avoid confusion with a Kubernetes Namespace.

For any questions, or to add a term, send me a message!

I also want comments on this page using the above terms in ways that make sense.