News for hackers. Stuff that matters.
Re:Secret Management with Vault by wise0wl on Friday October 28, 2016 @04:24PM (#12820278)
At work, we are using Vault and have nothing but good things to say. It is a pleasure to work with. Use Consul as the storage backend and it is instantly highly available. There is a bit of a learning curve, and common implementation strategies aren't very well spelled out. However, this is all fairly easily deduced from reading the documentation. A+, would recommend.
Re:Secret Management with Vault by OhSoHumble on Friday October 28, 2016 @05:04PM (#12820684)
The current problem I'm facing with figuring out how to implement Vault is how to tie it into Chef - which is our de facto CFM. The initial trust phase is kind of hard to figure out.
Re:Secret Management with Vault by doublerebel on Friday October 28, 2016 @05:52PM (#12821068)
This is a common question, a good solution is the "cubbyhole" technique.

https://www.hashicorp.com/blog/vault-cubbyhole-principles.ht...

I prefer the "pull" model, it can be done with a few lines of code in the CD process: First from the deployer to authorize a new instance, and second on the app/instance to request the token.

Re:Secret Management with Vault by bogomipz on Friday October 28, 2016 @06:13PM (#12821215)
I have read the cubbyhole doc and I understand there are two authentication mechanisms as the doc mentions - machine and user oriented. Can you explain how this helps integrate with config management such as Chef and Puppet etc as the OP above was asking. For some reason I'm just not getting it reading the Hashicorp Doc. Thanks.
Re:Secret Management with Vault by doublerebel on Friday October 28, 2016 @06:18PM (#12821249)
Have the temp token generated as part of the deployment process. This temp token can be shown in plaintext to the developer/CD machine/Chef/logs because it is use- and time- limited. If anything besides the new app uses the temp token, the deployment will fail and the token usage can be easily traced to the offender.

Regarding machine- or user- oriented, it just depends on whether you trust the deployer (user) or the deployment machine to authorize a new temp token.

Re:Secret Management with Vault by tonyarkles on Friday October 28, 2016 @06:59PM (#12821492)
A client of mine has a number of windows machines, and a well-organized Active Directory setup. The small group of users who need to be able to create deployment tokens are all in an AD group, and it was pretty straightforward to use the LDAP auth backend with vault to allow them to create those one-time use tokens using their normal network logins. Everyone's super impressed so far.
Re:Secret Management with Vault by OhSoHumble on Friday October 28, 2016 @06:52PM (#12821447)
I'll look into this more. I'm a simple guy so hopefully my initial forays produce fruit easily. Maybe I'll luck out and there will be a blog post from someone on how to implement this specifically with AWS and Chef.
Re:Secret Management with Vault by empath75 on Friday October 28, 2016 @07:49PM (#12821738)
There's an AWS based auth method based on iam roles and ami ids. Takes a few minutes to set up.

https://www.vaultproject.io/docs/auth/aws-ec2.html

Re:Secret Management with Vault by bogomipz on Friday October 28, 2016 @06:28PM (#12821314)
I see, that makes sense. Thanks for the good explanation.
Re:Secret Management with Vault by cheeseprocedure on Friday October 28, 2016 @05:29PM (#12820910)
Where are your services hosted?
Re:Secret Management with Vault by OhSoHumble on Friday October 28, 2016 @05:50PM (#12821055)
AWS. I thought about using the AWS EC2 auth provider to grant a temporary lease that is fed into consul template so that template can pull down additional information.

https://www.vaultproject.io/docs/auth/aws-ec2.html

But it's all in my head and I haven't gotten around to planning this out. It looks like once the initial trust is granted then hooking up consul template and chef is pretty straight forward. At least, that's what I got from Seth Vargo's post on using Chef and Vault.