Vault – A tool for managing secrets

The security page seems to be a generic one about reporting vulnerabilities: http://vaultproject.io/security.html

Edit: Found it under the threat model section here: https://vaultproject.io/docs/internals/security.html

re: naming (and disclaimer): I wrote Ansible and designed Ansible's vault (and no longer work on Ansible), but to be clear, Ansible's vault is a nicer CLI (IMHO) around an idea that Chef users were already used to: encrypted data bags. It was nothing new. It took about two weeks to implement, but we had a few security things to shake out after that made it take a bit longer before it got right. (Some people also got picky about whole-data-document encryption vs leaf-node-in-datastructure encryption, and I see points for doing it both ways, but went with the way that revealed the least amount of data)

I think calling it vault is perfectly fair, as it's a very generic word, and words are in short supply. This is also doing a LOT more.

I like what Mitchell and crew have done around revocation here, though I do somewhat wonder about the mode in the docs that sets secrets and allows them to show in bash history, which is why ansible vault spawned an editor. I'm sure it's got editor options too though. I'd probably also change the phrasing "HTTP API" to "HTTPS API" :)

The dynamic secret stuff also looks pretty interesting.

One of the interesting ideas might be to whether it allows sharing of secret values to some applications without letting someone read it (asking if a user can use X without letting the user READ x), which is something we did in tower - though it seems the ACL system might allow something like that. An example of that was the system could memorize an SSH key and let a team use it, but never give it to anyone, to avoid rotation scenarios.

Anyway, all the lease ideas are very cool and it seems natural to want this decoupled. For a time I considered decoupling what what in Ansible vault from Ansible, though really it already operates on generic files so that's easy enough if someone wanted to take a stab at it.

I suspect it wouldn't be impossible to make Ansible Vault have a hashicorp-vault-mode where it encrypts a file "into" the vault, and the contents that remain in your "ansible vault" file are nothing more than a pointer to a secret in Hashicorp Vault. In this way, it would just be another cipher type. Maybe that's crazy though - but I think I like that better than storing secrets in version control, where they exist forever unless you prune history. (And I never thought storing vault files in public source was a good idea). However, avoiding a server or database was always one of Ansible's design goals - for better or worse, that limited some of the things the core app could do, in ways that were both good and also occasionally limiting.

Anyway, keep up the forward progress with the new things! I really envy the time to architect/design something so detailed here.

It allows you to have a non-sensitive single factor within things like configuration management, and have the second factor come from a machine-local location (instance ID, MAC address, TSM module, etc.). The idea is that another team out of band sets the 2nd factor that developers and config management never get to see. The result is you have full automation without secret zero issues.

As an additional security parameter, you can bind the two factors together to a single CIDR block, so you can have an additional factor restricting access from that machine's IP.

The URL itself above goes into a lot more detail, but our beta users are successfully automated in an elastic environment this way.