New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unattended startup mode #72

Closed
coderanger opened this Issue Apr 28, 2015 · 21 comments

Comments

Projects
None yet
7 participants
@coderanger

coderanger commented Apr 28, 2015

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

This comment has been minimized.

Member

mitchellh commented Apr 28, 2015

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 mitchellh closed this Apr 28, 2015

@mitchellh

This comment has been minimized.

Member

mitchellh commented Apr 28, 2015

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

This comment has been minimized.

coderanger commented Apr 28, 2015

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

This comment has been minimized.

Member

mitchellh commented Apr 28, 2015

@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

This comment has been minimized.

coderanger commented Apr 28, 2015

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

This comment has been minimized.

Member

mitchellh commented Apr 28, 2015

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

This comment has been minimized.

coderanger commented Apr 28, 2015

👍

@mitchellh

This comment has been minimized.

Member

mitchellh commented Apr 28, 2015

Reopening and editing your root comment

@mitchellh mitchellh reopened this Apr 28, 2015

@Parent5446

This comment has been minimized.

Parent5446 commented Jun 29, 2015

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

This comment has been minimized.

jeffbyrnes commented Aug 22, 2015

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

@jefferai

This comment has been minimized.

Member

jefferai commented Mar 14, 2016

Closing this as the initial ask has been addressed.

@jefferai jefferai closed this Mar 14, 2016

@jeffbyrnes

This comment has been minimized.

jeffbyrnes commented Mar 14, 2016

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

@jefferai

This comment has been minimized.

Member

jefferai commented Mar 14, 2016

@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

This comment has been minimized.

jeffbyrnes commented Mar 14, 2016

Thanks for clarifying @jefferai; makes sense.

@BryanDollery

This comment has been minimized.

BryanDollery commented Mar 31, 2016

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

This comment has been minimized.

Member

jefferai commented Mar 31, 2016

@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

This comment has been minimized.

sabat commented Aug 11, 2016

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

This comment has been minimized.

Member

jefferai commented Aug 12, 2016

@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

This comment has been minimized.

Parent5446 commented Aug 12, 2016

@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

This comment has been minimized.

coderanger commented Aug 12, 2016

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

@jefferai

This comment has been minimized.

Member

jefferai commented Aug 12, 2016

@coderanger Couldn't agree more.

@hashicorp hashicorp locked and limited conversation to collaborators Aug 12, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.