Pro Tip: Allow Access to AWS Programmatic Accounts from Specific IP Addresses

IAM policies are a great way to enforce authorization for Groups / Users / Roles to specific services, under specific conditions. In high level, policies are a set of JSON statements which provide certain permissions to entities. Adding another security layer to that, there is an optional block under the policy statements. Like any condition in any programming languages, The condition block returns a boolean output — either true or false, which decides whether a policy grants or denies the request.

In this example, we will demonstrate how a policy can deny or allow access from specific IP address, and how combining it with programmatic users (service accounts) adds more security to it in case of credentials theft.

For our use case, let’s think about the following scenario: An established enterprise company uses a Jenkins to deploy AWS resources on their Development, Staging and Production workloads. As part of the automated continues integration process, Jenkins uses AWS credentials to programmatically call the AWS API to perform its actions.

Now, let’s think what is going to happen if someone performs MITM attack and getting those credentials, or an irresponsible user saves those credentials to GitHub and a bot finds them? A lot of bad things might happen on these cases.

How are we mitigating these kind of attacks? In most cases, Jenkins will run from an organizational network, where the IP address(es) are known upfront. Simply be creating an IAM policy that rejects access if the request is coming from IP address that is not explicitly mentioned in the policy, we can mitigate any incident of stolen credentials.

Create a new IAM policy and name it AWSAllowAccessFromIP. The policy will look as following (Update the IP address placeholder):

Now, let’s attach this policy to our programmatic user (service account). This policy will automatically ensure that any request not originates from the mentioned IP address will be denied.

In our example, we’re running the AWS Security audit tool prowler. On the first run without applying the policy, these are the results:

Now, after applying the policy, the AWS API won’t let us to access those actions since the request doesn’t originate from the explicitly mentioned IP address: