a3dfde5cec
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
75 lines
3.3 KiB
Markdown
75 lines
3.3 KiB
Markdown
---
|
|
layout: "docs"
|
|
page_title: "Secrets Engines"
|
|
sidebar_title: "Secrets Engines"
|
|
sidebar_current: "docs-secrets"
|
|
description: |-
|
|
Secrets engines are mountable engines that store or generate secrets in Vault.
|
|
---
|
|
|
|
# Secrets Engines
|
|
|
|
Secrets engines are components which store, generate, or encrypt data. Secrets
|
|
engines are incredibly flexible, so it is easiest to think about them in terms
|
|
of their function. Secrets engines are provided some set of data, they take some
|
|
action on that data, and they return a result.
|
|
|
|
Some secrets engines simply store and read data - like encrypted
|
|
Redis/Memcached. Other secrets engines connect to other services and generate
|
|
dynamic credentials on demand. Other secrets engines provide encryption as a
|
|
service, totp generation, certificates, and much more.
|
|
|
|
Secrets engines are enabled at a "path" in Vault. When a request comes to Vault,
|
|
the router automatically routes anything with the route prefix to the secrets
|
|
engine. In this way, each secrets engine defines its own paths and properties.
|
|
To the user, secrets engines behave similar to a virtual filesystem, supporting
|
|
operations like read, write, and delete.
|
|
|
|
## Secrets Engines Lifecycle
|
|
|
|
Most secrets engines can be enabled, disabled, tuned, and moved via the CLI or
|
|
API. Previous versions of Vault called these "mounts", but that term was
|
|
overloaded.
|
|
|
|
- **Enable** - This enables a secrets engine at a given path. With few
|
|
exceptions, secrets engines can be enabled at multiple paths. Each secrets
|
|
engine is isolated to its path. By default, they are enabled at their "type"
|
|
(e.g. "aws" enables at "aws/").
|
|
|
|
- **Disable** - This disables an existing secrets engine. When a secrets engine
|
|
is disabled, all of its secrets are revoked (if they support it), and all of
|
|
the data stored for that engine in the physical storage layer is deleted.
|
|
|
|
- **Move** - This moves the path for an existing secrets engine. This process
|
|
revokes all secrets, since secret leases are tied to the path they were
|
|
created at. The configuration data stored for the engine persists through the
|
|
move.
|
|
|
|
- **Tune** - This tunes global configuration for the secrets engine such as the
|
|
TTLs.
|
|
|
|
Once a secrets engine is enabled, you can interact with it directly at its path
|
|
according to its own API. Use `vault path-help` to determine the paths it
|
|
responds to.
|
|
|
|
Note that mount points cannot conflict with each other in Vault. There are
|
|
two broad implications of this fact. The first is that you cannot have
|
|
a mount which is prefixed with an existing mount. The second is that you
|
|
cannot create a mount point that is named as a prefix of an existing mount.
|
|
As an example, the mounts `foo/bar` and `foo/baz` can peacefully coexist
|
|
with each other whereas `foo` and `foo/baz` cannot
|
|
|
|
## Barrier View
|
|
|
|
Secrets engines receive a _barrier view_ to the configured Vault physical
|
|
storage. This is a lot like a [chroot](https://en.wikipedia.org/wiki/Chroot).
|
|
|
|
When a secrets engine is enabled, a random UUID is generated. This becomes the
|
|
data root for that engine. Whenever that engine writes to the physical storage
|
|
layer, it is prefixed with that UUID folder. Since the Vault storage layer
|
|
doesn't support relative access (such as `../`), this makes it impossible for a
|
|
enabled secrets engine to access other data.
|
|
|
|
This is an important security feature in Vault - even a malicious engine
|
|
cannot access the data from any other engine.
|