Where do you keep credentials for your Lambda functions?

Davide de Paolis
Apr 29, 2019 · 5 min read

If your Lambda function has to access a Database ( or any other service that requires credentials) where and how do you store that configuration?

Recently we have been iterating over our MVP and the requirements and size of our app grew a bit and we have been discussing how to handle safely the configuration of the Database for different environments/stages and relative user/passwords.

There are a lot many possibilities, let’s look at some of them:

Just keep the host, user and password hardcode in your files.

Image for post
Image for post

Please don’t. Should I really tell you why?

Use a .env file — which is committed to the repo

Image for post
Image for post

Even though this solution might allow a bit more flexibility it is still very bad. Everyone that can access your repo can immediately see your credentials.

Use a .secrets file ( basically the .env file above but encrypted via serverless secrets plugin

Image for post
Image for post

This was our very first quick approach but it didn’t really prove well because:

  • the credentials are clearly visible in the AWS UI Console once the lambda function is deployed ( env variables are baked into the code at deploy time)
  • the risk of someone committing by mistake the decrypted file was high
  • we had to duplicate those files in many repos sharing similar credentials
  • most of all, the question arose — where do we store the password to decrypt those secrets?

Use a SSM encrypted env variable in your serverless.yml

Image for post
Image for post

This is a step further from the secrets-plugin, AWS Systems Manager Parameter Store allows you to get rid of the file and have only one configuration shared by many lambda/repos that can be quickly updated via AWS UI Console or AWS CLI, but it has the same drawbacks:

  • the configuration values are stored in plain text as Lambda environment variables — you can see them in clear in the AWS Lambda console — and if the function is compromised by an attacker (who would then have access to process.env) then they’ll be able to easily find the decrypted values as well- (this video explains how )
  • since you are deploying your code together with the env variables, if you need to change the configuration you need to redeploy, every single lambda to propagate all the changes.

Access SSM or SecretsManager at runtime ( and use caching )

Image for post
Image for post

Store your credentials safely encrypted on Systems Manager Parameter Store or on Secrets Manager ( which allows also automatic rotation ) and access them at runtime.
Then configure your serverless yaml granting access to your lambda via IAMRole Policies:

You can set this permission with growing levels of granularity

The code above is specifying directly your ARN / Region / Account — if you want to be more flexible you can set up the permission to grab those value automagically:

Since SecretsManager is integrated with ParameterStore you can access your secrets via SSM just prepending your Key with aws/reference/secretsmanager/

If you start playing around with these permissions ( especially if editing the policy in the UI console — and not redeploying the lambda — may take some time. normally in seconds, but it can happen that it is 2–5 minutes)

Once you have granted your lambda access to your secrets you can specify an environment variable to simply tell your lambda which credentials to load at runtime based on the environment/stage:

This is a nifty little trick to apply a kind of conditionals to serverless deployment. Basically, you are telling serverless that you have three Secrets Keys: one for production, one for development and one for all other stages.
In the environment node of the lambda function then you set the key based on the current stage being deployed. If the current stage matches one of the variable names in the list it will be picked, otherwise, it will fallback to the ´other´ one.

Inside your lambda then, you just have to load the credentials from SSM or SecretsManager and connect to your DB.

Remember to implement some sort of caching so that when the lambda container is reused you avoid loading the keys from AWS ( and incurring in additional costs)

Something that I like to point out is that SSM requires the aws-region being defined at instantiation. As you see I am not passing that value though. That’s because process.env.AWS_REGION is read automatically from AWS SDK and that env var is set by serverless offline.

You will not need to do anything until you have some integration tests trying to load the secrets - we added some tests to be sure after every deployment, that the secret for that env-stage was available on SecretsManager. In that case you must pass that variable to the integration tests ( remember to manually pass it to integration tests).

This is our npm script (we are using AVA for tests and Instanbul/nyc for code coverage):

Do you have any other approaches to deal with this common — i’d say basic/fundamental — feature?

More resources on the topic:

Originally published at https://dev.to.



Sign up for Get Better Tech Emails via HackerNoon.com

By HackerNoon.com

how hackers start their afternoons. the real shit is on hackernoon.com. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Davide de Paolis

Written by

Sport addicted, productivity obsessed, avid learner, travel enthusiast, expat, 2 kids. Technical Lead (NodeJs Serverless)


Elijah McClain, George Floyd, Eric Garner, Breonna Taylor, Ahmaud Arbery, Michael Brown, Oscar Grant, Atatiana Jefferson, Tamir Rice, Bettie Jones, Botham Jean

Davide de Paolis

Written by

Sport addicted, productivity obsessed, avid learner, travel enthusiast, expat, 2 kids. Technical Lead (NodeJs Serverless)


Elijah McClain, George Floyd, Eric Garner, Breonna Taylor, Ahmaud Arbery, Michael Brown, Oscar Grant, Atatiana Jefferson, Tamir Rice, Bettie Jones, Botham Jean

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store