How to securely handle passwords or secret credentials in the applications by using AWS.

Samara simha reddy
3 min readJul 1, 2021

Disadvantages of using AWS SDK for projects developed outside AWS:

1) AWS services can be used in the projects built outside of AWS by using the AWS SDK

2) To handle the secret information (like passwords,API keys etc..) which are used in the projects or applications, AWS provides services like AWS Secret manager service to securely store the secret information in their database by encrypting the values.

3) However in order to fetch the secrets from AWS secret manager, we need to store the access keys either as environment variables or in ./aws/credentials file which resides unencrypted.

4) If we store our access keys in ./aws/credentials file we can provide some security by giving read write access only to the required users.

5) But it’s not completely secured as there are chances of hacking the information as they are stored unencrypted.

Solutions:

Method-1

So to handle the above mentioned disadvantages, we can run our projects in AWS EC2 instances and attach the instance to an IAM role which has the permissions to use our AWS secret manager service.

Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html

Why is the above method better?

The Identity and Access Management (IAM) role attached to the instance will provide temporary credentials (like temporary access keys) to the applications running on the instance which they can use to access other AWS services.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

These temporary credentials consisting of {access key, access key id, token} are not the actual credentials and have an expiry time. The temporary credentials can be fetched only by the instance from the instance metadata service (IMDS) and cannot be fetched from elsewhere. That is the temporary credentials are instance specific and cannot be accessed by other instances.

By default IMDS comes with two versions IMDSv1 and IMDSv2. We can configure the IMDS to use IMDSv2 as it has additional security layers than IMDSv1.

References:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html#configuring-IMDS-existing-instances

https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html

https://medium.com/@shurmajee/aws-enhances-metadata-service-security-with-imdsv2-b5d4b238454b

What happens when our applications in the instance requests for AWS resources?

Whenever the application is requesting for an AWS resource, the instance checks whether it has been granted the permission to use that particular request.

If the instance has the required permission then it fetches the temporary credentials from Instance Metadata service. The application then uses these temporary credentials to get access to the AWS resources.

The temporary credentials are rotated automatically by AWS. So we don’t have to bother about the rotation of the temporary credentials.

Method-2

And the other method which I found might be useful is that we can save our entire project in the repos provided by AWS codebuild or AWS codepipeline and integrate them with AWS secret management service. The AWS codebuild or AWS codepipeline is similar to Jenkins where we can create builds using the secret credentials fetched from AWS secret manager inorder to run our application.

Conclusion:

So in this way we can execute our application without hardcoding the secret credentials in the codebase and not storing the AWS access keys in the system where we run our application.

Thanks and regards:

Samar

--

--