Deploy Vault
Up to this point, you interacted with the "dev" server, which automatically unseals Vault, sets up in-memory storage, and uses a root token value that you set. Now that you know some Vault basics, you are prepared to learn how to deploy Vault into a real environment.
Launch Terminal
This tutorial includes a free interactive command-line lab that lets you follow along on actual cloud infrastructure.
In this tutorial, you will learn how to configure, start, initialize, and unseal Vault.
Warning
Press Ctrl+C to stop any dev server that is already running at
http://127.0.0.1:8200
before starting.
Unset the VAULT_TOKEN
environment variable to prevent any value used earlier from use this time.
$ unset VAULT_TOKEN
Configure Vault
You can configure Vault with with HashiCorp Configuration Langauge (HCL) files.
Create the Vault configuration in the file config.hcl
.
config.hcl
storage "raft" { path = "./vault/data" node_id = "node1"} listener "tcp" { address = "127.0.0.1:8200" tls_disable = "true"} api_addr = "http://127.0.0.1:8200"cluster_addr = "https://127.0.0.1:8201"ui = true
Vault Enterprise
As of version 1.12.0, Vault Enterprise will no longer
start up if configured to use a storage backend other than Integrated
Storage (raft
) or
Consul (consul
). See the Release
Notes.
Within the configuration file, there are some configuration stanzas:
storage
- This is the physical backend that Vault uses for storage. Up to this point the dev server has used "inmem" (in memory), but the example above uses Integrated Storage (raft
), a much more production-ready backend.listener
- One or more listeners determine how Vault listens for API requests. The example above listens on localhost port 8200 without TLS. In your environment setVAULT_ADDR=http://127.0.0.1:8200
so the Vault client will connect without TLS.Insecure operation
The listener stanza disables TLS (
tls_disable = "true"
). In production, Vault should always use TLS to provide secure communication between clients and the Vault server. It requires a certificate file and key file on each Vault host.api_addr
- Specifies the address to advertise to route client requests.cluster_addr
- Indicates the address and port to be used for communication between the Vault nodes in a cluster.
Start the server
The ./vault/data
directory that raft
storage backend uses must exist, so you must create it.
$ mkdir -p ./vault/data
Start the server, and use the -config
flag to point to the proper path where you saved the configuration file.
$ vault server -config=config.hcl ==> Vault server configuration: Api Address: http://127.0.0.1:8200 Cgo: disabled Cluster Address: https://127.0.0.1:8201 Go Version: go1.16.2 Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled") Log Level: info Mlock: supported: true, enabled: true Recovery Mode: false Storage: raft (HA available) Version: Vault v1.7.0 Version Sha: 4e222b85c40a810b74400ee3c54449479e32bb9f ==> Vault server started! Log data will stream in below:
Note
If you get a warning message about mlock not being supported, that is okay. However, for maximum security you should run Vault on a system that supports mlock.
Vault outputs details about its configuration, and then blocks. This process should be run using a resource manager such as systemd or upstart.
On Linux, Vault may fail to start with the following error:
Error initializing core: Failed to lock memory: cannot allocate memoryThis usually means that the mlock syscall is not available.Vault uses mlock to prevent memory from being swapped todisk. This requires root privileges as well as a machinethat supports mlock. Please enable mlock on your system ordisable Vault from using it. To disable Vault from using it,set the `disable_mlock` configuration option in your configurationfile.
For guidance on dealing with this issue, see the discussion of disable_mlock
in Server Configuration.
config.hcl
storage "raft" { path = "./vault/data" node_id = "node1"} listener "tcp" { address = "127.0.0.1:8200" tls_disable = "true"} disable_mlock = true api_addr = "http://127.0.0.1:8200"cluster_addr = "https://127.0.0.1:8201"ui = true
Initialize Vault
Initialization is the process of configuring Vault. You do this once when starting the server with a new storage backend. This command cannot be run against already-initialized Vault cluster. When running in HA mode, this happens once per cluster, not per server. Vault also generates the encryption key, unseal keys (or recovery keys for auto seal), and initial root token value during initialization.
Launch a new terminal session, and export the VAULT_ADDR
environment variable to address the dev server.
$ export VAULT_ADDR='http://127.0.0.1:8200'
Use the vault operator init
command to initialize Vault.
$ vault operator init
Example output:
Unseal Key 1: 4jYbl2CBIv6SpkKj6Hos9iD32k5RfGkLzlosrrq/JgOmUnseal Key 2: B05G1DRtfYckFV5BbdBvXq0wkK5HFqB9g2jcDmNfTQiSUnseal Key 3: Arig0N9rN9ezkTRo7qTB7gsIZDaonOcc53EHo83F5chAUnseal Key 4: 0cZE0C/gEk3YHaKjIWxhyyfs8REhqkRW/CSXTnmTilv+Unseal Key 5: fYhZOseRgzxmJCmIqUdxEm9C3jB5Q27AowER9w4FC2CkInitial Root Token: s.KkNJYWF5g0pomcCLEmDdOVCWVault initialized with 5 key shares and a key threshold of 3. Please securelydistribute the key shares printed above. When the Vault is re-sealed,restarted, or stopped, you must supply at least 3 of these keys to unseal itbefore it can start servicing requests.Vault does not store the generated root key (previously known as master key).Without at least 3 key to reconstruct the root key, Vault will remainpermanently sealed!It is possible to generate new unseal keys, provided you have a quorum ofexisting unseal keys shares. See "vault operator rekey" for more information.
Initialization outputs two critical pieces of information: the unseal keys and the initial root token. This is the only time ever that all of this data is known by Vault, and also the only time that the unseal keys should ever be so close together.
For the purpose of this getting started tutorial, save all of these keys somewhere, and continue. In a real deployment scenario, you would never save these keys together. Instead, you would likely use Vault's PGP and Keybase.io support to encrypt each of these keys with the users' PGP keys. This prevents one single person from having all the unseal keys. Please see the documentation on using PGP, GPG, and Keybase for more information.
Seal/Unseal
Every initialized Vault server starts in the sealed state. From the configuration, Vault can access the physical storage, but it can't read any of it because it doesn't know how to decrypt it. The process of teaching Vault how to decrypt the data is known as unsealing the Vault.
Unsealing has to happen every time Vault starts. It can be done via the API and via the command line. To unseal the Vault, you must have the threshold number of unseal keys. In the output above, notice that the "key threshold" is 3. This means that to unseal the Vault, you need 3 of the 5 keys that were generated.
Note
Vault does not store any of the unseal key shards. Vault uses an algorithm known as Shamir's Secret Sharing to split the root key into shards. Only with the threshold number of keys can it be reconstructed and your data finally accessed.
Begin unsealing the Vault:
$ vault operator unseal Unseal Key (will be hidden):Key Value--- -----Seal Type shamirInitialized trueSealed trueTotal Shares 5Threshold 3Unseal Progress 1/3Unseal Nonce d3d06528-aafd-c63d-a93c-e63ddb34b2a9Version 1.7.0Storage Type raftHA Enabled true
After pasting in a valid key and confirming, you see that Vault is still sealed, but progress is made. Vault knows it has 1 key out of 3. Due to the nature of the algorithm, Vault doesn't know if it has the correct key until the threshold is reached.
Also notice that the unseal process is stateful. You can go to another computer,
use vault operator unseal
, and as long as it's pointing to the same server,
that other computer can continue the unseal process. This is incredibly
important to the design of the unseal process: multiple people with multiple
keys are required to unseal the Vault. The Vault can be unsealed from multiple
computers and the keys should never be together. A single malicious operator
does not have enough keys to be malicious.
Continue with vault operator unseal
to complete unsealing the Vault. To unseal
the vault you must use three different unseal keys, the same key repeated will
not work.
$ vault operator unseal Unseal Key (will be hidden):# ...
As you use keys, as long as they are correct, you should soon see output like this:
Key Value--- -----Seal Type shamirInitialized trueSealed falseTotal Shares 5Threshold 3Version 1.7.0Storage Type raftCluster Name vault-cluster-0ba62caeCluster ID 7d49e5fd-a1a4-c1d1-55e2-7962e43006a1HA Enabled trueHA Cluster n/aHA Mode standbyActive Node Address <none>Raft Committed Index 24Raft Applied Index 24
When the value for Sealed
changes to false
, the Vault is unsealed.
Feel free to play around with entering invalid keys, keys in different orders, etc. in order to understand the unseal process.
Finally, authenticate as the initial root token (it was included in the output with the unseal keys).
$ vault loginToken (will be hidden):
Enter the token value when prompted.
Example output:
Success! You are now authenticated. The token information displayed belowis already stored in the token helper. You do NOT need to run "vault login"again. Future Vault requests will automatically use this token.Key Value--- -----token s.spAZOi7SlpdFTNed50sYYCIUtoken_accessor OevFmMXjbmOCQ8rSubY84vVptoken_duration ∞token_renewable falsetoken_policies ["root"]identity_policies []policies ["root"]
As a root user, you can reseal the Vault with vault operator seal
. A single
operator is allowed to do this. This lets a single operator lock down the
Vault in an emergency without consulting other operators.
When the Vault is sealed again, it clears all of its state (including the encryption key) from memory. The Vault is secure and locked down from access.
Clean up
Before continuing on to the Using the HTTP APIs with Authentication tutorial, press Ctrl+C to stop the server.
Or, kill the Vault process from a command.
$ pgrep -f vault | xargs kill
Delete the /vault/data
directory which stores the encrypted Vault data.
$ rm -r ./vault/data
Next
You now know how to configure, initialize, and unseal/seal Vault. This is the basic knowledge necessary to deploy Vault into a real environment. Once the Vault is unsealed, you access it as you have throughout this getting started tutorial (which worked with an unsealed Vault).