Unattended startup mode

[coderanger]

Edit by @mitchellh: Read comments below on why. Let's add the @filename syntax to read keys for unseal.

Creating this for tracking, would be a feature for a future version.

While the n-of-m unsealing is the best default, some cases will require a less manual process for starting/restarting the Vault server. The best way to handle this is probably to allow putting the whole master key in a file that Vault can read. This comes with no shortage of security implications and the docs will need to reflect that, but would be good to have an option for situations where the operator is willing to take on key management for that master key and knows the risks.

[mitchellh]

The unsealing process is a big part of our security model. If you want to automate the unsealing and throw away all the security that comes with it, you can just use curl and the set of unseal keys along with the HTTPS API to do it via a script.

See #64 for my little speech on trading UX and core architectural security. This is one of those places I think that the tradeoff doesn't make sense. There is a workaround possible via the API. This would make it sufficiently automatable.

I'm also curious for what reasoning you need a less manual process? During the beta process we worked with companies ranging from startups to global 2000 and also highly elastic cloud infras to very old school physical infras, and all of them were able to get the unseal process to work. Even for highly elastic infrastructures the process was generally to spin up and manually unseal n servers in high-availability mode. This way if any go offline, you can still serve traffic. The security folks always wanted to unseal them anyways.

I believe this is all fair, welcome any discussion.

[mitchellh]

Actually, I want to add that you can probably do this even with pure CLI and not the HTTP API directly. There is an undocumented feature where the vault unseal command can take the unseal key as an argument. You can easily read each line and xargs it in, most likely.

[coderanger]

Hmm, maybe extend that feature to allow reading the key(s) in via the @filename syntax? Would require a complex init script but sounds doable overall. The reason for this is stuff like ephemeral staging environments where I would want to CM-ify the full process of launching an env. Even in production, storing the master key in a local HSM (with its own unlocking process) or something like managing the master key via EC2 IAM roles or KMS would be an option.

[mitchellh]

@coderanger Got it, I think the easiest for those environments then would be to init with a single key (-key-shraes=1 -key-threshold=1) and then use vault unseal with a single arg! :)

[coderanger]

Yeah, just wouldn't want to put that in the command line itself if possible, vault unseal @/etc/tableflip.key would give a modicum more safety at least.

[mitchellh]

Haha, I think all safety is mostly thrown out the door, but I can see your "modicum". Fair enough, we'll add the @ syntax for 0.1.1. Note that it won't be documented for the same reason the arg isn't documented. At least for now.

[coderanger]

:+1:

[mitchellh]

Reopening and editing your root comment

[Parent5446]

Just want to +1 the idea of KMS. Would be useful if I could assign an IAM role to the machines running Vault, and then allow it to retrieve the unsealing keys from KMS (and then maybe support auto-rotation of the vault encryption keys).

[jeffbyrnes]

Adding a mechanism to push/pull the unsealing keys to/from KMS sounds very nifty to me.

[jefferai]

Closing this as the initial ask has been addressed.

[jeffbyrnes]

@jefferai I must have missed something; where was this addressed?

[jefferai]

@jeffbyrnes It was made clear that automatic unsealing is not the operating mode of Vault and that a simple script or API calls can unseal Vault automatically if someone wants to trade off security for UX.

[jeffbyrnes]

Thanks for clarifying @jefferai; makes sense.

[BryanDollery]

Even though this issue is closed, with a good-enough answer, I think it's worth expanding slightly on why anyone would want to do away with the 3-key unsealing process...

In my case, I have a startup with only one employee -- me -- but I'm quite experienced and want to do things right, hence I'm planning on using vault. The 3 key thing is a hinderance for me because I don't have anyone else to give the keys to.

Another potential problem is in local development environments -- I want to develop against vault, but I want to do it on my local machine by bringing up an instance of vault in docker, but yet again the 3 key thing is a hinderance. I imagine this is a much more common scenario than the first one -- you have to look after developers otherwise the tool won't get used at all.

Anyway, that was just for clarification. I'd already implemented this with three curl's in a script, as per the canonical answer and was only looking around for 'better' solutions, but this one is fine really. I agree with the approach -- if you watered it down then large companies would end up using the less secure approach because they'd think it was easier and cheaper.

[jefferai]

@BryanDollery You can also just set your secret shares to 1 and your threshold to 1 and then you have one key, not three.

[sabat]

The unsealing process is a big part of our security model. If you want to automate the unsealing and throw away all the security that comes with it

I cannot tell you how much I disagree with this philosophy. Human intervention is not the solution to security problems; humans are the security problem. Tightly controlled automation is a much better solution than actually expecting people to remember to intervene. Automation is faster, cheaper, more easily controlled, and enables reproducible environments. Human intervention requirements assist none of these things.

[jefferai]

@sabat You are more than welcome to set up automation on your own. It's a bash script away, assuming you can properly protect your unseal keys. Vault does not, and will not, support, a built-in automatic unsealing mode, outside of its HSM capability.

[Parent5446]

@sabat My recommendation is to evaluate similar products like Confidant, Keywhiz, or Sneaker. I have not personally looked at them, but in general it's better to find a product who's developers are more security-minded than to try and hack a solution together.

[coderanger]

@jefferai Can you lock this ticket? I don't think it's productive at this point :)

[jefferai]

@coderanger Couldn't agree more.