Prerequisites

• projectx-prod-vpc has been created with subnets configured.
• My-Desktop-Key-Pair key pair exists.
• AWS CLI configured with appropriate IAM credentials.

Note

This guide defends against the Hardcoded Secrets in AWS attack scenario. By storing credentials in AWS Secrets Manager and retrieving them at runtime, you avoid embedding secrets in configuration files, source code, environment variables, user data scripts, or public S3 buckets—all of which can be discovered and exploited.

Network Topology

(Click to zoom)

Overview

AWS Secrets Manager helps you protect access to applications, services, and resources by storing secrets (passwords, API keys, database credentials, etc.) in a central, encrypted store.

Applications retrieve secrets via the Secrets Manager API at runtime instead of reading them from config files, environment variables, or user data—eliminating the hardcoded-secrets exposure shown in the Hardcoded Secrets attack.

The main benefit of using AWS Secrets Manager include keeping secrets out of code and configurations.

Additional benefits include encrypting secrets at rest with AWS KMS, controlling access through IAM policies, optionally rotating credentials to limit blast radius, and maintaining full auditability through CloudTrail logging.

Step 1: Create a Secret in Secrets Manager

Create a secret to hold the kind of application credentials that were hardcoded in the attack (database credentials, API keys).

Open AWS Secrets Manager ➔ Secrets ➔ Store a new secret

Secret type: Choose Other type of secret

Key/value pairs: Add the keys and values your application needs (e.g. DB_HOST, DB_USER, DB_PASSWORD, API_KEY). Use placeholder or real values; never paste production secrets into docs or screenshots.

Encryption key: Use the default aws/secretsmanager KMS key (or select a custom key if required).

(Click to zoom)

Secret name: e.g. projectx-app/production

Store secret

(Click to zoom)

Step 2: Grant the Application Access via IAM

Applications (e.g. on EC2, Lambda, ECS) must have IAM permissions to read the secret. Use an IAM role attached to the workload. This allows you to never hardcode AWS credentials.

For an EC2 instance (instance profile):

Open IAM ➔ Roles ➔ Create role

Trusted entity type: AWS service ➔ EC2 ➔ Next

Permissions: Add AWSSecretsManagerClientReadOnlyAccess AWS-managed policy

Role name: projectx-app-secrets-reader ➔ Create role

(Click to zoom)

Attach this role to your EC2 instance: EC2 ➔ Instances ➔ Select instance ➔ Actions ➔ Security ➔ Modify IAM role

(Click to zoom)

Choose projectx-app-secrets-reader ➔ Update IAM role

(Click to zoom)

Your application now uses the instance profile to call Secrets Manager—no access keys in config or .env.

You can now use the aws cli to retrieve the secret, such as:

aws secretsmanager get-secret-value --secret-id <YourSecretNameOrARN> --region <Region>

(Click to zoom)

Step 3: Configure Secret Rotation

Rotation limits the impact of a leaked credential by automatically updating the secret on a schedule.

Open AWS Secrets Manager ➔ Secrets ➔ Select your secret (e.g. projectx-app/production)

Rotation configuration ➔ Edit rotation

Enable automatic rotation: On

Rotation schedule: e.g. 30 days (or custom)

Rotation function: For custom key/value secrets, use a custom Lambda rotation function that updates the secret and (if applicable) the downstream resource (e.g. database password). For RDS credentials, you can use the built-in rotation.

Next through the wizard, then Store to save rotation settings.

(Click to zoom)

If you use a custom Lambda, ensure the secret’s resource policy and the Lambda’s execution role have the permissions required by Rotate secrets.

Verify Setup

• In Secrets Manager ➔ Secrets, confirm the secret exists and (if enabled) rotation is configured.
• In IAM ➔ Roles, confirm the EC2 instance profile (or role used by your app) has a policy that allows secretsmanager:GetSecretValue only for the intended secret.
• Run your application and confirm it starts successfully by fetching the secret from Secrets Manager. Do not ship credentials in config or environment variables.

Cleanup

Warning

Remove secrets and IAM resources when finished to avoid unnecessary retention and charges.

1. AWS Secrets Manager ➔ Secrets ➔ Select the secret ➔ Actions ➔ Delete secret. Choose the required retention period, then confirm.
2. IAM ➔ Roles ➔ Delete the role created in Step 2 (e.g. projectx-app-secrets-reader) if it is no longer used.
3. IAM ➔ Policies ➔ Delete the custom policy (e.g. ProjectXAppSecretsRead) if unused.
4. If you attached the role to an EC2 instance for this exercise, EC2 ➔ Instances ➔ Actions ➔ Security ➔ Modify IAM role ➔ Set to No IAM role (or a different role) as appropriate.