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

91–100 of 112 posts

Re: Vault – A tool for managing secrets

#91

Post by FireBeyond »

IgorPartola wrote: post #82
acveilleux wrote: post #68

Earlier quoted context omitted.

To some extent, that's true. The granularity is a bit lacking however. A bigger worry would be that the ability to spin up an host in a specific subnet is the effective authentication. It's not something I'd be comfortable with myself but I guess some people would be.

If I get on your subnet with a host on which I have root, I can do a few things. First, I can now see any unencrypted traffic. Use MySQL? I can read that or even MIIT it. Use unencrypted LDAP? I can do the same. Basically you either assume your VPC is secure or it's not. This goes doubly so for servers on your network. Either, you assume that only authorized users have access to it or you don't. You have to draw the…

Hmm, how many networks these days are unswitched? How are you going to see traffic that the switch doesn't send to you?

Re: Vault – A tool for managing secrets

#92

Post by mitchellh »

SEJeff wrote: post #90
mitchellh wrote: post #6

Earlier quoted context omitted.

It does. The solution to this problem is to run Vault in high availability mode[1]. This will have a set of stand-bys that can take over if the leader goes down. The idea is to unseal all the stand bys, and if the leader goes down, the standbys take over, and the sealed one can be unsealed at some other future point. Security-sensitive things have been an interesting UX challenge for us, but this compromise comes at…

Can you call mlock in go to prevent any secrets from being paged to disk?

We already do this. And yes, you can (using the "syscall" package).

Re: Vault – A tool for managing secrets

#93

Post by ntucker »

otterley wrote: post #50
zhoutong wrote: post #20

Earlier quoted context omitted.

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.

I'm not the person you're asking, but in our system, our secret access is tied to an SSH identity, not an SSH agent. This means that you have flexibility to require a personal user's ssh agent to be present for access to some things, or an identity file (optionally encrypted) stored on the server for less-sensitive things. In the case of things that need to happen unattended, we use an in-the-clear identity file, which might seem a little counterintuitive since security-wise, it's basically equivalent to just having the secret sitting there, but the indirection adds ease of rotating secrets along with revocability if we were to suspect we lost control of such a machine. But for most of our secrets, we tie them to individual user's identities which must be forwarded via an agent. We consider this an acceptable constraint because deployment and app restarts are always driven by a human in our operations.

It's not a perfect system or a panacea, but it's far better than having a bunch of passwords directly stored in config files, in my opinion. We also have a wrapper tool that uses your SSH agent access to fetch secrets for the mysql suite of tools as needed, so nobody is ever tempted to create a personal .my.cnf on prod servers. Anybody who actually has access to a given mysql password is still on the honor system not to fetch it and write it down somewhere, but removing the need to ever even see them eliminates the temptation to put it in a .my.cnf or in your clipboard, which eliminates a whole class of mistakes you can make in handling them.

Re: Vault – A tool for managing secrets

#96

Post by daurnimator »

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.

on linux you can mount procfs with the option 'hidepid' to similar effect.

Re: Vault – A tool for managing secrets

#97

Post by detaro »

FireBeyond wrote: post #91
IgorPartola wrote: post #82

Earlier quoted context omitted.

If I get on your subnet with a host on which I have root, I can do a few things. First, I can now see any unencrypted traffic. Use MySQL? I can read that or even MIIT it. Use unencrypted LDAP? I can do the same. Basically you either assume your VPC is secure or it's not. This goes doubly so for servers on your network. Either, you assume that only authorized users have access to it or you don't. You have to draw the…

Hmm, how many networks these days are unswitched? How are you going to see traffic that the switch doesn't send to you?

Active attacks, like ARP spoofing? Sure, there are environments where that won't work or will quickly be detected, but in many it will.

Re: Vault – A tool for managing secrets

#99

Post by eb0la »

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.

Good point!

When I want to run something on a server and I don't want it to end in the .history file, I always run vi and execute the commands inside it ( :!command ).

It always shows in the process list; but for short-lived commands the opportunity window is small for an attacker.

Re: Vault – A tool for managing secrets

#100

Post by gknoy »

msutherl wrote: post #66
ams6110 wrote: post #39

Earlier quoted context omitted.

Yes but very easy to forget to do. BTDT.

Could you alias "vault" to " vault"?

I doubt it. My history file shows all the git-related aliases I use (st, gd, gd-) rather than the expansions (git status, git diff, git diff --cached).
Post reply on HN