alphaspirit - Fotolia

Q
Problem solve Get help with specific problems with your technologies, process and projects.

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.

Dig Deeper on AWS cloud platform

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Even when in configuration files, it's possible to do a hash or encryption of the plain text to at least obfuscate the text. If someone has access to the server, they likely have access to the keys required to en-encrypt, but it would require some know-how. 

We pushed a similar article on removing plain text passwords from your Java code over on the sister-site TSS for anyone interested:

https://www.theserverside.com/feature/How-to-remove-plain-text-passwords-for-a-secure-Java-code-base
Cancel

-ADS BY GOOGLE

SearchServerVirtualization

SearchVMware

SearchVirtualDesktop

SearchAWS

SearchDataCenter

SearchWindowsServer

Close