Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: In a microservice architecture, how do you handle managing secrets?

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Ask HN: In a microservice architecture, how do you handle managing secrets?

#41

Post by kkamperschroer »

steveb wrote: post #40

We have started work on exposing Hashicorp Vault secrets via FUSE and Docker volumes. The expectation is your containers will just mount secrets via a mount like /secret in the container. The project is brand new and we'd love to hear your feedback: https://github.com/asteris-llc/vaultfs

Nice! The FUSE mounting method for obtaining secrets is similar to how Keywhiz does this. Very cool and novel solution. Though, if you are unfortunate enough to still have Windows servers in your architecture, I think you're out of luck.

Re: Ask HN: In a microservice architecture, how do you handle managing secrets?

#43

Post by dsp1234 »

yodon wrote: post #25
voltagex_ wrote: post #18

Earlier quoted context omitted.

Have you had a look at the new ASP.NET Configuration classes? [1] I hate having to manage web.config but I get your point about keeping attackers at bay (and not providing pivot points). [1]: http://docs.asp.net/en/latest/fundamentals/configuration.htm...

Thanks - it's clear MSFT is working hard to get to a place where secret management is a first class part of the dev process and we're attempting to integrate with the classes you mention but as I understand it they only work with ASP.NET 5 so you can't use them in console app based test harnesses or Windows services or etc. That means we end up needing to have a bunch of provider mechanisms, all essentially the same…

It's 100% possible to use the new ConfigurationBuilder class outside of a asp.net site (like a console application). ex: http://stackoverflow.com/questions/31885912/how-to-read-valu...

Re: Ask HN: In a microservice architecture, how do you handle managing secrets?

#45

Post by eropple »

tptacek wrote: post #37
Crystalin wrote: post #6

It also depends on how secret it needs to be. For most of our secrets (those used for configuration) we use Consul.

I think this can be sane when you don't have multiple privilege levels anywhere in the data center you're deploying in. It's less sane if you have less- and more- privileged machines anywhere in the environment, or less- and more- privileged applications. You're putting a lot of faith in a very complex and not- well- tested codebase if you rely on Consul ACLs to protect secrets.

The poor state of its testing is the biggest red flag I have towards Consul. I'm much more positive about it in its way than I am about other Hashicorp tools like Packer and Terraform, if only because it seems like Consul is core enough to the way they want to make money that it's more important to them. But there doesn't seem to be a culture of correctness and strong testing around those tools; trusting my sensitive data to a tool that's as complex and complicated as Consul is worries me. (I feel like it should be normal to have something maintaining my cryptographic secrets to be at least as well-tested as my web framework...)

Of the tools listed in the OP, I feel really good about Square Keywhiz; I'm still rolling it out in my first environment, so I can't say for sure, but I appreciate the level of effort that's gone into only doing secret storage and making sure it is exhaustively tested to spec.

Re: Ask HN: In a microservice architecture, how do you handle managing secrets?

#46

Post by austinjp »

ladon86 wrote: post #23
samstave wrote: post #13

Earlier quoted context omitted.

Yes, but is there a succinct howto on this?

The short version is: 1) Create an S3 bucket. Remove all permissions from it 2) Create an IAM role - give it explicit read permissions to just that bucket (there's a HOWTO at the bottom of this article: http://mikeferrier.com/2011/10/27/granting-access-to-a-singl... ). When you start an ec2 instance, you can give it one (and only one) IAM instance role. 3) Put your secrets or configs in a file on that bucket. For exa…

I'm somewhat naive regarding S3. If data is in RAM, can you prevent it being swapped to disk and read by an unauthorised user?

(I guess "RAM" and "disk" are virtual entities, but hopefully the spirit of the question still applies.)

Re: Ask HN: In a microservice architecture, how do you handle managing secrets?

#47

Post by austinjp »

Is there any detailed opinion on good and bad approaches to this problem? It is clearly a hot topic.

I'm sure each product listed conforms to one from a small set of design patterns. Has any credible analysis of these designs been published? Are competing offerings likely to evolve toward a stable converged solution? Or is there something in this problem that remains fundamentally unsolved?

I appreciate it's turtles all the way down, but I'm wondering if anyone has proven the merits of some approaches over others, or components within the approaches at least.

Re: Ask HN: In a microservice architecture, how do you handle managing secrets?

#48

Post by voltagex_ »

yodon wrote: post #25
voltagex_ wrote: post #18

Earlier quoted context omitted.

Have you had a look at the new ASP.NET Configuration classes? [1] I hate having to manage web.config but I get your point about keeping attackers at bay (and not providing pivot points). [1]: http://docs.asp.net/en/latest/fundamentals/configuration.htm...

Thanks - it's clear MSFT is working hard to get to a place where secret management is a first class part of the dev process and we're attempting to integrate with the classes you mention but as I understand it they only work with ASP.NET 5 so you can't use them in console app based test harnesses or Windows services or etc. That means we end up needing to have a bunch of provider mechanisms, all essentially the same…

Maybe a local (LAN?) NuGet feed with your preferred mechanism would help with the dev experience? You could even go as far as deploying custom templates. I don't think the new Configuration classes are limited to ASP.NET any more - and from the response I got on the issue tracker, if you find any hard dependencies report them as a bug.

Re: Ask HN: In a microservice architecture, how do you handle managing secrets?

#49

Post by ladon86 »

austinjp wrote: post #46
ladon86 wrote: post #23

Earlier quoted context omitted.

The short version is: 1) Create an S3 bucket. Remove all permissions from it 2) Create an IAM role - give it explicit read permissions to just that bucket (there's a HOWTO at the bottom of this article: http://mikeferrier.com/2011/10/27/granting-access-to-a-singl... ). When you start an ec2 instance, you can give it one (and only one) IAM instance role. 3) Put your secrets or configs in a file on that bucket. For exa…

I'm somewhat naive regarding S3. If data is in RAM, can you prevent it being swapped to disk and read by an unauthorised user? (I guess "RAM" and "disk" are virtual entities, but hopefully the spirit of the question still applies.)

As the sibling comment to mine points out, the fact that the instance has access to S3 means it's not actually secure - they could just use the aws-cli to copy the file back down again. My comment about deleting the file from disk was a bit silly and doesn't add any true security.

Really, you need to just make sure that the instance is secure. The point of this whole setup is not to make secrets unobtainable if someone compromises your app server; it is to prevent you from checking in production database passwords and secrets to your code repository.

Re: Ask HN: In a microservice architecture, how do you handle managing secrets?

#50

Post by whisk3rs »

For AWS users, KMS's GenerateDataKey is a simple way to store secrets locally in a way that reuses your IAM policies. You can also use grants and EncryptionContext to restrict the ability to decrypt secrets in a very fine-grained manner. As a bonus, all decrypts are logged in CloudTrail. The KMS docs are awful but if you're on AWS then it is worth checking out!
Post reply on HN