confidant

We initially looked around, and here are a few alternatives: - Azure Key Vault: https://azure.microsoft.com/en-us/services/key-vault/ - Blackbox: https://github.com/StackExchange/blackbox - CredStash: https://github.com/fugue/credstash - Lyft Confydant: https://github.com/lyft/confidant - Trousseau: https://github.com/oleiade/trousseau - Sneaker: https://github.com/codahale/sneaker Some of these didn't exist when we were first investigating proper secret management, while others didn't fit as well with our deployment strategy. We're using what works when it makes sense - Blackbox is used in some repos, for instance - but I'll be sure the next time we have an internal doc like this that we cover why we didn't choose a different set of tools. One thing we liked about Vault is that it built upon our usage of Consul a

Encrypted S3 is definitely an option. The difficulty there is how to manage secrets that may be shared across services and how to ensure that there's no race conditions between updates of secrets. Confidant provides access to credentials by IAM role. The key here is that you can have credentials A, B, and C, and IAM roles example1-production, example2-production and example3-production, then map credentials A and B to example1-production, A and C to example2-production and A to example3-production. Confidant just stores mapping info for this. If you update A, you don't need to fan out an update to all three services. Race conditions can come in when A and B or C are updated at the same time. S3 is very eventually consistent and there's no locking. read-after-write consistency is only available in one region at this point. Of course, this

This is the first time I've seen a nicely documented requirements.txt and I like! https://github.com/lyft/confidant/blob/master/requirements.t...