Secrets Management with AWS Secrets Manager and Parameter Store

Every application has sensitive configuration — database passwords, API keys, encryption keys, third-party service credentials. How these values are stored and accessed determines a significant part of your overall security posture.

Hardcoding them in code or storing them in plain text configuration files creates serious risk.

AWS provides two services for managing sensitive configuration securely, Secrets Manager for credentials that need rotation and lifecycle management, and Parameter Store for configuration values that need secure, centralised storage. 

The Core Problem

Applications need sensitive values to function. The challenge is getting those values to the application at runtime without:

1. Storing them in source code — where they end up in Git history.

2. Storing them in environment files on servers — where they can be read by anyone with server access.

3. Passing them through CI/CD pipeline variables — where they can appear in build logs.

4. Hardcoding them in container images — where they are visible to anyone who pulls the image.

Secrets Manager and Parameter Store solve this by acting as a secure vault — applications retrieve secrets at runtime through an API call, and the values never need to be stored anywhere they could be accidentally exposed.

AWS Secrets Manager

Secrets Manager is designed specifically for sensitive credentials that have a lifecycle — they are created, used, rotated, and eventually retired. It is the right choice for database passwords, API keys, OAuth tokens, and certificates.

How It Works

An application calls the Secrets Manager API at startup or when it needs a credential. Secrets Manager returns the current value. The application uses it. The value is never stored anywhere persistently — it exists only in memory during execution.

Automatic Rotation

This is the defining feature of Secrets Manager. You configure a rotation schedule — every 30 days, every 90 days — and Secrets Manager automatically generates a new credential, updates the secret value, and updates the target service.

For supported databases — RDS, Redshift, DocumentDB — rotation is built in with no custom code required.

For other services, you provide a Lambda function that handles the rotation logic. Secrets Manager calls it on schedule.

Why rotation matters: Long-lived, static credentials are a significant security risk. A credential that was leaked six months ago and never rotated is still valid and exploitable. Automatic rotation limits the window of exposure for any compromised credential.

Versioning

Every time a secret is rotated, the previous value is retained as a previous version. This allows applications that have not yet refreshed their cached credential to continue working during the rotation window — and allows rollback if a rotation causes issues.

Cross-Account Access

Secrets Manager supports cross-account access through resource-based policies. A Lambda function in a production account can retrieve a secret stored in a central security account, keeping all credentials in one governed location while allowing access from multiple accounts.

AWS Systems Manager Parameter Store

Parameter Store is a broader configuration management service. It stores both plain text configuration values and encrypted sensitive values, and it costs less than Secrets Manager for simple use cases.

Parameter Types

SecureString parameters are encrypted at rest using AWS KMS. Decryption happens automatically when your application retrieves the parameter with the WithDecryption flag — assuming the IAM role has permission to use the KMS key.

Parameter Hierarchy

Parameter Store supports a hierarchical naming structure using forward slashes. This makes parameters easy to organise and apply IAM policies to entire branches of the hierarchy:

A production service can be granted access to /myapp/production/* only — it cannot read staging parameters. A developer can be granted read access to /myapp/staging/* — they cannot access production values.

Parameter Store Tiers

1. Standard tier — Free for up to 10,000 parameters. Suitable for most use cases.

2. Advanced tier — Supports larger parameter values, parameter policies, and higher throughput. A small monthly cost per parameter.

3. Parameter policies — Available in the advanced tier, parameter policies define expiration dates and notification triggers for parameters. You can configure a parameter to expire after 90 days and receive an SNS notification 14 days before expiry — prompting rotation before the credential becomes a risk.

Secrets Manager vs. Parameter Store

The practical rule — if it needs automatic rotation, use Secrets Manager. If it is configuration or a secret that does not change frequently, use Parameter Store.

Accessing Secrets at Runtime

The correct pattern for every service type:

1. Lambda functions: Retrieve secrets in the function initialisation code — outside the handler, so the value is cached for the lifetime of the execution environment. Use the AWS SDK to call Secrets Manager or Parameter Store. The Lambda execution role must have permission to retrieve the specific secret.

2. ECS tasks: Reference secrets directly in the task definition. ECS retrieves the secret value from Secrets Manager or Parameter Store at task launch and injects it as an environment variable. The task role must have retrieval permission.

3. EC2 instances: The AWS SDK in your application startup code to retrieve secrets via the instance role. Never write secrets to disk on the instance.

4. CodeBuild pipelines: Reference Secrets Manager and Parameter Store directly in the buildspec.yml env section. CodeBuild retrieves values at build start and injects them as environment variables. They appear in the build environment but never in the source code or the build logs.

Auditing Secret Access

Every call to Secrets Manager and Parameter Store is logged in AWS CloudTrail. This gives you a complete audit trail, which application retrieved which secret, at what time, from which IP address, using which IAM role.

Enable CloudTrail in every account and set up CloudWatch alarms for unusual secret access patterns, a secret being retrieved from an unexpected IP address, an unusual spike in retrieval calls, or a secret being accessed by an unexpected role.