Secure Credentials Management

Welcome to the first lesson of the Developer Security & Observability course. In this lesson, we will focus on secure credentials management using AWS Secrets Manager and the AWS SDK for Python (boto3).

Credentials are pieces of sensitive information, such as usernames, passwords, or API keys, that allow applications to access resources like databases or external services. If these credentials are not protected, they can be stolen or misused, leading to security breaches.

AWS provides tools to help you manage credentials safely:

• AWS Secrets Manager lets you store, manage, and retrieve secrets securely.
• boto3 allows your applications to interact with AWS services using authenticated requests.

By the end of this lesson, you will know how to store a secret in AWS Secrets Manager and retrieve it securely in your application using boto3.

Before we dive in, let's understand how AWS credentials work with boto3.

When you use boto3 to interact with AWS services, it needs credentials to authenticate your requests. boto3 looks for credentials in several places, in this order:

1. Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
2. AWS credentials file (~/.aws/credentials)
3. IAM roles (when running on AWS services like EC2, Lambda, ECS)
4. Other configured sources

In this practice environment, credentials are pre-configured for you. However, understanding the credential chain is important for deploying your applications securely in production.

Production Best Practice: In production environments running on AWS infrastructure (like EC2 instances), you should use IAM roles instead of static credentials. IAM roles provide temporary credentials automatically, eliminating the need to store long-term access keys in your code or configuration files. We'll discuss this more at the end of the lesson.

Let's start by learning how to store a secret, such as database credentials, in AWS Secrets Manager using Python and the boto3 library.

First, we need to import the necessary libraries. We will use boto3 to interact with AWS and json to handle our secret data.

import json
import boto3
from botocore.exceptions import ClientError

• boto3 is the AWS SDK for Python. It allows us to interact with AWS services.
• json helps us format our secret data as a JSON string.
• ClientError is used for handling errors when making AWS API calls.

Next, we create a client to interact with AWS Secrets Manager.

sm = boto3.client('secretsmanager')

• This line creates a client object called sm that lets us call Secrets Manager functions.
• boto3 will automatically use the configured AWS credentials to authenticate this client.

Let's define the secret we want to store. For example, database credentials:

SECRET_NAME = "app/db/credentials"
payload = {
    "username": "appuser",
    "password": "S3cureP@ss!",
    "host": "db.example.com"
}

• SECRET_NAME is the name we will use to refer to this secret in AWS.
• payload is a dictionary containing our sensitive information.

Now, let's store the secret in AWS Secrets Manager.

resp = sm.create_secret(
    Name=SECRET_NAME,
    SecretString=json.dumps(payload)
)
print("Created:", resp["ARN"])

• sm.create_secret creates a new secret in AWS.
• Name is the name of the secret.
• SecretString is the secret data, converted to a JSON string.
• The response contains information about the created secret, including its ARN (Amazon Resource Name).

Note on Secret Types: AWS Secrets Manager supports two types of secrets:

