Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vault – A tool for managing secrets

hashicorp.com

Post reply on HN
Print view View original

101–110 of 112 posts

Re: Vault – A tool for managing secrets

#101

Post by [deleted] »

Freaky wrote: post #60
perlgeek wrote: post #33

It sounds very exciting. But, the first example made me flinch: $ vault write secret/foo value=bar Don't ever pass passwords on the command line. On linux, other users can see your command line (ps aux), and it usually ends up in a shell's history file.

> On linux, other users can see your command line (ps aux) On FreeBSD I like doing: /boot/loader.conf: mac_seeotheruids_load="YES" /etc/sysctl.conf: security.mac.seeotheruids.enabled="1" Which restricts users to seeing only their own processes. You can make exceptions for a specific group or users with the same primary group. I still don't put anything sensitive in a command line, of course.

[deleted]

Re: Vault – A tool for managing secrets

#102

Post by koffiezet »

IgorPartola wrote: post #43
outworlder wrote: post #29

> "Vault is the sixth such tool we've built. We've also built Vagrant, Packer, Serf, Consul, and Terraform. " Sigh. This is the first time that I actually feel overwhelmed. That nagging feeling that I'm doing something in some way solely because of habits. And that someone somewhere has created an awesome tool that would have allowed me to go home two hours earlier. The amount of new tools cropping in the last couple…

Obligatory quote from that XKCD about automating things. Remember, most of these tools simply automate what you already do. If you don't spend much time performing certain things, you don't need the tool. The cargo cult of "I should use Packer to create my Vagrant boxes, so I can have dev/prod parity" only works to a point. Instead, look at where you spend lots of time, and then look for tools that automate that task…

The main reason for automation is not saving time. It is about being able to reproduce and test the thing you're trying to automate. It's also about tracking changes, accountability on a larger scale.

I manage quite a few servers, all running different in-house developed services. Almost all configurations are completely different, with a few exceptions, but I am still automating them. Just leaving it like it is, all manually managed would probably save me a lot of time, so why do I do it? So it can first be deployed on some test VM's, and when someone changes a configuration, I can track it in git/svn/.. and see who committed what change. It would only save me time if I had to deploy service X more than 3 or 4 times (dev/test/qa/prod), but as it stands, nop. Timesink it is.

Re: Vault – A tool for managing secrets

#105

Post by notum »

saintfiends wrote: post #103

Slightly OT, but is there such a tool (to store secrets securely and accessibly) for personal use that runs well with Linux and can be easily moved around (portable).

https://www.keepassx.org/ but I'm unsure if it has any sort of a CLI. It was mentioned in the EFF's updated SSL article.

Re: Vault – A tool for managing secrets

#106

Post by nunull »

kylequest wrote: post #76
mitchellh wrote: post #36

Earlier quoted context omitted.

Absolutely true! We support values coming from the command-line, stdin, and files: https://vaultproject.io/docs/commands/read-write.html So you should use what you feel is most secure given the data you're entering.

Why not use interactive CLI instead of command line CLI (like routers have) to avoid leaks through the shell command history and other related channels?

I think what you mean by "interactive CLI" is reading from stdin, which seams to be supported.

Re: Vault – A tool for managing secrets

#107

Post by IgorPartola »

koffiezet wrote: post #102
IgorPartola wrote: post #43

Earlier quoted context omitted.

Obligatory quote from that XKCD about automating things. Remember, most of these tools simply automate what you already do. If you don't spend much time performing certain things, you don't need the tool. The cargo cult of "I should use Packer to create my Vagrant boxes, so I can have dev/prod parity" only works to a point. Instead, look at where you spend lots of time, and then look for tools that automate that task…

The main reason for automation is not saving time. It is about being able to reproduce and test the thing you're trying to automate. It's also about tracking changes, accountability on a larger scale. I manage quite a few servers, all running different in-house developed services. Almost all configurations are completely different, with a few exceptions, but I am still automating them. Just leaving it like it is, all…

I would say that if you are not automating something like what you describe, you would have to spend time manually verifying that it is working correctly, so it is about time after all.

Re: Vault – A tool for managing secrets

#108

Post by mpdehaan2 »

mitchellh wrote: post #36
perlgeek wrote: post #33

It sounds very exciting. But, the first example made me flinch: $ vault write secret/foo value=bar Don't ever pass passwords on the command line. On linux, other users can see your command line (ps aux), and it usually ends up in a shell's history file.

Absolutely true! We support values coming from the command-line, stdin, and files: https://vaultproject.io/docs/commands/read-write.html So you should use what you feel is most secure given the data you're entering.

This is why ansible-vault (which is not trying to do the same thing) spawned a temporary editor, and immediately upon save encrypted the file - it doesn't exist in history, nor is there a chance of leaving it behind on disk.

There's probably a way to do what you have launching an editor with stdin, but I'd probably suggest documenting an example, to avoid the risk of leaving the secret around.

Also +1 to removing the insecure history option. Documenting the stdin to use 'cat' or something that's not in the history would probably take care of that one.

Re: Vault – A tool for managing secrets

#109

Post by metavida »

dorfsmay wrote: post #40

Got to mention blackbox, it's based on gpg, and meant for teams interacting within version control systems: https://github.com/StackExchange/blackbox

I'm not terribly familiar with blackbox, but based on the blackbox Readme it seems that this critique from Vault's website [1] addresses why HashiCorp thinks Vault is a better solution.

> Chef, Puppet, etc. all solve this in a similar way: single-key encrypted storage. Chef has encrypted data bags, Puppet has encrypted Hiera, an so on. The encrypted data is always one secret (a password, a key, etc.) away from being decrypted, and this secret is generally not well protected since in an elastic environment, every server needs to somehow get this secret to decrypt the data. Additionally, access to the encrypted data isn't always logged, so if there is an intrusion, it isn't clear what data has been accessed and by who.

[1]: https://vaultproject.io/intro/vs/chef-puppet-etc.html

Re: Vault – A tool for managing secrets

#110

Post by mentat »

ukd1 wrote: post #95
mentat wrote: post #10

Any reason why AWS dynamic credentials use IAM users instead of STS and role assumption? That seems to be a somewhat more widely accepted way to do dynamic credentials / role proxying.

came here to see how it was done; was hoping for STS :(

https://github.com/dump247/docker-ec2-metadata and https://github.com/AdRoll/hologram exist as examples of this, just FYI.
Post reply on HN