I used Marathon and Mesos and rolled my own pub/priv encryption for our developers JSON (encrypted the ENV parameters POSTed to Marathon): https://github.com/malnick/mantle
Ask HN: In a microservice architecture, how do you handle managing secrets?
21–30 of 60 posts
Re: Ask HN: In a microservice architecture, how do you handle managing secrets?
#22Azure Key Vault! Disclosure: am dev in Azure, although not on this specific product. https://azure.microsoft.com/en-us/services/key-vault/
Azure Key Vault is a great component but it's a component not a solution. By way of example, Key Vault's hardware "secrets check in but they don't check out" capability is awesome for preventing disclosure of secrets but if you don't have a system for adequately managing who/what can use the contained key to sign messages all you've done is add a complex and pricey piece of security theater (but as I mention elsewhere our primary concern is making sure whatever secret management we use helps us defend against at least the early stages of compromise of our infrastructure)
Re: Ask HN: In a microservice architecture, how do you handle managing secrets?
#23A simple solution if you are in AWS is S3 with instance profiles for access.
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 example, config.json or whatever format you choose.
4) On your instance or container, use the aws-cli on when your app starts to copy that file down from S3, then read it into memory in your application and then delete it.
It's a bit of a hack but you can now easily restrict access to that secrets bucket, and only your running instances/containers can access it. The secrets only exist in running app memory. Now don't allow SSH access to those instances :)
Re: Ask HN: In a microservice architecture, how do you handle managing secrets?
#24A simple solution if you are in AWS is S3 with instance profiles for access.
Yes, but is there a succinct howto on this?
1) Have an EC2 instance with a role-specific IAM Role
2) Create a S3 bucket
3) Write a bucket policy that whitelists specific IAM Roles to specific key paths within the bucket.
Re: Ask HN: In a microservice architecture, how do you handle managing secrets?
#25it's a huge pain point for us. We're a .NET shop rolling our own that mimics/overlays app.config and web.config patterns for both dev and production usage. Our concern is less on how do you get the secrets to the box (though that's obviously important) and more on how do you keep an attacker who has started penetrating your infrastructure from gaining control of the infrastructure that holds your secrets.
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 in principle but with different implementations for the different platform details. If it's not super easy for the dev to drop into a quick test app, they'll "just copy and paste the secrets for now" which is always the path to darkness.
Re: Ask HN: In a microservice architecture, how do you handle managing secrets?
#26We're using Ansible which means we use ansible-vault to store secrets. We store the encrypted files in S3 and decrypt them on deploy as needed.
Re: Ask HN: In a microservice architecture, how do you handle managing secrets?
#27We're using Ansible which means we use ansible-vault to store secrets. We store the encrypted files in S3 and decrypt them on deploy as needed.
So if you potentially need to roll a secret you would just run your deployment playbook limited to the secrets task?
Re: Ask HN: In a microservice architecture, how do you handle managing secrets?
#28We use Kubernetes, which includes its own secrets API: http://kubernetes.io/v1.1/docs/user-guide/secrets.html I can't remember which issue this was on, but it seemed like there was some discussion on their GitHub project about making pluggable secrets backends (HashiCorp's Vault was mentioned). Kubernetes' secrets API is still very basic, but I think the fundamental concept is very sound and has a great foundation to…
> I can't remember which issue this was on, but it seemed like there was some discussion on their GitHub project about making pluggable secrets backends (HashiCorp's Vault was mentioned).
https://github.com/kubernetes/kubernetes/issues/10439#issuec...
Re: Ask HN: In a microservice architecture, how do you handle managing secrets?
#29You should check out Daniel Somerfield's talk at OWASP, "Turtles All the Way Down: Storing Secrets in the Cloud and the Data Center"
Re: Ask HN: In a microservice architecture, how do you handle managing secrets?
#30You can encrypt and deploy secrets using Distelli.
https://www.distelli.com/docs/user-guides/securing-your-appl...
Disclaimer: I'm the founder at Distelli