55c26a909e
backend example.
147 lines
4.9 KiB
Plaintext
147 lines
4.9 KiB
Plaintext
<script type="text/x-handlebars" data-template-name="welcome">
|
||
<p>
|
||
This tutorial is great for getting familiar with the command line
|
||
interface to Vault. As soon as you opened this terminal, you are connected to a real in-memory Vault server.
|
||
Any commands you enter will work as they would with Vault normally, but leaving this page
|
||
will end the session.
|
||
</p>
|
||
<p>
|
||
Please note that this is running in a shared environment, so avoid setting any real secrets.
|
||
</p>
|
||
<p>
|
||
<strong>Use the command "next" to move forward</strong>.
|
||
</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:
|
||
</p>
|
||
<ul>
|
||
<li>- Initializing and unsealing your Vault</li>
|
||
<li>- Authorizing your requests to Vault</li>
|
||
<li>- Reading and writing secrets</li>
|
||
<li>- Sealing your Vault</li>
|
||
</ul>
|
||
<p>
|
||
<strong>Again, use "next" to move to the first step – initializing your Vault</strong>.
|
||
</p>
|
||
</script>
|
||
|
||
<script type="text/x-handlebars" data-template-name="init">
|
||
<p>
|
||
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>
|
||
Initialize Vault now, with 1 unseal key for simplicity, using the command:
|
||
</p>
|
||
<p>
|
||
<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.
|
||
</p>
|
||
</script>
|
||
|
||
<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,
|
||
we use one shard to decrypt this master key.
|
||
</p>
|
||
<p>
|
||
Unseal the Vault:
|
||
</p>
|
||
<p>
|
||
<code>vault unseal <key 1></code>
|
||
</p>
|
||
</script>
|
||
|
||
<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>
|
||
|
||
<script type="text/x-handlebars" data-template-name="secrets">
|
||
<p>
|
||
Now that Vault has been set-up, we can start reading and writing secrets
|
||
with the default mounted secret backend. Secrets written to Vault
|
||
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.
|
||
</p>
|
||
<p>
|
||
<code>vault write secret/hello value=world</code>
|
||
</p>
|
||
<p>
|
||
Of course, you can then read this data too:
|
||
</p>
|
||
<p>
|
||
<code>vault read secret/hello</code>
|
||
</p>
|
||
</script>
|
||
|
||
<script type="text/x-handlebars" data-template-name="seal">
|
||
<p>
|
||
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".
|
||
</p>
|
||
<p>
|
||
This way, if there is a detected intrusion, the Vault data can be locked
|
||
quickly to try to minimize damages. It can't be accessed again
|
||
without access to the master key shards.
|
||
</p>
|
||
<p>
|
||
<code>vault seal</code>
|
||
</p>
|
||
</script>
|
||
|
||
<script type="text/x-handlebars" data-template-name="finish">
|
||
<p>
|
||
Thanks for trying out the Vault CLI. If you want to keep playing with
|
||
commands, use "fu" to go fullscreen.
|
||
</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.
|
||
</p>
|
||
</script>
|