AWS Secrets Manager: Secure App Credentials
Learn how AWS Secrets Manager protects database passwords, API keys, and credentials while helping developers avoid hardcoding secrets in applications.
Series: My 90-Day AWS & DevOps Learning Journey (30 articles)
- …
- 14AWS Secrets Manager: Secure App Credentials This article
AWS Secrets Manager: Secure App Credentials
Have you ever stored a password directly inside your code?
For a beginner project, it might seem convenient:
1
2
DB_USERNAME = "admin"
DB_PASSWORD = "mypassword123"
But imagine this code being pushed to GitHub.
Now the password is exposed.
This is one of the problems that becomes important when moving from beginner projects to real-world cloud and DevOps environments.
A better approach is to keep sensitive information separate from application code.
One AWS service that helps with this is AWS Secrets Manager.
What Is AWS Secrets Manager?
AWS Secrets Manager helps you securely store and manage sensitive information called secrets.
Examples include:
- Database passwords
- API keys
- Application credentials
- Authentication tokens
- Other sensitive configuration information
Instead of putting these values directly into source code, an application can retrieve them when needed.
A simplified architecture looks like:
1
2
3
4
5
6
7
Application
↓
Secrets Manager
↓
Secret
↓
Database / Service
Why Should We Avoid Hardcoding Secrets?
Consider a simple application:
1
2
3
Python Application
↓
Database
A beginner might write:
1
2
username = "admin"
password = "mypassword123"
The problem becomes much bigger when this code is pushed to a Git repository.
1
2
3
4
5
6
7
8
9
Developer
↓
Git
↓
GitHub
↓
Source Code
↓
Password Exposed
Even if the password is removed later, the secret may have already been exposed through repository history or other copies.
This is why secrets should not normally be hardcoded into application source code.
How Secrets Manager Works
Instead of storing the password inside the application, we can store it in Secrets Manager.
For example:
1
2
3
4
5
6
7
8
9
10
Secrets Manager
Secret Name:
production/database
Username:
admin
Password:
********
The application can then retrieve the secret when it needs to connect to the database.
The basic idea becomes:
1
2
3
4
5
6
7
Application
↓
AWS Secrets Manager
↓
Database Credentials
↓
Database
This separates sensitive information from application code.
Secrets Manager and IAM
Security doesn't stop at storing the secret.
We also need to control who or what can access it.
This is where AWS IAM becomes important.
For example:
1
2
3
4
5
6
7
8
9
EC2 Instance
↓
IAM Role
↓
Permission
↓
Secrets Manager
↓
Secret
Instead of giving developers unrestricted access to every secret, IAM policies can be used to control access.
This follows an important security principle:
Give only the permissions that are required.
A Practical DevOps Example
Imagine you deploy a Python application to EC2.
The application needs database credentials.
A less secure approach might be:
1
2
3
4
5
EC2
↓
Application
↓
Password stored in code
A better approach could be:
1
2
3
4
5
6
7
8
9
10
11
EC2
↓
IAM Role
↓
Secrets Manager
↓
Database Secret
↓
Application
↓
Database
Now the application doesn't need to keep the database password directly inside the source code.
This is one example of how AWS services can work together.
Secrets Manager and GitHub
Suppose you're building a project and using GitHub for version control.
Your repository might contain:
1
2
3
4
app.py
requirements.txt
README.md
Dockerfile
You generally don't want it to contain:
1
2
database_password.txt
production_api_key.txt
Instead, sensitive values can be stored using an appropriate secrets-management solution and accessed securely by the application or deployment environment.
This is an important habit to develop early when learning DevOps.
Automatic Secret Rotation
Another useful capability of Secrets Manager is secret rotation.
For supported scenarios, Secrets Manager can help automate the process of changing credentials periodically.
The basic concept is:
1
2
3
4
5
6
7
Old Secret
↓
Rotation
↓
New Secret
↓
Application Uses Updated Credential
Regularly changing credentials can reduce the risk associated with long-lived secrets.
The exact rotation process depends on the type of secret and the service being integrated.
Secrets Manager in CI/CD
Secrets management is also important in CI/CD pipelines.
Imagine this workflow:
1
2
3
4
5
6
7
8
9
Developer
↓
GitHub
↓
CI/CD Pipeline
↓
Deploy Application
↓
AWS
The pipeline may need credentials or other sensitive configuration values.
Those values should not simply be committed into the repository.
Instead, the CI/CD environment can be configured to retrieve or securely provide the required secrets.
This is an important part of building safer automated deployments.
Secrets Manager vs Hardcoded Passwords
| Approach | Main Issue |
|---|---|
| Password in source code | Can be exposed through repositories |
| Password in configuration file | Can be accidentally shared |
| Secrets Manager | Centralized secret management |
| IAM-controlled access | Helps limit who can retrieve secrets |
The goal isn't just to hide the password.
The goal is to manage access to sensitive information properly throughout its lifecycle.
A Beginner DevOps Lesson
When I started learning cloud and DevOps, it was easy to focus on services such as EC2, S3, and VPC.
But real-world DevOps also involves questions like:
Where should application credentials be stored?
Who should be allowed to access them?
What happens when a credential needs to be changed?
How can we prevent secrets from reaching GitHub?
These questions are just as important as knowing how to launch an EC2 instance.
What I'm Taking Away From This
One lesson I'm learning from AWS is that security should be considered while designing an application, not added only after deployment.
A simple project can start with hardcoded credentials because it is easy.
But developing the habit of separating secrets from application code is much more useful when moving toward real-world cloud and DevOps work.
💬 Let's Discuss
If you're learning AWS or DevOps:
Have you ever accidentally exposed an API key, password, or other secret while working on a project — or learned about it before it happened? What approach do you use now to manage secrets?
I'd be interested to hear how other beginners and DevOps engineers handle this.
#AWS #DevOps #CloudSecurity #SecretsManagement
Series: My 90-Day AWS & DevOps Learning Journey (30 articles)
- …
- 14AWS Secrets Manager: Secure App Credentials This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article