AWS Credential and Secret Management
A proposed security and operational improvement for an Elastic Beanstalk application running on EC2 and accessing S3, Lambda, and Step Functions.
Recommendation: replace long lived AWS access keys with an IAM role attached to the Elastic Beanstalk EC2 instances. Store sensitive application secrets in AWS Secrets Manager and suitable application configuration in AWS Systems Manager Parameter Store.
Current Architecture
Elastic Beanstalk
|
v
EC2
|
v
Node.js application
|
+-- AWS_ACCESS_KEY_ID
+-- AWS_SECRET_ACCESS_KEY
|
+-- S3
+-- Lambda
+-- Step Functions
Root Cause and Reason for Change
Recommended AWS Service Access
Elastic Beanstalk
|
v
EC2
|
| Instance Profile
v
Production Application IAM Role
|
+--------> S3
+--------> Lambda
+--------> Step Functions
IAM Role and Instance Profile
This is the primary change. The EC2 instances receive an IAM role through an instance profile. The role defines what the application is allowed to do in AWS.
Least privilege
The role should contain only the permissions the application needs. For example, the application might need access to specific S3 objects, permission to invoke specific Lambda functions, and permission to start specific Step Functions state machines.
Broad permissions such as AdministratorAccess should not be assigned to the application role.
Environment Separation
Development, staging, and production should use separate application roles where practical.
| Environment | Example identity | Scope |
|---|---|---|
| Development | DevelopmentApplicationRole | Development resources only |
| Staging | StagingApplicationRole | Staging resources only |
| Production | ProductionApplicationRole | Production resources only |
Resource Based Policies
Resource based policies provide a second layer of control. The IAM role answers which actions the workload can request. A resource policy can additionally restrict which identities a resource will accept.
S3 bucket policies are a practical example. They can restrict access to a specific application role or account boundary.
Application Secret Management
IAM roles solve AWS service authentication. They do not replace the need to manage application secrets.
| Value | Recommended location |
|---|---|
| Database password | AWS Secrets Manager |
| Third party API key | AWS Secrets Manager |
| JWT signing secret | AWS Secrets Manager |
| Application URL | SSM Parameter Store or normal configuration |
| Feature configuration | SSM Parameter Store |
AWS Secrets Manager
Secrets Manager should be the primary store for sensitive application credentials. It provides encrypted storage, IAM controlled access, auditing support, and secret rotation capabilities for supported use cases.
SSM Parameter Store
Parameter Store is suitable for application configuration and encrypted parameters that do not require the secret lifecycle features of Secrets Manager.
Docker Secrets
Docker secrets are not required for the current Elastic Beanstalk architecture. They can be reconsidered if the deployment model changes to a container focused platform.
Encrypted Configuration Files
An encrypted configuration file still requires a decryption key. If that key is stored on the same server, the fundamental secret management problem remains.
Recommended Target Architecture
AWS ACCOUNT
|
+-------------------+-------------------+
| |
Elastic Beanstalk Secrets Manager
| |
v |
EC2 |
| |
| Instance Profile |
v |
Application IAM Role |
| |
+----+-----------+ |
| | | |
v v v |
S3 Lambda Step Functions |
| | | |
+--------+-------+---------------------------+
|
Resource policies
where appropriate
+
SSM Parameter Store
|
Application configuration