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

81–90 of 112 posts

Re: Vault – A tool for managing secrets

#81

Post by ntucker »

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

This is similar to what we do at my company. I wrote about it a bit here: https://news.ycombinator.com/item?id=8826300

Would be interesting to hear more details of yours for comparison.

Re: Vault – A tool for managing secrets

#82

Post by IgorPartola »

acveilleux wrote: post #68
IgorPartola wrote: post #55

Earlier quoted context omitted.

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.

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 line in the sand somewhere and say "past this point it's secure".

Now, I am not opposed to layers of security, but there are multiple options for how to define those, and assuming your network is secure isn't a far stretch on some platforms.

Re: Vault – A tool for managing secrets

#83

Post by istvan__ »

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.

Yes FreeBSD got this one right.

Re: Vault – A tool for managing secrets

#84

Post by mitchellh »

dserodio wrote: post #72

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 (fi…

I'm responding a little late here, but hopefully you'll still see this.

Yes, when you unmount a backend, all the data is deleted. Vault mostly behaves like a filesystem, but not in this scenario. The raw data is not preserved. If you want to preserve the raw data, you can remount (move the mount point).

We didn't finish it for 0.1, but we already built in secret enumeration into the core. We plan to expose this at some point. If you want to unmount and preserve your secrets, you can always enumerate them and back them up elsewhere (unencrypted). This isn't yet available.

Re: Vault – A tool for managing secrets

#85

Post by kgilpin »

It's pretty amazing to see how many new secrets tools for DevOps and cloud have suddenly materialized in the last few weeks. At Conjur, we have been in production in this space for almost two years. If you're wondering how to stack up these different tools against each other, here are a few facts about our solution:

* At Conjur, we care deeply about three things : (1) the overall user experience for developers, operations, and security personnel (2) the security of our code (3) high availability

* Conjur implements full-featured role-based access control for both "carbon" (people) and "silicon" (VMs, servers, containers, and other code)

* Conjur solves not just secrets management, but also SSH access management and software-defined firewall (granular access control for microservices)

* The Conjur core services are not open source, but our cryptography is (https://github.com/conjurinc/slosilo), as are many of our client libraries and connectors (for example: https://github.com/conjurinc/api-ruby, https://github.com/conjur-cookbooks/conjur). And Conjur cryptography has been audited by a respected 3rd party.

* Conjur features packaged integrations with Chef (https://supermarket.chef.io/cookbooks/conjur), Puppet (https://forge.puppetlabs.com/conjur/conjur), Docker (http://developer.conjur.net/product_demo/secrets.html), Heroku (https://github.com/conjurinc/heroku-buildpack-conjur), AWS and more. New integrations are easy to build using the Conjur HTTPS and LDAPS APIs (http://developer.conjur.net/reference/services)

We have also gone to great lengths to make it easy to try Conjur yourself, with automatically provisioned, self-service demo appliances featuring the Conjur server and client, Docker and Git:

https://demo-factory-conjur.herokuapp.com/request/secrets

https://demo-factory-conjur.herokuapp.com/request/ssh

Re: Vault – A tool for managing secrets

#86

Post by kgilpin »

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…

Using an instance id or MAC address as a secret 2nd factor seems surprising to me. This is what banks are asking for? It's nice that there are two factors to the authentication, but neither one seems to be securely random.

Re: Vault – A tool for managing secrets

#87

Post by kgilpin »

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…

There's a lot of variability in cloud architectures, and for that reason there's really no one-size-fits-all solution for machine authentication. Sometimes using factors like the network subnet for machine authentication makes sense and adds something; sometimes it doesn't. It's definitely a factor to consider though.

Another example : in AWS, IP spoofing is not possible (according to https://ip-saas-infopark23444378-cms.s3-eu-west-1.amazonaws....). So IP address is a reliable identifier. However, IP addresses of AWS instances are sometimes stable over time, and sometimes not. It depends on how the instance is configured and used. So again, IP address is a potential authentication factor, but there's no "one true solution".

And even once a machine is authenticated, it needs to be associated with some kind of role (or a role-like thing). This part is actually even trickier.

Re: Vault – A tool for managing secrets

#88

Post by kgilpin »

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…

Also, when you are talking about container-based cluster deployment, the network (IP addresses, VPC, subnets etc) is useless for machine authentication, because any container in the cluster can run on any host machine at any time. As an example, Heroku is basically a giant compute cluster in a single security group (for each region).

They used to publish the security group ids, so that you could whitelist inbound traffic from Heroku. Now they don't do that any more, which makes sense because really, what is the point of whitelisting all of Heroku? :-)

Re: Vault – A tool for managing secrets

#89

Post by mitchellh »

kgilpin wrote: post #86
mitchellh wrote: post #19

Earlier quoted context omitted.

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…

Using an instance id or MAC address as a secret 2nd factor seems surprising to me. This is what banks are asking for? It's nice that there are two factors to the authentication, but neither one seems to be securely random.

No, it is usually one of those values salted with a value that is only available offline.

Re: Vault – A tool for managing secrets

#90

Post by SEJeff »

mitchellh wrote: post #6
carllerche wrote: post #2

Looks interesting. There is definitely a need for something secure to manage secrets easily & efficiently. I'm not super familiar with Shamir's secret sharing. The post says that the master key is split up across a number of people. One thing that I am confused about is if Vault goes down (possibly in the middle of the night), does it require a quorum of humans to boot it back up?

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?
Post reply on HN