AWS provides its users with the opportunity to leverage their vast offering of advanced datacenter resources via a tightly integrated API. While the goal is to provide easy access to these resources, we must do so with security in mind. Peak efficiency via automation is the pinnacle of our industry. At the core of our automation and operation efforts lie the 'keys' to the kingdom. Actually, I really do mean keys; access keys. As an AWS Administrator or Power User, we've probably all used them, and there is probably at least 1 (valid!) forgotten copy somewhere in your home directory. Unauthorized access to AWS resources via compromised access keys usually occurs via:
- Accidental commit to version control systems
- Machine compromise
- Unintentional sharing/capturing during live demonstrations or recordings
Without the proper controls, if your credentials are obtained by an unauthorized party, they can be used by anyone with internet access. So, we'll work to transform how we look at our access keys, by treating them less as secrets that we guard with great care, and more like disposable items. We'll do that by embracing Multi-factor Authentication (MFA, but also referred to as Two Factor Authentication or 2FA).
In this scenario, we're looking to protect IAM users who are members of the Administrators IAM group. We'll do this by:
- Enabling MFA for IAM Users
- Authoring and applying an MFA Enforced IAM Policy
- Leveraging the Security Token Service to create MFA enabled credentials
This can be done by adding a Multi-Factor Authentication Device in each user's Security Credentials section. I prefer Duo Mobile, but any TOTP application will work. Your MFA device will be uniquely identified by it's ARN and will look something like: arn:aws:iam::1234567889902:mfa/hugo
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*",
"Condition": {
"bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Create a Managed or Inline policy using the json above and attach it to the IAM User or Group whose credentials you wish to protect. This IAM policy above allows all actions against any resource if the request's credentials are labeled as having successfully performed MFA.
Now that you're enforcing MFA for API requests via Step 2, your existing access keys are no longer primarily used for making requests. Instead, you'll use these keys in combination with your MFA passcode to create a new set of temporary credentials that are issued via the Security Token Service.
The idea now is to keep your temporary, privledged credentials valid for only as long as you need them. e.g. The life of an administrative task or action. I like to recommend creating credentials that have a valid duration of less than or equal to 1 hour. Shrinking the timeframe for which your credentials are valid, limits the risk of their exposure. Credentials that provide administrative level privileges on Friday, from 10am to 11am, aren’t very useful to an attacker on Friday evening.
To create temporary credentials, you reference the current Time Based One Time Passcode (TOTP) in your MFA application and perform either of the following operations:
3a. Use a credential helper tool such as aws-mfa to fetch and manage your AWS credentials file
aws sts get-session-token --duration-seconds 3600 --serial-number <ARN of your MFA Device> --token-code 783462 and using its output, manually update your AWS credentials file or environment variables.
3c. Write your own application that interfaces with STS using one of AWS's SDKs!
Implementing MFA for console usage is a much simpler process. By performing Step 1, the console automatically prompts for your MFA passcode upon login. Awesome, and easy!
There are scenarios where temporary credentials do not fit the workload of long running tasks. Having to renew credentials every 60 minutes for long-running or recurring automated processes seems highly counterintuitive. In this case, it's best to create what I like to call an IAM Service Account. An IAM Service Account is just a normal IAM User, but it’s functionally used by an application or process, instead of a human being. Because the service account won't use MFA, you’ll want to reduce the risk associated to its credentials in the event of their exposure. You do this by combining a least privilege policy, meaning only give access to what’s absolutely necessary, with additional controls, such as source IP address restrictions.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:TerminateInstances"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"ec2:TerminateInstances"
],
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"10.10.66.0/24"
]
}
}
}
]
}
An example Service Account IAM Policy that only allows EC2 instance termination from an allowed IP address range.
While AWS offers MFA Protection for Cross-Account Delegation, this only applies to requests originating from an AWS account. AWS does not have visibility into the MFA status of external identity providers (IdP). If your organization uses an external Identity Provider to broker access to AWS, either via SAML or a custom federation solution, it is advised that you implement a MFA solution, such as Duo, in your IdP’s authentication workflow.
Stay safe, have fun, and keep building!