# Secrets engines

### What is a secrets engine? <a href="#what-is-a-secrets-engine" id="what-is-a-secrets-engine"></a>

Secrets engines are Vault components which store, generate or encrypt secrets. In Your First Secrets tutorial, you used key/value v2 secrets engine to store data. Some secrets engines like the key/value secrets engine simply store and read data. Other secrets engines connect to other services and generate dynamic credentials on demand. Other secrets engines provide encryption as a service.

There are a number of secrets engines available. You can think of them as a **plugin**. Enable the secrets engine that meets your security needs.

Secrets Management has a tutorial for different secrets engines. But first, complete this tutorial to learn the basic commands.

In the Your First Secrets tutorial, we used the `-mount=secret` flag with our `kv` commands. The key/value v2 secrets engine was enabled and ready to receive requests at `secret/` by default because we had started our Vault server in `-dev` mode.

The optional `-mount` flag syntax (e.g. `vault kv get -mount=secret foo`) from the previous tutorial is recommended when using the KV v2 secrets engine, but in this tutorial, we'll be using the KV v1 secrets engine and the path prefix syntax instead (e.g. `vault kv get secret/foo`) just to quickly demonstrate some concepts universal to all secrets engines.

Try the following command which will result an error:

```shell-session
$ vault kv put foo/bar a=b

Error making API request.

URL: GET http://localhost:8200/v1/sys/internal/ui/mounts/foo/bar
Code: 403. Errors:

* preflight capability check returned 403, ... grant access to path "foo/bar/"
```

The path prefix (or alternatively the `-mount` flag for `vault kv` commands) tells Vault which secrets engine to which it should route traffic. When a request comes to Vault, it matches the initial path part using a longest prefix match and then passes the request to the corresponding secrets engine enabled at that path. Vault presents these secrets engines similar to a filesystem.

There is no secrets engine mounted at `foo`, so the above command returned an error.

This tutorial discusses secrets engines and the operations they support. This information is important to both operators who will configure Vault and users who will interact with Vault.

### Enable a secrets engine <a href="#enable-a-secrets-engine" id="enable-a-secrets-engine"></a>

To get started, enable a new KV secrets engine at the path `kv`. Each path is completely isolated and cannot talk to other paths. For example, a KV secrets engine enabled at `foo` has no ability to communicate with a KV secrets engine enabled at `bar`.

```shell-session
$ vault secrets enable -path=kv kv

Success! Enabled the kv secrets engine at: kv/
```

The path where the secrets engine is enabled defaults to the name of the secrets engine. Thus, the following command is equivalent to executing the above command.

```shell-session
$ vault secrets enable kv
```

Executing this command will throw the `path is already in use at kv/` error.

To verify our success and get more information about the secrets engine, use the `vault secrets list` command:

```shell-session
$ vault secrets list

Path          Type         Accessor              Description
----          ----         --------              -----------
cubbyhole/    cubbyhole    cubbyhole_78189996    per-token private secret storage
identity/     identity     identity_ac07951e     identity store
kv/           kv           kv_15087625           n/a
secret/       kv           kv_4b990c45           key/value secret storage
sys/          system       system_adff0898       system endpoints used for control, policy and debugging
```

This shows there are 5 enabled secrets engines on this Vault server. You can see the type of the secrets engine, the corresponding path, and an optional description (or "n/a" if none was given). Running the above command with the `-detailed` flag can show you the version of the KV secrets engine and more.

The `sys/` path corresponds to the system backend. These paths interact with Vault's core system and are not required for beginners.

Take a few moments to read and write some data to the new `kv` secrets engine enabled at `kv/`. Here are a few ideas to get started.

To create secrets, use the `kv put` command.

```shell-session
$ vault kv put kv/hello target=world
Success! Data written to: kv/hello
```

To read the secrets stored in the `kv/hello` path, use the `kv get` command.

```shell-session
$ vault kv get kv/hello

===== Data =====
Key       Value
---       -----
target    world
```

Create secrets at the `kv/my-secret` path.

```shell-session
$ vault kv put kv/my-secret value="s3c(eT"
Success! Data written to: kv/my-secret
```

Read the secrets at `kv/my-secret`.

```shell-session
$ vault kv get kv/my-secret

==== Data ====
Key      Value
---      -----
value    s3c(eT
```

Delete the secrets at `kv/my-secret`.

```shell-session
$ vault kv delete kv/my-secret
Success! Data deleted (if it existed) at: kv/my-secret
```

List existing keys at the `kv` path.

```shell-session
$ vault kv list kv/

Keys
----
hello
```

### Disable a secrets engine <a href="#disable-a-secrets-engine" id="disable-a-secrets-engine"></a>

When a secrets engine is no longer needed, it can be disabled. When a secrets engine is disabled, all secrets are revoked and the corresponding Vault data and configuration is removed.

```shell-session
$ vault secrets disable kv/

Success! Disabled the secrets engine (if it existed) at: kv/
```

Note that this command takes a PATH to the secrets engine as an argument, not the TYPE of the secrets engine.

Any requests to route data to the original path would result in an error, but another secrets engine could now be enabled at that path.

### Next <a href="#next" id="next"></a>

Vault behaves similarly to a virtual filesystem. The read/write/delete/list operations are forwarded to the corresponding secrets engine, and the secrets engine decides how to react to those operations.

This abstraction is incredibly powerful. It enables Vault to interface directly with physical systems, databases, HSMs, etc. But in addition to these physical systems, Vault can interact with more unique environments like AWS IAM, dynamic SQL user creation, etc. all while using the same read/write interface.

You learned the basics of the `vault secrets` command. This is important knowledge to move forward and explore other secrets engines.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.enclaive.cloud/vault/tutorials/cli/secrets/secrets-engines.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.