How to Manage Secrets Securely with AWS Secrets Manager and Lambda

Introduction

In modern cloud-native applications, managing sensitive information like API keys, database credentials, any third party service credentials and other secrets securely is a top priority. Hardcoding secrets into application code, environmental variables in lambda functions or configuration files can lead to serious security vulnerabilities and operational risks and this is where AWS Secrets Manager comes in—a fully managed service that enables you to store, retrieve, and rotate secrets securely.

When combined with AWS Lambda, Secrets Manager allows you to build powerful serverless applications that access secrets dynamically during the runtime, without ever exposing them in your codebase. In this blog, we'll explore how to integrate AWS Secrets Manager with Lambda functions, ensuring your application remains secure, scalable, and maintainable. Whether you're accessing a database, calling a third-party service, or simply avoiding secret sprawl, this guide will walk you through best practices and hands-on examples for secure secret management in AWS.

Creating a Secret in AWS Secrets Manager

The first step is to store your credentials in AWS Secrets Manager based on the type of secret you want to manage. When you open the service, you’ll start by choosing the secret type. For this tutorial, we’ll use “Other type of secret” and store an API key. 

You can store secrets in two ways: as key/value pairs or as plain text. Here, we’ll go with the key/value option, setting the key as api_key and assigning its value to the API key for your endpoint. 

Next, select the KMS encryption key to protect your secret. If you already have one, choose it; otherwise, create a new key. (I’ve already covered how to create and manage KMS keys in my earlier blog on KMS Server-Side Encryption.)

Finally, give your secret a meaningful name so it’s easy to find later. Continue to the next step where you’ll see the secret rotation option. For now, we’ll keep rotation disabled, but AWS Secrets Manager also allows you to configure automatic rotation by creating a custom Lambda function that securely updates your secrets on a schedule.

Attach IAM Policy to Your Lambda Role

Before your Lambda function can fetch secrets from AWS Secrets Manager, it needs the right permissions. This is where IAM roles come into play. 

So, don’t forget to attach the Secrets Manager policy to the Lambda execution role. At a minimum, you’ll need the following permission:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:REGION:ACCOUNT_ID:secret:YOUR_SECRET_NAME"
    }
  ]
}

Repalce with your REGION, ACCOUNT_ID and YOUR_SECRET_NAME in the resource field.

Accessing Secrets from Lambda

Now that we’ve stored the secrets and given Lambda the right permissions, it’s time to actually fetch the secret inside our function.

Here’s a simple example:

# Add this code snippet in lambda function to retrieve keys.
# You need to change the secret_name and region name with yours secret and region name.

import boto3
from botocore.exceptions import ClientError


def get_secret():
    secret_name = "api_key" # Replace here with your secret name
    region_name = "us-east-1" # Replace here with your region name


    # Create a Secrets Manager client
    session = boto3.session.Session()
    client = session.client(
        service_name='secretsmanager',
        region_name=region_name)

    try:
        get_secret_value_response = client.get_secret_value(
            SecretId=secret_name)
        
    except ClientError as e:
        raise e

    secret = get_secret_value_response['SecretString']

    return secret

Conclusion

Managing secrets the right way is crucial for building secure applications in the cloud. By using AWS Secrets Manager with Lambda, you can keep sensitive information out of your code, control access with IAM, and even enable automatic rotation when needed. This approach not only improves security but also makes your applications easier to maintain. Start small by securing one secret, and gradually extend this practice across your entire serverless stack.