Home / server / Questions / 979619
In Process
scetoaux
Asked: 2019-08-17 23:31:17 +0800 CST

Securely storing AWS access credentials in an on-premise server

  • 772

What is the best way to store AWS IAM access credentials in a physical/virtual server so services running in it can access it?

This is a problem which was fixed long ago for EC2 instances through instance profiles but I don't know what the best practices are for non-EC2 servers (i.e. a leased box in a datacenter, a RaspberryPi sitting at home, etc).

Note: I'm not talking about a development environment in a personal desktop or laptop here. There are multiple solutions for that scenario.

I would like to avoid, if at all possible, having long-lived access key ID and secret access key pairs sitting around the hard drive in clear text. Many tools and system that require access to AWS services rely on either including access keys and key ID pairs in config files or using the standard environment variables.

One approach I'm considering is using the AWS System Manager's agent (which is already installed in the box) to periodically pull the keys from AWS secret manager or parameter store. The agent itself uses a custom IAM role when running commands and invoking Automation workflows on the host, so I should be able to add extra IAM policies as needed to access parameter store or other AWS services.

Wondering if there are any good practices to achieve this. I do not want to re-invent the wheel if this is a solved problem or come up with an overcooked and complex custom solution.

amazon-web-services

2 Answers

  1. One way or another you'll have to have some credentials on the server that will be used to retrieve the AWS keys. At least try to restrict it by IP. Here is one way to do it:

    • Create a dedicated IAM User for each server and an IAM Role.
    • The IAM Role has all the privileges your tasks need while the IAM User has ho privileges other than sts:AssumeRole for that IAM Role.
    • Here is the trick: in the IAM User's sts:AssumeRole policy use Condition: { IPAddress: ... } to restrict its use only to your server's IP. See here for more details.

    You may ask why I suggest IAM User and a separate IAM Role - it's because the IPAddress condition must be specified for each Permission in the policy. If you apply it to sts:AssumeRole you've got a single place where you control it. If you'd attach all your permissions/policies directly to the IAM User you'll have to specify the same condition over and over again for each permission.

    Hope that helps :)

    • 4

  2. Best approach: Use SSM agent to automatically give it a "role". This works in the same way as an instance profile.

    Free bonus: You can validate the servers security stance and do patch management if you care. https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html

    • 0