<p>Proper management of an application's secrets has always been a challenge. New challenges came with the adoption of the cloud. There's a <a href="http://danielsomerfield.github.io/turtles/" rel="noreferrer">great OWASP presentation</a> about the reality and challenges of storing secrets in the cloud.</p>

<p>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.</p>

<p>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:</p>

<ul>
<li>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)?</li>
<li>Audit logs: required for many compliancy reports and a good way to figure if something is awry</li>
<li>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? </li>
<li>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?</li>
<li>Compatibility: Some of these solutions offer tight integration with certain languages or framework. Some offer REST API. Are you interested in this?</li>
</ul>

<p>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 <a href="https://www.google.com/webhp?sourceid=chrome-instant&amp;rlz=1C5CHFA_enCA708CA708&amp;ion=1&amp;espv=2&amp;ie=UTF-8#q=secret%20management%20service&amp;*" rel="noreferrer">one of the secret management service out there</a>.</p>

CC BY-SA 3.0
2017-03-02T21:41:04.293Z
2017-03-02T21:47:35.997Z
2017-03-02T21:47:35.997Z
Alexandre
<p>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 <a href="https://github.com/poise/citadel" rel="nofollow noreferrer">https://github.com/poise/citadel</a>, 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.</p>

CC BY-SA 3.0
2017-03-02T21:44:40.913Z
For the future, this answers an earlier and more specific version of the question.
coderanger
CC BY-SA 3.0
2017-03-04T05:15:05.910Z
AWS now provides a dedicated service for key-value storage, including encryption via KMS: https://aws.amazon.com/ec2/systems-manager/parameter-store/.
bnzmnzhnz
CC BY-SA 3.0
2017-03-01T20:30:00.513Z
2017-03-01T20:30:00.513Z
coderanger
<p>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.</p>

<p>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.</p>

<p>How to manage an application's credentials?</p>

CC BY-SA 3.0
2017-09-07T05:29:03.997Z
depends on your case, I'd say. Docker has introduces secrets semantics.
Ta Mu
CC BY-SA 3.0
2017-03-01T19:58:40.090Z
In lieu of making this a full answer, check out https://coderanger.net/talks/secrets/ for 30 minutes on this topic.
coderanger
CC BY-SA 3.0
2017-03-01T19:59:15.820Z
Also this is probably too broad for a single answer that isn't the size of a book.
coderanger
CC BY-SA 3.0
2017-03-01T20:01:58.903Z
@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 Zislis
CC BY-SA 3.0
2017-03-01T20:28:03.140Z
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
CC BY-SA 3.0
2017-03-01T20:28:08.867Z
This is too broad. There's at least 14 tools available out there to do this, not including custom scripting or templates: https://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
CC BY-SA 3.0
2017-03-01T20:36:22.470Z
@Alexandre Hah, I opened that and thought "yay a good compilation list" and then see myself cited at the bottom :)
coderanger
CC BY-SA 3.0
2017-03-02T17:09:24.857Z
At the top  you ask how to store credentials, and at the bottom you ask why not store it in git. Sounds like two different questions. Please clarify.
avi
<deployment><security><credentials>
How to store credentials that are required by an application?
Evgeny Zislis
# How to store credentials that are required by an application?

(Asked by: username_0 on 2017-03-01)

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?

**Tags:** deployment, security, credentials

> **Comments:**
> **username_2**: In lieu of making this a full answer, check out https://username_2.net/talks/secrets/ for 30 minutes on this topic.  
> **username_2**: Also this is probably too broad for a single answer that isn't the size of a book.  
> **username_0**: @username_2 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.  
> **username_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).  
> **username_3**: This is too broad. There's at least 14 tools available out there to do this, not including custom scripting or templates: https://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.)  
> **username_2**: @username_3 Hah, I opened that and thought "yay a good compilation list" and then see myself cited at the bottom :)  
> **username_4**: At the top  you ask how to store credentials, and at the bottom you ask why not store it in git. Sounds like two different questions. Please clarify.  
> **username_1**: depends on your case, I'd say. Docker has introduces secrets semantics.  

---

## 2 answers

### Answer by username_3 on 2017-03-02. Score: 8 | Accepted answer

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](http://danielsomerfield.github.io/turtles/) 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](https://www.google.com/webhp?sourceid=chrome-instant&rlz=1C5CHFA_enCA708CA708&ion=1&espv=2&ie=UTF-8#q=secret%20management%20service&*).


---

### Answer by username_2 on 2017-03-01. Score: 4

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.

> **Comments:**
> **username_2**: For the future, this answers an earlier and more specific version of the question.  
> **username_5**: AWS now provides a dedicated service for key-value storage, including encryption via KMS: https://aws.amazon.com/ec2/systems-manager/parameter-store/.  

---