• SecretString - Used for text-based secrets like JSON credentials (what we're using here)
• SecretBinary - Used for binary data like encryption keys or certificates

Most application secrets use SecretString, which is what we'll focus on in this lesson.

About ARNs: An ARN is AWS's unique identifier for resources. Think of it like a complete address that specifies exactly which secret you created, including the AWS account, region, and service. We print the ARN here for two reasons:

1. Confirmation - It verifies your secret was created successfully
2. Future reference - You can use the ARN to:
   • Grant specific permissions to this secret in IAM policies
   • Reference the exact secret in CloudFormation templates or other infrastructure code
   • Audit which secrets exist in your AWS account

While you can retrieve secrets using just the friendly name (like "app/db/credentials"), the ARN provides an unambiguous reference that includes all the context about where the secret lives.

Example Output:

Created: arn:aws:secretsmanager:us-east-1:123456789012:secret:app/db/credentials-abc123

Now, your secret is safely stored in AWS Secrets Manager.

Once your secret is stored, you need a way for your application to retrieve it securely. boto3 makes this straightforward.

Here's how the secure retrieval flow works:

┌─────────────────────────────┐
│   Your Application          │
│   (Python + boto3)          │
│                             │
│  ┌───────────────────────┐  │
│  │ AWS Credentials       │  │
│  │ (configured via       │  │
│  │  boto3 credential     │  │
│  │  chain)               │  │
│  └───────────┬───────────┘  │
└──────────────┼──────────────┘
               │
               │ Authenticated Request
               │ (using credentials)
               ▼
    ┌─────────────────────┐
    │  AWS Secrets        │
    │  Manager            │
    │                     │
    │  • Stores secrets   │
    │  • Returns values   │
    └─────────────────────┘

Key Points:

1. Your application uses boto3 to make authenticated requests
2. boto3 automatically uses available AWS credentials (from the credential chain)
3. Secrets Manager validates the credentials and returns the secret if authorized
4. No secrets need to be stored in your application code

Let's write a function that fetches the secret from AWS Secrets Manager with basic error handling.

def get_secret(name):
    try:
        val = sm.get_secret_value(SecretId=name)
        return json.loads(val["SecretString"])
    except ClientError as e:
        # Handle common errors
        error_code = e.response['Error']['Code']
        if error_code == 'ResourceNotFoundException':
            print(f"Error: Secret '{name}' not found")
        elif error_code == 'AccessDeniedException':
            print(f"Error: Access denied to secret '{name}'")
        else:
            print(f"Error retrieving secret: {error_code}")
        raise

• get_secret takes the name of the secret.
• sm.get_secret_value fetches the secret from AWS using the authenticated client.
• The secret is returned as a JSON string, so we use json.loads to convert it back to a Python dictionary.
• We catch ClientError to handle common issues like missing secrets or permission problems.
• Different error codes tell us what went wrong (secret doesn't exist, access denied, etc.).

Now, let's use this function to get our database credentials and print the host.

if __name__ == "__main__":
    secret = get_secret("app/db/credentials")
    print("Secret host:", secret["host"])

• This code retrieves the secret and prints the value of the host field.

Example Output:

Secret host: db.example.com

⚠️ NEVER log or print the actual secret values (passwords, API keys, tokens) in your application logs. Notice in our example we only print secret["host"], which is the database hostname - not sensitive information like the password.

Do NOT do this:

# ❌ BAD - Logs sensitive data
print("Retrieved secret:", secret)
print("Password:", secret["password"])
logger.info(f"DB credentials: {secret}")

Do this instead:

# ✅ GOOD - Only logs non-sensitive metadata
print("Secret retrieved successfully")
print("Connecting to host:", secret["host"])
logger.info("Database credentials loaded from Secrets Manager")

Why is this important?

• Application logs are often stored in monitoring systems, log files, or sent to third parties
• Logging secrets defeats the purpose of using Secrets Manager
• Leaked logs can expose credentials to unauthorized users

When debugging, you can verify secret retrieval succeeded without exposing the actual values.

In this practice environment, credentials are pre-configured for learning purposes. However, in production, you should never hardcode credentials or rely on long-term access keys stored in configuration files.

Best Practice: IAM Roles for EC2

When deploying applications on AWS infrastructure like EC2 instances, you should:

1. Create an IAM role with permissions to access Secrets Manager
2. Attach the IAM role to your EC2 instance (called an instance profile)
3. Use the same boto3 code - no changes needed!

Here's how it works:

┌─────────────────────────────┐
│      EC2 Instance           │
│  ┌───────────────────────┐  │
│  │   Your Application    │  │
│  │   (Python + boto3)    │  │
│  └───────────┬───────────┘  │
│              │              │
│  ┌───────────▼───────────┐  │
│  │      IAM Role         │  │
│  │  (Instance Profile)   │  │
│  │  Provides temporary   │  │
│  │  credentials via IMDS │  │
│  └───────────┬───────────┘  │
└──────────────┼──────────────┘
               │
               │ Authenticated Request
               │ (temporary credentials)
               ▼
    ┌─────────────────────┐
    │  AWS Secrets        │
    │  Manager            │
    └─────────────────────┘

Key Advantages:

• No static credentials in your code or configuration
• Automatic credential rotation - AWS provides temporary credentials that expire
• Same code - boto3 automatically discovers and uses the IAM role credentials
• Better security - credentials can't be leaked from configuration files

The boto3 code you've written in this lesson works identically whether using configured credentials (like in this practice environment) or IAM roles (like in production on EC2). The credential discovery is automatic!

In this lesson, you learned:

• Why it's important to keep credentials secure.
• How to use AWS Secrets Manager to store sensitive information.
• How to retrieve secrets using boto3 with authenticated AWS requests.
• Basic error handling when accessing secrets.
• The critical importance of not logging secret values in your application.
• The production best practice of using IAM roles on EC2 instead of static credentials.

You saw step by step how to create and store a secret, and how to access it securely from your application. In the next set of practice exercises, you will get hands-on experience with these concepts by writing and running code to manage secrets yourself. This will help you build secure applications on AWS from the start.