1--- 2layout: "docs" 3page_title: "Secrets Engines" 4sidebar_title: "Secrets Engines" 5sidebar_current: "docs-secrets" 6description: |- 7 Secrets engines are mountable engines that store or generate secrets in Vault. 8--- 9 10# Secrets Engines 11 12Secrets engines are components which store, generate, or encrypt data. Secrets 13engines are incredibly flexible, so it is easiest to think about them in terms 14of their function. Secrets engines are provided some set of data, they take some 15action on that data, and they return a result. 16 17Some secrets engines simply store and read data - like encrypted 18Redis/Memcached. Other secrets engines connect to other services and generate 19dynamic credentials on demand. Other secrets engines provide encryption as a 20service, totp generation, certificates, and much more. 21 22Secrets engines are enabled at a "path" in Vault. When a request comes to Vault, 23the router automatically routes anything with the route prefix to the secrets 24engine. In this way, each secrets engine defines its own paths and properties. 25To the user, secrets engines behave similar to a virtual filesystem, supporting 26operations like read, write, and delete. 27 28## Secrets Engines Lifecycle 29 30Most secrets engines can be enabled, disabled, tuned, and moved via the CLI or 31API. Previous versions of Vault called these "mounts", but that term was 32overloaded. 33 34- **Enable** - This enables a secrets engine at a given path. With few 35 exceptions, secrets engines can be enabled at multiple paths. Each secrets 36 engine is isolated to its path. By default, they are enabled at their "type" 37 (e.g. "aws" enables at "aws/"). 38 39- **Disable** - This disables an existing secrets engine. When a secrets engine 40 is disabled, all of its secrets are revoked (if they support it), and all of 41 the data stored for that engine in the physical storage layer is deleted. 42 43- **Move** - This moves the path for an existing secrets engine. This process 44 revokes all secrets, since secret leases are tied to the path they were 45 created at. The configuration data stored for the engine persists through the 46 move. 47 48- **Tune** - This tunes global configuration for the secrets engine such as the 49 TTLs. 50 51Once a secrets engine is enabled, you can interact with it directly at its path 52according to its own API. Use `vault path-help` to determine the paths it 53responds to. 54 55Note that mount points cannot conflict with each other in Vault. There are 56two broad implications of this fact. The first is that you cannot have 57a mount which is prefixed with an existing mount. The second is that you 58cannot create a mount point that is named as a prefix of an existing mount. 59As an example, the mounts `foo/bar` and `foo/baz` can peacefully coexist 60with each other whereas `foo` and `foo/baz` cannot 61 62## Barrier View 63 64Secrets engines receive a _barrier view_ to the configured Vault physical 65storage. This is a lot like a [chroot](https://en.wikipedia.org/wiki/Chroot). 66 67When a secrets engine is enabled, a random UUID is generated. This becomes the 68data root for that engine. Whenever that engine writes to the physical storage 69layer, it is prefixed with that UUID folder. Since the Vault storage layer 70doesn't support relative access (such as `../`), this makes it impossible for a 71enabled secrets engine to access other data. 72 73This is an important security feature in Vault - even a malicious engine 74cannot access the data from any other engine. 75