11

Everyone is saying that storing credentials in version control (git) is a bad thing. So there must be other ways to store credentials which are much better.

An application must receive credentials from somewhere to use services it depends on. These credentials are usually stored in configuration files. Manually entering each server to create that file is out of the question, since servers come and go without human intervention.

How to manage an application's credentials?

  • 2
    Also this is probably too broad for a single answer that isn't the size of a book. – coderanger Mar 1 '17 at 19:59
  • 1
    @coderanger Watching your presentation, your categorization of the different types of secrets is great. And I can see how you think its a book ... but the question above doesn't ask for a classification, only a solution(s) to a specific problem. – Evgeny Mar 1 '17 at 20:01
  • 2
    If you have a specific situation, then please edit the question to include more details like the type of secret being used (database password, TLS keys, etc). – coderanger Mar 1 '17 at 20:28
  • 1
    This is too broad. There's at least 14 tools available out there to do this, not including custom scripting or templates: gist.github.com/maxvt/bb49a6c7243163b8120625fc8ae3f3cd Additional details are required (like is an CLI is required, is it for cloud-native solution or for big monolithic applications, etc.) – Alexandre Mar 1 '17 at 20:28
  • 1
    @Alexandre Hah, I opened that and thought "yay a good compilation list" and then see myself cited at the bottom :) – coderanger Mar 1 '17 at 20:36
5

Proper management of an application's secrets has always been a challenge. New challenges came with the adoption of the cloud. There's a great OWASP presentation about the reality and challenges of storing secrets in the cloud.

You might be surprised to hear that storing secrets into the source code is one of the solution (or "architecture") presented. That's because, right now, there is no perfect architecture or way of doing this. In the end, your secrets might be encrypted... but what is guarding the encryption key? "Turtles all the way down", they said.

Every type of secret management has its strengths and weaknesses and the presentation already covers that. Instead, I'll try to go over some of the features you might be looking for in an secret (credential) management solution:

  • Access control: can you give write access to admins and read access to applications? Can you limit what applications are able to read (application A has access only to those secrets)?
  • Audit logs: required for many compliancy reports and a good way to figure if something is awry
  • Secure storage of the secrets: how is the solution storing the secrets? Encrypted DB? Encrypted FS? Who/what holds the encryption key, if any? How is this key used - once at startup and then securely discarded?
  • Keys/passwords rotation or renewal: if a secret is compromised, can you revoke it and send an updated secret to the applications? Can/should the applications pool the secret management service?
  • Compatibility: Some of these solutions offer tight integration with certain languages or framework. Some offer REST API. Are you interested in this?

By looking at these items, how they are important to you and how they are implemented by the solution, you will be able to choose one of the secret management service out there.

3

For a purely EC2-based environment, the easiest solution is to use AWS IAM roles and S3 bucket policies. Some formulations of this pattern also include KMS for encryption and DynamoDB instead of S3 for storage but I've not found a hugely compelling reason to use either. Check out https://github.com/poise/citadel, it is specifically aimed at Chef users but the underlying pattern works for anything, you just might have to make your own helper for doing the actual download from S3.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.