Injecting Sensitive data as Environment Variables to Lambda Functions

Hi,

If you're using CloudFormation to deploy your lambda functions, you can use dynamic references as per this section of the documentation.

Example using AWS SAM (with some properties omitted for brevity):

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      [...]
      Environment:
        Variables:
          SECRET_STRING: '{{resolve:secretsmanager:my/secret:SecretString:secretkey}}'

A different option for both, Lambda and ECS can be dynamically read from SecretsManager in the code of your application instead of using Environment Variables.

You need to add a policy to IAM Role for Lambda and TaskRole to access SecretsManager. Then you can get the value using AWS SDK.

An advantage of this solution is that even if the secret change, you can refresh it in the app, so you don't need to redeploy the app. It is also more secure because the secret is not visible anywhere in plain text.

A disadvantage is that it can cost more because you will pull the value more often but it can be cached. Example in .net.

Or a more cost-efficient solution with SSM Parameter Store.

I faced the same issue on my lambdas and I chose to use SSM Parameter store Secure Strings instead of Secrets Manager for the following reasons.

1. Cost. Each secret costs .50 per month whereas secure strings are essentially free (each 10000 decrypts costs .05)
2. Consolidated storage. I have all my other lambda parameters in the parameter store so everything is in one place.

Now the only env variable I pass to my lambda is the region where the parameters are stored. When the lambda starts, it calls the store and gets everything it needs.

The main advantage of secrets manager is auto rotation of passwords. When the password rotates AWS takes care of updating secrets manager. Using Parameter Store you would need to change the password manually or create a lambda function to update it. This is not a major concern for my use case.

Just one point worth noting. Put your API calls to the Parameter Store or Secrets manager into some type of init function instead of the handler so the API is only called once when the lambda starts instead of every time the handler is called.

If you want to pass sensitive information to lambda, you can't pass this directly as plain text to lambda. This is because your sensitive data will be visible in environment variables section of aws lambda service in aws console.

Instead, you can use either Parameter store or Secret Manager to store the secrets and pass the ARN of the secret as environment variable to AWS Lambda and your lambda can fetch the secret by communicating with respective service.

Please note that your lambda should have necessary role to communicate and fetch the secret. I've written detailed step-by-step guide to do the same here - https://www.cloudtechsimplified.com/environment-variables-secrets-database-password-aws-lambda/

You can use either Parameter Store or Secret manager for storing the secret and within your lambda function - you can retrieve the secret dynamically and use that secret accordingly.

I've written detailed step by step guide on how to use this here -https://www.cloudtechsimplified.com/environment-variables-secrets-database-password-aws-lambda/