alphaspirit - Fotolia
How do I store secrets in AWS so they don't appear in my code?
To secure a cloud environment, IT teams must keep their application's secrets under wraps. Learn how AWS users can keep sensitive information out of their code with tools like Secrets Manager.
Developers commonly separate secrets from source code and configuration information when they design secure applications. This is particularly true of secrets related to configurations -- usernames, passwords, API keys or other credentials -- the application needs to access restricted or sensitive resources.
AWS developers and admins should follow these principles to store and manage secrets:
- Never define secrets in the source code. Secrets stored in source code can make sensitive information visible to the public or be uploaded to widely available repositories. Fail to follow this rule and you risk security breaches.
- Restrict the presence of secrets in local configuration files as much as possible.
- Make sure applications have access to the right secrets based on the hosting environment, including development, staging or production environments.
Applications should only define a reference to specific secrets in the code. Then, the application can load the actual secrets during deployment or runtime, instead of accessing them directly.
To do this, identify functional areas in the application that need to access restricted resources. Identify how the application accesses any database or APIs that require authentication. For example, are they hard coded, taken from local configuration files or environment variables?
For AWS users, there are two primary ways to ensure credentials never appear in source code.
The role of AWS credentials and IAM roles in secrets management
If an application needs to call AWS APIs and requires access to AWS credentials, there's no need to configure these credentials in the application servers or code components.
For applications that run on EC2 instances, assign an EC2 instance profile. An EC2 instance profile is associated with an AWS Identity and Access Management (IAM) role. That role defines and grants permissions so an authorized server can call the AWS APIs.
For applications deployed in Elastic Container Service (ECS), ECS tasks can be linked to an IAM role to grant the relevant permissions. This way, containers don't need to have any AWS credentials configured using internal files or application code.
Lambda functions use an execution IAM role by default, which is the standard way to grant AWS permissions to a function.
How to store and manage secrets with AWS Secrets Manager
To protect secrets in AWS, configure them in AWS Secrets Manager, then insert a descriptive reference to them in the application code. For example, the password for a production database can be stored in Secrets Manager and named my_db_password_production. Then the application retrieves the actual password using the name configured in AWS Secrets Manager. The actual password is a secret stored and encrypted by AWS, retrieved as needed by the application in a secure way.
Through this approach, the application is only aware of a reference to a secret and not the secret itself. No one who reads the application source code will discover the password to access the production database. This setup in AWS also simplifies secret rotation, which should be performed regularly as part of system maintenance tasks.
Applications can retrieve the right secret for a specific environment by using it in the actual secret name. For example, my_db_password_development for the development sandbox, or my_db_password_production for live systems.
ECS can integrate with Secrets Manager natively. When configuring an ECS task definition, specify a secrets section, which refers to a secret using the valueFrom and name parameters. With this approach, containers deployed in ECS can refer to a secret value as an environment variable, while AWS stores the secret separately.
Access to Secrets Manager is controlled by AWS IAM. IAM's capabilities boost secrets management, because it enables application owners to restrict which users and entities can access a specific secret.
If you're running a high-volume application, it's important to factor in the added expense of secrets management through AWS. Secrets Manager costs $5 per one million API calls. It can quickly become a considerable expense, depending on the application.
