0

My AWS Lambda function needs to be populated with env vars that contain sensitive values, like a master db password.

The new env vars feature of Lambda makes this super-simple. But it's a little fuzzy as to what the best practice is, or how to go about achieving it.

In the Lambda FAQ, they state the following:

Q: Can I store sensitive information in environment variables? For sensitive information, such as database passwords, we recommend you use client-side encryption using AWS Key Management Service and store the resulting values as cipher text in your environment variable. You will need to include logic in your AWS Lambda function code to decrypt these values.

So they're basically saying that you need to encrypt the values yourself, then input the encrypted value into your Lambda function env vars. Then you need to include logic in your function that will decrypt the value upon instantiation. In pseudo-code, it would look like so:

On Your Laptop

/// Encrypt your password var myDbPassword = '122345'; var encryptedDbPassword = aws.kms.encrypt(myDbPassword, 'my-lambda-env-key'); /// Store it 'on' your Lambda function aws.lambda.env.save('DB_PASS', encryptedDbPassword); 


In Your Lambda Function

And then in your function, you would have logic to decrypt it upon instantiation:

var myDbPassword = aws.kms.decrypt(process.env.DB_PASS, 'my-lambda-env-key'); db.connect('someURL', myDbPassword); 


Simple enough, but any values you input are already encrypted when you input them, and they allow you to choose which KMS key you want to use to encrypt the values, and you can create your own KMS key and use that instead of the "default" key.

So, what's the point of encrypting the values before input? If you can tell Lambda to use your my-lambda-env-key key for the encryption isn't that the same as using the my-lambda-env-key key to encrypt the values on your laptop before sending them to Lambda?

2
  • As a solo-dev that works from home, it just occurred to me that I've forgotten about Over-The-Shoulder attacks. My cat rarely hacks my DB that way. Commented Dec 1, 2016 at 10:12
  • 2
    I would never trust a cat... Commented Dec 1, 2016 at 23:33

1 Answer 1

2

This construct helps to hide the actual password from the developer of the Lambda function (e.g. if you outsource develoment). In this case you give the KMS key to the developer, but not the master password for the DB.

Then you take delivery of the function, deploy it in your AWS account, configure the environment variable and you are good to go. This also allows you to change your DB password without changing the source code of the Lambda function.

Sign up to request clarification or add additional context in comments.

4 Comments

That sounds true~ish. If you're providing the KMS key to an outsourced dev, and the KMS key can be used to obtain the DB password, what's to stop the outsourced dev from simply using the KMS key and console.logging() the DB password?
You do not give the outsourced developer the right to run code in a production environment. They can only run code in a dev or staging environment (that uses other passwords). If you take their code and run it in production, then you do not need to modify it at all because the actual credentials are "injected" and decrypted via KMS.
@Digitalkapitaen I don't get it still. Your point is related to just using different env vars in production. It has nothing to do with encryption. The question that why you encrypt in the first place if in the code the encrypted will be decrypted by the key you provided, still remains.
@Arbitrary Because one should encrypt everything, especially if it is at rest. Specifically: Encrypting credentials and only decrypting them when they are actually used is good practice to limit the attack surface as much as possible.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.