Fun and Profit with Vault Part 2

Last time with Vault, I downloaded the binary, built a configuration file, initialized and unsealed the vault, and created a secret. That's all fun, but it's time to make the project a little more stable.

In defense of non-containerized install

In the first installment, I chose to just put the binary on the Mac directly instead of running it in a container. I know it's super sexy to run all the things in containers. But I don't already have containerized things running all the time on my laptop. Also, Vault will need to be easily accessible and writing to disk. Those things are easy to accomplish with containers, but for something so light weight, I felt like it wasn't necessary in this case. Also, I've never set up a daemon on a Mac, and haven't seen much about it specifically in regards to Vault either. So there it is. And I'm old and set in my ways.

Daemonizing Vault on OSX

Previously, I started Vault manually from the command line, and sent it into the background to do it's thing. Now I want it to start up when the laptop reboots. I could do that in my shell env, but that's not cool. I wondered how to create a daemon at startup. After some basic web searches and poking around on my laptop, I found /Library/LaunchDaemons/. It already had some stuff in it:

ls -l
total 32
-rw-r--r--  1 root  wheel  446 May 26  2017 com.apple.installer.cleanupinstaller.plist
-rw-r--r--  1 root  wheel  418 Feb  1  2017 com.citrix.ctxusbd.plist
-rw-r--r--  1 root  wheel  684 Nov 26 22:29 com.hashicorp.vault.plist
lrwxr-xr-x  1 root  wheel   76 May 27  2017 org.virtualbox.startup.plist -> ../Application Support/VirtualBox/LaunchDaemons/org.virtualbox.startup.plist

I created com.hashicorp.vault.plist by working from the others already present as examples. Mine looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>             <string>com.hashicorp.vault</string>
    <key>Disabled</key>          <false/>
    <key>RunAtLoad</key>         <true/>
    <key>KeepAlive</key>         <false/>
    <key>LaunchOnlyOnce</key>    <true/>
    <key>ProgramArguments</key>
        <array>
            <string>/usr/local/bin/vault</string>
            <string>server</string>
            <string>-config</string>
            <string>/Users/alan/vault-stuff/vault.hcl</string>
        </array>
</dict>
</plist>

Once I created /Library/LaunchDaemons/com.hashicorp.vault.plist with the above content, Vault started after my laptop reboot. As I understand the directives, this will start Vault at boot only once, and not try to keep it alive if the system detects it dies. Seems like a good start.

Setting up the shell environment

Not much needs to be done for setting up the shell really. Basically, since I haven't set up TLS at this point, it's just exporting the vault address for the CLI to use. I created a new file in my ~/vault-stuff/user-setup.sh. It only has one line for now, but it's there and logically placed if things get more complicated. Here are the contents:

export VAULT_ADDR=http://127.0.0.1:8200

Now that I have that file, I just source it from my ~/.bash_profile. Here is are the contents of that file:

# Setting PATH for Python 3.6
# The original version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.6/bin:/Users/alan/Library/Python/3.6/bin:/Users/alan/bin:${PATH}"
export PATH
. ~/vault-stuff/user-setup.sh

So now when I open my terminal session, I'm set for using vault. By default, Vault keeps the token you last used at ~/.vault-token, and so that is just there already.

Protecting the keys and tokens

While I'm not truly worried about my unseal keys and login tokens in this instance, it's still good practice to figure out how to make things more secure. To that end, I'm going to remove the file that has my Shamir keys shards and root token. But I have to keep it somewhere. There are a couple of reasons.

  • Even though the root token doesn't expire, I don't want it just living out there on the filesystem, and will eventually be creating my own tokens for logging in so it's not in .vault-token as it is now
  • Whenever the laptop reboots, Vault is restarted, or the vault seal command is used, the Shamir key shards will be required to unseal it again. Similar to the root token, I don't want these just laying around on the filesystem.

Even so, I only have so many options here. Securing something is always a chicken or egg argument. How can I completely secure a thing, but also still have the knowledge to get into it? This can drive you crazy if you just sit down and ponder it for a while. To that end, I'm just going to utilize my LastPass account to hold this stuff. This allows me to have these secret things hidden behind another password protected thing. An added benefit is that in a worst case scenario the details will be available from my phone without the interwebs. Typing in the keys would be super annoying, but I guess it's a thing to be said for this approach. of course, don't do it this way in a production environment!

LastPass-laptop-vault-note

Don't worry. I'll eventually revoke that root token, and rotate the keys for fun. Until then, don't steal my laptop and get my foo secret!

Next Up

Now that I've gotten the vault server part more or less configured to be running and accessible on my laptop, my next idea is to make an interface for doing some simple secret storage and updates. I know there are things already out there, but building the simple pieces can usually make my understanding better. I'm certainly not one for re-inventing the wheel, but it does help to know how and why a wheel does what it does.

Vault maintains a good list API libraries. Some are supported by Hashicorp, most are community supported. I'm tempted to use Go because I haven't before. However, I think I'll stick with ruby for the nonce to keep the task simple.

Till next time.