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

41–50 of 112 posts

Re: Vault – A tool for managing secrets

#41

Post by IgorPartola »

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.

This is true on shared systems. But for example as I am setting up a brand new server, I might do this from there since I know I'm the only user. The second half of your complaint is solved (at least in bash) by adding a space character before the beginning of the command.

Edit: am I wrong? If so, please explain, I really am curious.

Re: Vault – A tool for managing secrets

#43

Post by IgorPartola »

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.

Personally, I try to be pretty conservative with tools that I start relying on. I know by painful experience that some tools get abandoned, some change drastically, making it impossible to upgrade, and some just turn out to be very buggy and horrible once you start putting them through their paces. In lots of cases, it's better to be critical than permissive when it comes to your infrastructure (and that's what these tools are aimed at). In almost all cases, your edge is in knowing the tools you use, and knowing about other tools. It's not in knowing all and using everything under the sun.

Re: Vault – A tool for managing secrets

#44

Post by mikewhy »

mikewhy wrote: post #42

this may be an obvious question, but how do things like Vault/Keywhiz differ from Consul/Etcd? Is it simply that the former is more encrypted than the latter?

ah, as per http://vaultproject.io/intro/vs/consul.html

> While Consul can be used to store secret information and gate access using ACLs, it is not designed for that purpose. As such, data is not encrypted in transit nor at rest, it does not have pluggable authentication mechanisms, and there is no per-request auditing mechanism.

I guess my question now is why not add E2E encryption on top of Consul/Etcd instead of a whole new system?

Re: Vault – A tool for managing secrets

#45

Post by IgorPartola »

jvehent wrote: post #18

There are many solutions out there that attempt to solve the secrets distribution problem. Vault is the newest one. None of them solve the fundamental problem of the secret zero: provisioning the first secret on an untrusted system the automated way is hard, and without that secret zero, there is no way to authenticate the new system. With Vault, you still need to figure out how to push secret zero (here a client aut…

Why not do it at the network level? In some infrastructures this is really easy. For example in AWS you can set up all your servers in a VPC. Then put Vault on a machine on a specific subnetwork, and firewall it off such that only the machines from your VPC may access it. You have now created a walled garden where anything inside your VPC has access to the secrets without holding an authentication token, while anything outside does not.

Personally, I think this is your only line of defense anyways. Someone with access to your private network will likely be able to do some harm, and if they get even a non-root user on your server, it's game over, since you are just one local exploit away from them gaining root. Remember, once they gain root on one box, it's just a matter of time before they replace /usr/bin/sudo and /usr/bin/login with a script that emails them your password and/or steals your ssh-agent socket.

Re: Vault – A tool for managing secrets

#46

Post by lenish »

odiroot wrote: post #35
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.

Put a space before the command and it's gone from the history, AFAIR.

This is only true in bash if HISTCONTROL contains ignorespace or ignoreboth (ignoreboth implies ignorespace and ignoredups), so you should check that before relying on this functionality.

Re: Vault – A tool for managing secrets

#47

Post by acveilleux »

mikewhy wrote: post #44
mikewhy wrote: post #42

this may be an obvious question, but how do things like Vault/Keywhiz differ from Consul/Etcd? Is it simply that the former is more encrypted than the latter?

ah, as per http://vaultproject.io/intro/vs/consul.html > While Consul can be used to store secret information and gate access using ACLs, it is not designed for that purpose. As such, data is not encrypted in transit nor at rest, it does not have pluggable authentication mechanisms, and there is no per-request auditing mechanism. I guess my question now is why not add E2E encryption on top of Consul/Etcd instead of a…

It's desirable to keep secret managements simple and as self-contained and self-sufficient as possible. That way, it's much easier to drastically lock it down without impacting normal users too much. Your organization might have, say, 30 people who routinely need access to the orchestration / deployment infrastructure but maybe 3 who need access to cryptovariables.

Re: Vault – A tool for managing secrets

#48

Post by metric10 »

ams6110 wrote: post #38
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.

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.

Re: Vault – A tool for managing secrets

#49

Post by jgrowl »

steveb wrote: post #8

I'm pretty excited about this release. We just added deploying Vault on top of consul in the microservice/realtime data platform we're building: https://github.com/CiscoCloud/microservices-infrastructure We were already using consul as our service discovery engine and as a data store for dynamic configurations via consul template. We feel Vault will help us manage secrets on our infrastructure and inside containers.

Neat! I'll have to see how you ended up using Vault since your project uses a lot of the same tech my personal webrtc server project uses. I'm also using ansible, docker, consul, registrator.

Excuse the mess, I'm still working on it: https://github.com/jgrowl/livehq

Re: Vault – A tool for managing secrets

#50

Post by otterley »

zhoutong wrote: post #20
jvehent wrote: post #18

There are many solutions out there that attempt to solve the secrets distribution problem. Vault is the newest one. None of them solve the fundamental problem of the secret zero: provisioning the first secret on an untrusted system the automated way is hard, and without that secret zero, there is no way to authenticate the new system. With Vault, you still need to figure out how to push secret zero (here a client aut…

We've had the same issues at CoinJar, and we used SSH agent forwarding to solve it. This is how it can work: Every new instance of application server is provisioned automatically by a trusted server (which holds the key to a credentials server). During orchestration/deployment, the application server has a temporary permission to fetch the secrets it needed, through SSH agent forwarding. Once the deployment is done,…

How does SSH agent forwarding work if there's no interactive user driving the process? Otherwise the concurrency is going to be limited to however many ssh sessions the client can spawn; and the orchestration/deployment cannot be a handsfree process.
Post reply on HN