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

71–80 of 112 posts

Re: Vault – A tool for managing secrets

#71

Post by dmgbrn »

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.

Unless you're on your personal laptop.

It's a tricky question, one that we've spent a lot of time thinking about at my company (Conjur -- shameless plug, one of our use cases is secrets management). Obviously doing this on a server that others can access/pwn is a bad idea, but that's a very rare use case. Most secrets are being added via the command line from an admin's single user laptop.

In the end, we've settled on what seems to be the same solution as Vault: support other sources (stdin, files, etc.), but allow the command line.

That said, I think you're right that we should look into adding a warning for the CLI tools and placing more emphasis on this fact in our documentation.

Re: Vault – A tool for managing secrets

#72

Post by dserodio »

I haven't finished reading the docs yet, but this part[1] caught my attention:

> When a backend is unmounted, all of its secrets are revoked and its data is deleted.

If a backend is similar to a filesystem as mentioned in the docs, that's quite a surprise. If a backend is like a filesystem, the secrets (files) should become unavailable when unmounted, but should become available again after remounting the backend (filesystem).

Are the secrets actually _deleted_ (ie, can't be recovered again), or am I misunderstanding?

[1] http://vaultproject.io/intro/getting-started/secret-backends...

Re: Vault – A tool for managing secrets

#73

Post by dustinrcollins »

The policies look like they'd be a bear to manage since they are path- and not role-based. In order to implement least privilege with multiple actors you'd have to be really careful with your paths.

Example: 2 apps. App 1 needs secrets A B and D. App 2 need secrets A B and C.

So we need to set up our paths in a way that App 1 can get A and B and C, but not D. App 2 needs C but not D. Now when you want to modify secret access from your apps you have to rethink how your paths are set up.

When you're instead assigning permissions to roles this is a lot easier. An example: http://blog.conjur.net/what-is-a-devops-secrets-server

Re: Vault – A tool for managing secrets

#74

Post by wslh »

dmgbrn wrote: post #71
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.

Unless you're on your personal laptop. It's a tricky question, one that we've spent a lot of time thinking about at my company (Conjur -- shameless plug, one of our use cases is secrets management). Obviously doing this on a server that others can access/pwn is a bad idea, but that's a very rare use case. Most secrets are being added via the command line from an admin's single user laptop. In the end, we've settled o…

> Unless you're on your personal laptop.

It persists in your shell history... your notebook is stolen, then...

You can encrypt the filesystem but it is better to not have your secret information disseminated in your filesystem and computer memory.

Re: Vault – A tool for managing secrets

#75

Post by skywhopper »

metric10 wrote: post #48
ams6110 wrote: post #38

Earlier quoted context omitted.

How many people these days share their linux machine with anyone else? If you're the only user, first point doesn't matter. History file is a concern, but can be mitigated e.g. setting HISTIGNORE

Depends on the situation. A Linux machine running as a server can still be accessed by multiple people. Also, a "user" could be a compromised process that can execute commands. Using stdin or a properly created file means one less possible attack vector.

Doesn't storing the secret in a file first violate half the point of this service? Once it's written to disk in plaintext it's just as recoverable as your shell history.

Re: Vault – A tool for managing secrets

#76

Post by kylequest »

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.

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?

Re: Vault – A tool for managing secrets

#77

Post by skywhopper »

ceejayoz wrote: post #51
ams6110 wrote: post #38

Earlier quoted context omitted.

How many people these days share their linux machine with anyone else? If you're the only user, first point doesn't matter. History file is a concern, but can be mitigated e.g. setting HISTIGNORE

All it takes is a WordPress vulnerability that lets someone run `exec` on your server.

if you the sort to worry about vault's command line being a security risk, you shouldn't be managing your secrets from your wordpress host in the first place.

Re: Vault – A tool for managing secrets

#78

Post by MCRed »

Can someone explain hashicorps business model to me?

Love all the projects. Are they contracting out features to companies? Selling support contracts?

Very curious-- I think if people, especially individuals, can make a living from open source projects, that's great for everybody.

But do you have to be "famous" to do it?

Re: Vault – A tool for managing secrets

#79

Post by druiid »

MCRed wrote: post #78

Can someone explain hashicorps business model to me? Love all the projects. Are they contracting out features to companies? Selling support contracts? Very curious-- I think if people, especially individuals, can make a living from open source projects, that's great for everybody. But do you have to be "famous" to do it?

To the best of my knowledge it comes from contracting/support and mostly their Vagrant Cloud (now Atlas) features that are business/enterprise only, which they charge money for. For example private hosting of Vagrant box images is a paid feature. The costs for that are per-user/per-month.

Re: Vault – A tool for managing secrets

#80

Post by ams6110 »

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…

So what I really need to do is automate reading HN. I'll get half my day back!
Post reply on HN