<p>I typically treat secrets as configuration data in scope.  As such, it does not live alongside the code as they are handled by different release schedules and processes.  A separate git repo, KMS, dynamo, s3, or inside your config management system (chef-vault/encrypted database in the chef world) are good places.  Basically, you don't want to have to build and deploy a new release of your software to get a secret updated.</p>

<p>If you secrets management needs are more complex, something like Hasicorp Vault (<a href="https://github.com/hashicorp/vault" rel="nofollow noreferrer">https://github.com/hashicorp/vault</a>) would be a good option.</p>

CC BY-SA 3.0
2017-03-24T15:25:37.623Z
2017-03-24T15:25:37.623Z
Matt
<p>There are a couple of elements to consider here:</p>

<ol>
<li><p>It is valuable to have the capability to maintain configuration with a separate release cadence from the code that is being configured. Doing so encourages rotation of credentials in an automated manner, do it regularly make it painless.  </p></li>
<li><p>It is entirely reasonable from an "Infrastructure as Code" point of view to store all configuration in Git, albeit probably in a different repository as the scope of configuration is likely to span more than one service.</p></li>
<li><p>Assuming both of the above statements are relevant to your situation, I would be inclined to encrypt the data with KMS and store it in S3 or DynamoDB.  I would even go so far to say that in very simple situations it might be suitable to <a href="https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html" rel="noreferrer">encrypt and store the data within KMS itself.</a></p></li>
</ol>

<p>There are several open source libraries that will support this operation:</p>

<ul>
<li>Python: <a href="https://pypi.python.org/pypi/creds3" rel="noreferrer">CredS3</a></li>
<li>Go: <a href="https://github.com/codahale/sneaker" rel="noreferrer">Sneaker</a></li>
</ul>

CC BY-SA 3.0
2017-03-17T23:40:44.177Z
2017-03-17T23:40:44.177Z
Richard Slater
<p>With serverless.com, the easiest way to expose a secret to an AWS Lambda function is to store it in the <code>serverless.yml</code> file (encrypted with KMS, for example).</p>

<p>But committing encrypted secrets to Git is not the best thing in the world. Requires code changes when the secret has to change, for one thing.</p>

<p>But in terms of security alone, what are better alternatives? e.g. the secret could be stored in S3 (encrypted), with the Lambda given access to that location and KMS key, but is that actually better in any meaningful way?</p>

CC BY-SA 3.0
2017-03-24T16:14:21.853Z
this opinionphobia semantic gymanstics interests me not.
Assaf Lavie
<security><aws-lambda><serverless><encryption>
How to storing encrypted secrets in code for a serverless.com project?
Assaf Lavie
# How to storing encrypted secrets in code for a serverless.com project?

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

With serverless.com, the easiest way to expose a secret to an AWS Lambda function is to store it in the `serverless.yml` file (encrypted with KMS, for example).

But committing encrypted secrets to Git is not the best thing in the world. Requires code changes when the secret has to change, for one thing.

But in terms of security alone, what are better alternatives? e.g. the secret could be stored in S3 (encrypted), with the Lambda given access to that location and KMS key, but is that actually better in any meaningful way?

**Tags:** security, aws-lambda, serverless, encryption

> **Comments:**
> **username_0**: this opinionphobia semantic gymanstics interests me not.  

---

## 2 answers

### Answer by username_2 on 2017-03-17. Score: 7 | Accepted answer

There are a couple of elements to consider here:

1. It is valuable to have the capability to maintain configuration with a separate release cadence from the code that is being configured. Doing so encourages rotation of credentials in an automated manner, do it regularly make it painless.
2. It is entirely reasonable from an "Infrastructure as Code" point of view to store all configuration in Git, albeit probably in a different repository as the scope of configuration is likely to span more than one service.
3. Assuming both of the above statements are relevant to your situation, I would be inclined to encrypt the data with KMS and store it in S3 or DynamoDB. I would even go so far to say that in very simple situations it might be suitable to [encrypt and store the data within KMS itself.](https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html)

There are several open source libraries that will support this operation:

* Python: [CredS3](https://pypi.python.org/pypi/creds3)
* Go: [Sneaker](https://github.com/codahale/sneaker)


---

### Answer by username_1 on 2017-03-24. Score: 1

I typically treat secrets as configuration data in scope. As such, it does not live alongside the code as they are handled by different release schedules and processes. A separate git repo, KMS, dynamo, s3, or inside your config management system (chef-vault/encrypted database in the chef world) are good places. Basically, you don't want to have to build and deploy a new release of your software to get a secret updated.

If you secrets management needs are more complex, something like Hasicorp Vault (<https://github.com/hashicorp/vault>) would be a good option.


---

