2015-04-22 22:09:12 +00:00
|
|
|
|
<script type="text/x-handlebars" data-template-name="welcome">
|
|
|
|
|
<p>
|
2015-04-23 03:50:05 +00:00
|
|
|
|
This tutorial is great for getting familiar with the command line
|
|
|
|
|
interface to Vault. As soon as you opened this terminal, you connected to a real in-memory Vault server.
|
|
|
|
|
Any commands you enter will work as they would with Vault normally, but leaving this page
|
2015-04-23 03:21:15 +00:00
|
|
|
|
will end the session.
|
2015-04-22 22:09:12 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2015-04-23 03:21:15 +00:00
|
|
|
|
Please note that this is running in a shared environment, so avoid setting any real secrets.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2015-04-23 03:50:05 +00:00
|
|
|
|
<strong>Use the command "next" to move forward</strong>.
|
2015-04-23 03:21:15 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>This will work throughout
|
|
|
|
|
the tutorial, along with "previous" to go back a step.
|
|
|
|
|
</p>
|
|
|
|
|
</script>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<script type="text/x-handlebars" data-template-name="steps">
|
|
|
|
|
<p>
|
|
|
|
|
This tutorial will cover the following steps:
|
2015-04-22 22:09:12 +00:00
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
2015-04-23 03:21:15 +00:00
|
|
|
|
<li>- Initializing and unsealing your Vault</li>
|
2015-04-23 01:48:24 +00:00
|
|
|
|
<li>- Authorizing your requests to Vault</li>
|
2015-04-23 16:58:15 +00:00
|
|
|
|
<li>- Reading and writing secrets</li>
|
2015-04-23 01:48:24 +00:00
|
|
|
|
<li>- Sealing your Vault</li>
|
2015-04-22 22:09:12 +00:00
|
|
|
|
</ul>
|
|
|
|
|
<p>
|
2015-04-23 03:50:05 +00:00
|
|
|
|
<strong>Again, use "next" to move to the first step – initializing your Vault</strong>.
|
2015-04-22 22:09:12 +00:00
|
|
|
|
</p>
|
2015-04-23 01:48:24 +00:00
|
|
|
|
</script>
|
|
|
|
|
|
|
|
|
|
<script type="text/x-handlebars" data-template-name="init">
|
2015-04-22 22:09:12 +00:00
|
|
|
|
<p>
|
2015-04-23 03:21:15 +00:00
|
|
|
|
To get started, we need to initialize an instance of Vault for you
|
|
|
|
|
to work with.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
While initializing, you can configure the seal behavior
|
|
|
|
|
of Vault.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2015-04-23 16:44:33 +00:00
|
|
|
|
Initialize Vault now, with 1 unseal key for simplicity, using the command:
|
2015-04-22 22:09:12 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2015-04-23 03:21:15 +00:00
|
|
|
|
<code>vault init -key-shares=1 -key-threshold=1</code>
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
You'll notice Vault prints out several keys here. Don't clear your terminal,
|
|
|
|
|
as these are needed in the next few steps.
|
2015-04-22 22:09:12 +00:00
|
|
|
|
</p>
|
|
|
|
|
</script>
|
2015-04-22 22:15:45 +00:00
|
|
|
|
|
2015-04-23 03:21:15 +00:00
|
|
|
|
<script type="text/x-handlebars" data-template-name="unseal">
|
|
|
|
|
<p>
|
|
|
|
|
When a Vault server is started, it starts in a sealed state.
|
|
|
|
|
In this state, Vault is configured to know where and how to access the
|
|
|
|
|
physical storage, but doesn't know how to decrypt any of it.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Vault encrypts data with an encryption key. This key is encrypted with the "master key", which
|
|
|
|
|
isn't stored. Decrypting the master key requires a threshold of shards. In this example,
|
2015-04-23 16:44:33 +00:00
|
|
|
|
we use one shard to decrypt this master key.
|
2015-04-23 03:21:15 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Unseal the Vault:
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
<code>vault unseal <key 1></code>
|
|
|
|
|
</p>
|
|
|
|
|
</script>
|
2015-04-23 01:48:24 +00:00
|
|
|
|
|
2015-04-23 03:21:15 +00:00
|
|
|
|
<script type="text/x-handlebars" data-template-name="auth">
|
|
|
|
|
<p>
|
|
|
|
|
Before performing any operation with Vault, the
|
|
|
|
|
connecting client must be authenticated. Authentication is
|
|
|
|
|
the process of verifying a person or machine is who they say
|
|
|
|
|
they are and assigning an identity to them. This identity is then
|
|
|
|
|
used when making requests with Vault.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
For simplicity, we'll use the root token we generated on init in Step 2. This
|
|
|
|
|
output should be available in the scrollback.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Authorize with a client token:
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
<code>vault auth <root token></code>
|
|
|
|
|
</p>
|
|
|
|
|
</script>
|
2015-04-23 01:48:24 +00:00
|
|
|
|
|
2015-04-23 03:21:15 +00:00
|
|
|
|
<script type="text/x-handlebars" data-template-name="secrets">
|
|
|
|
|
<p>
|
2015-04-23 16:44:33 +00:00
|
|
|
|
Now that Vault has been set-up, we can start reading and writing secrets
|
2015-04-23 19:16:17 +00:00
|
|
|
|
with the default mounted secret backend. Secrets written to Vault
|
2015-04-23 16:44:33 +00:00
|
|
|
|
are encrypted and then written to the backend storage.
|
|
|
|
|
The backend storage mechanism never sees the unencrypted
|
|
|
|
|
value and doesn't have the means necessary to decrypt
|
|
|
|
|
it without Vault.
|
2015-04-23 03:21:15 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2015-04-23 16:44:33 +00:00
|
|
|
|
<code>vault write secret/hello value=world</code>
|
2015-04-23 03:21:15 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2015-04-23 16:44:33 +00:00
|
|
|
|
Of course, you can then read this data too:
|
2015-04-23 03:21:15 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2015-04-23 16:44:33 +00:00
|
|
|
|
<code>vault read secret/hello</code>
|
2015-04-23 03:21:15 +00:00
|
|
|
|
</p>
|
|
|
|
|
</script>
|
|
|
|
|
|
|
|
|
|
<script type="text/x-handlebars" data-template-name="seal">
|
|
|
|
|
<p>
|
2015-04-23 16:44:33 +00:00
|
|
|
|
There is also an API to seal the Vault. This will throw
|
|
|
|
|
away the encryption key and require another unseal process
|
|
|
|
|
to restore it. Sealing only requires a single operator
|
|
|
|
|
with root privileges. This is typically part of a rare "break glass
|
|
|
|
|
procedure".
|
2015-04-23 01:48:24 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2015-04-28 18:30:17 +00:00
|
|
|
|
This way, if there is a detected intrusion, the Vault data can be locked
|
2015-04-23 16:44:33 +00:00
|
|
|
|
quickly to try to minimize damages. It can't be accessed again
|
|
|
|
|
without access to the master key shards.
|
2015-04-22 22:15:45 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2015-04-23 16:44:33 +00:00
|
|
|
|
<code>vault seal</code>
|
2015-04-22 22:15:45 +00:00
|
|
|
|
</p>
|
2015-04-23 16:44:33 +00:00
|
|
|
|
</script>
|
|
|
|
|
|
|
|
|
|
<script type="text/x-handlebars" data-template-name="finish">
|
2015-04-22 22:15:45 +00:00
|
|
|
|
<p>
|
2015-04-23 19:26:00 +00:00
|
|
|
|
Thanks for trying out the Vault CLI. If you want to keep playing with
|
|
|
|
|
commands, use "fu" to go fullscreen.
|
2015-04-23 16:44:33 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Note that the Vault CLI uses the HTTP API, which gives you full access to Vault. Every aspect
|
|
|
|
|
of Vault can be controlled via this API.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
We recommend reading through the <a href="/intro/index.html">intro guide</a> next, which will
|
|
|
|
|
provide more background information, use cases and examples.
|
2015-04-22 22:15:45 +00:00
|
|
|
|
</p>
|
|
|
|
|
</script>
|