Managing Secrets with AWS Secrets Manager for Developers

Previously in this course, we discussed Security Hardening for Serverless: A Guide to IAM and Secrets, which established why hardcoding credentials is a critical failure. This lesson adds the practical "how-to" for implementing that security, showing you how to replace plaintext configuration with the robust, encrypted storage of AWS Secrets Manager.

Why Secrets Manager?

In your current application, you might be tempted to use environment variables for things like third-party API keys or database passwords. While better than hardcoding, environment variables are often visible in the AWS Console and potentially logged in CI/CD pipelines.

AWS Secrets Manager provides:

• Encryption at rest: Automatically encrypted using AWS KMS.
• Automatic Rotation: Integrated capability to rotate passwords periodically without code changes.
• Auditability: Every time a secret is accessed, it’s logged in AWS CloudTrail, so you know exactly who or what accessed your data.

Creating Your First Secret

You can create secrets via the AWS Console, but for our infrastructure-as-code workflow, we'll focus on the manual setup for understanding, then use the AWS SDK to retrieve them.

1. Navigate to the Secrets Manager dashboard in the AWS Console.
2. Click Store a new secret.
3. Select Other type of secret.
4. Create a key/value pair (e.g., Key: API_KEY, Value: super-secret-value-123).
5. Name it prod/my-app/api-key.
6. Complete the wizard. Note the Secret ARN—you will need this for your IAM policies.

Granting Lambda Access

Secrets are useless if your Lambda can't see them. You must grant the function's Execution Role permission to call secretsmanager:GetSecretValue.

In your CDK stack (following the patterns from Project Integration: Exposing the API with AWS CDK), add this permission to your Lambda role:

TYPESCRIPT
// Assuming CE9178">'myLambda' is your Function object
secret.grantRead(myLambda);

Behind the scenes, this creates an IAM policy that looks like this:

JSON
{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "arn:aws:secretsmanager:region:account:secret:prod/my-app/api-key-xyz"
}

Retrieving Secrets in Code

With permissions in place, you use the AWS SDK for JavaScript (v3) to pull the secret into your function's memory at runtime.

JAVASCRIPT
import { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";

const client = new SecretsManagerClient({ region: "us-east-1" });

export const handler = async (event) => {
  const command = new GetSecretValueCommand({
    SecretId: "prod/my-app/api-key",
  });

  const response = await client.send(command);
  const secret = JSON.parse(response.SecretString);

  console.log("Secret retrieved successfully:", secret.API_KEY);
  
  return { statusCode: 200, body: "Secret accessed" };
};

Hands-on Exercise

1. Create: Create a new secret in the console named dev/app/db-password.
2. Permission: Update your Lambda's IAM role to grant secretsmanager:GetSecretValue access to that specific ARN.
3. Code: Modify your current backend Lambda to fetch this secret on startup. Log the value (in a real app, never log secrets!) to verify you successfully retrieved it in your CloudWatch logs.

Common Pitfalls

• Caching Failures: Don't call Secrets Manager on every request. It adds latency and costs money per API call. Fetch the secret once outside your handler function (in the global scope) so it persists across warm starts.
• Hardcoding ARNs: Avoid hardcoding the Secret ARN in your code. Pass the ARN as an environment variable to your Lambda via your CDK stack, then use that variable in your GetSecretValueCommand.
• IAM Bloat: Don't use a wildcard * for the resource in your IAM policy. Always restrict the permission to the specific Secret ARN.

FAQ

Q: Is it cheaper to use Parameter Store or Secrets Manager? A: Systems Manager Parameter Store is cheaper for basic configuration, but Secrets Manager is purpose-built for sensitive data, offering automatic rotation and better security integration.

Q: Can I use this for database credentials? A: Yes, and it's recommended. Secrets Manager can even trigger a Lambda to rotate the database password automatically.

Recap

We've moved from insecure environment variables to managed, encrypted storage. You now know how to provision a secret, apply the principle of least privilege via IAM, and fetch that data securely using the AWS SDK. This is a vital step in Security Hardening for Serverless: A Guide to IAM and Secrets and ensures your application is production-ready.

Up next: Advanced DynamoDB Query Patterns.