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

51–60 of 112 posts

Re: Vault – A tool for managing secrets

#51

Post by ceejayoz »

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

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

Re: Vault – A tool for managing secrets

#52

Post by acveilleux »

mitchellh wrote: post #19
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 worked with a handful of companies to help us design the "App ID" authentication backend that does exactly that: https://vaultproject.io/docs/auth/app-id.html 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 2n…

So if I read that correctly, the UserID (I find that naming confusing since users here aren't necessarily humans) creation has a human in the loop to add the UserID to Vault and therefore make the authorization decision?

Re: Vault – A tool for managing secrets

#53

Post by malandrew »

What's coming next from hashicorp? The one infrastructure piece for which good open-source solutions still lack is ACL with solid auditing and variety of permissions approval models.

There are a bunch of good ideas in this RFC, https://tools.ietf.org/html/rfc2904

Something like a host-your-own Amazon IAM would be pretty dope. Add support for 2fa and especially u2f and you've got yourself a winner.

Re: Vault – A tool for managing secrets

#54

Post by acveilleux »

IgorPartola wrote: post #45
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 anythi…

Because you want authorization and authentication by application. So a web server / proxy needs the public TLS cert but maybe an application server doesn't. Meanwhile the app server needs DB credentials but the web server doesn't.

In your scenario, if something happens to a front facing web server, nothing prevents the attacker to just enumerate all secrets and retrieve them, whether the server should have had access or not.

Defense in depth is a thing.

Re: Vault – A tool for managing secrets

#55

Post by IgorPartola »

acveilleux wrote: post #54
IgorPartola wrote: post #45

Earlier quoted context omitted.

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 anythi…

Because you want authorization and authentication by application. So a web server / proxy needs the public TLS cert but maybe an application server doesn't. Meanwhile the app server needs DB credentials but the web server doesn't. In your scenario, if something happens to a front facing web server, nothing prevents the attacker to just enumerate all secrets and retrieve them, whether the server should have had access…

I believe what you are describing can be built using the primitives I described. Vault, or another secrets manager, would only release secrets to severs on specific subnets. The front-end would be on your front-end subnet, the application server would be on the backend subnet, and the application server would not be authorized to access the private TLS key because it's on the wrong subnet for that particular secret.

Re: Vault – A tool for managing secrets

#56

Post by flowerpot »

Neat! I've been working on something similar for about the past six months, although my approach is a little more minimalistic, but also based on shamir's secret sharing. I was planning to release a preview the next couple of days. If any one is interested https://github.com/duse-io/api#how-it-works

//edit My solution focuses more on the sharing aspect between people, but can just as well be used like Vault

Re: Vault – A tool for managing secrets

#58

Post by sliverstorm »

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.

I think the argument is something like, why support a method that is insecure nearly all the time and leads less-experienced users to make the wrong choices.

Good security software gently herds the non-expert to make good choices. Too many options, especially specialty risky options, don't help that goal.

Re: Vault – A tool for managing secrets

#59

Post by hexedpackets »

This is really awesome! I've been passively looking for something like Vault for a while, can't wait to start integrating.

I just finished tossing together a Chef cookbook to get Vault installed/configured up to the init/unseal step. Here's the link in case its useful to anyone: https://github.com/hexedpackets/chef-vault

Re: Vault – A tool for managing secrets

#60

Post by Freaky »

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.

Post reply on HN