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?

AJB
  • 7,389
  • 14
  • 57
  • 88

1 Answers1

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.

Digitalkapitaen
  • 2,353
  • 13
  • 17
  • 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? – AJB Dec 17 '16 at 02:44
  • 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 Dec 17 '16 at 07:08
  • @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 Apr 22 '21 at 07:10
  • @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. – Digitalkapitaen Apr 23 '21 at 09:32