open-vault/website/source/_ember_steps.html.erb

<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 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>- Mounting a backend</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 &lt;key 1&gt;</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 &lt;root token&gt;</code>
    </p>
</script>

<script type="text/x-handlebars" data-template-name="mounts">
    <p>
        Vault supports a number of secret backends. This behaves
        a lot like a virtual filesystem. The read/write/delete
        operations are forwarded to the backend, and the backend can
        choose to react to these operations however it wishes.
    </p>
    <p>
        Backends can be very powerful, dynamically interacting with
        services like AWS IAM, but for now we'll mount a simple
        generic backend that simply passes data through to
        the storage backend (after encrypting it).
    </p>
    <p>
        <code>vault mount generic</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 previously mounted generic 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 intrustion, 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.
    </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>