Using the dev server - Vault Tutorial

- Our first introductory steps will use the Vault Dev Server. A Vault server running in dev mode is useful for testing and experimentation. Dev mode servers differ from production servers. A dev server is meant for experimentation and testing only, never for production use. TLS is disabled, so secrets are not encrypted in transit. The dev server uses an in-mem, or in-memory storage back end. All data is stored in memory, not to a durable storage back end like a file system or KV store. A Vault dev server starts unsealed. And the command to start a dev server displays a single unsealed key rather than key shards. To start a Vault server, open the terminal window. Execute the command: vault server -dev. This will start a new Vault server in dev mode, display status information, and block. Let's take a look at the status information. You may need to scroll up to see it. I'll point out some of the important elements of the output. The API address is the URL where requests can be sent to the running Vault server. This is how the CLI and other applications can communicate with Vault. The cluster address is used when a Vault server is part of a high availability cluster. Mlock is a Linux feature that prevents memory from being swapped to disc. When enabled, this prevents unencrypted secrets in memory from being written to permanent storage. Storage is the back end used by Vault. The dev server uses an in-mem or in-memory storage back end. The faded text here reminds us that a dev server is not secure and should never be run in production. These lines list the information we need to interact with Vault, the unseal key and the root token. The unseal key of a dev server is the entire master key for this Vault server. The root token is a special token used for administration of the Vault server. In order to execute commands on this server, we'll need to open a second terminal window. Do that and then execute this command. Export VAULT_ADDR="http://127.0.0.1:8200". This command sets an environment variable used by the Vault CLI. The CLI checks this variable to get the address of the running Vault server. Vault servers listen on port 8200 by default. For convenience, you may want to set this environment variable permanently on your system. The methods for this very by OS and shell. Congratulations, you've just started your first Vault server. Now let's start using it, shall we? Next, we'll execute vault status. This command gets information about the current state of the vault server. This server is running and is technically using Shamir's Secret Sharing to protect the master key, even though the the key of a dev server is not split into shards. Our first demonstration of Vault will be to write a simple key value pair to the KV secrets engine. Key value pairs are like a two-column database table. The key must be unique. The value can be any text value. Execute this command: vault kv put secret/mySecret password=myPassword. The Vault KV command interacts with the KV secrets engine. Vault KV put adds a new secret at the path secret/mySecret. The secret is a key value pair. The key is password and the value is myPassword. The output returns metadata about the secret that we just created, including the creation time. Our secret is now stored in memory in the vault server and encrypted. Let's now read the secret back out of Vault. Execute this command: vault kv get secret/mySecret. The output of this command is the secret metadata and the secret itself. We can also return the data in JSON format. Vault kv get -format=json secret/mySecret. This is the format Vault would use to respond to an HTTP API request. You can parse the response using Linux utilities such as JQ.