Recently I’ve been exploring the features of the AWS API Gateway to see if it’s a viable routing solution for some of our microservices hosted in ECS.
One of these services is a new onboarding API that we wish to make available to a trusted third party. To keep the integration as simple as possible we opted for API key based authentication.
In addition to supporting API Key authentication, API Gateway also allows you to configure plans with usage policies, which met our second requirement, to provide rate limits on this API.
As an additional level of security, we decided to whitelist the IP Addresses that could hit the API. The way you configure this is not quite what I expected since it’s not a setting directly within API Gateway but instead done using IAM policies.
Below is an example API within API Gateway. I want to apply an IP Address restriction to the webhooks resource:
The first step is to configure your resource Authorization settings to use IAM. Select the resource method (in my case, ANY) and then AWS_IAM in the Authorization select list:
Next go to IAM and create a new Policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke"
],
"Condition": {
"IpAddress": {
"aws:SourceIp": "xxx.xx.xx.xx/32"
}
},
"Resource": "arn:aws:execute-api:*:*:*"
}
]
}
Note that this policy allows invocation of all resources within all APIs in API Gateway from the specified IP Address. You’ll want to restrict this to a specific API or resource, using the format:
arn:aws:execute-api:region:account-id:api-id/stage/METHOD_HTTP_VERB/Resource-path
It was my assumption that I would attach this policy to my API Gateway role and hey presto, I’d have my IP restriction in place. However, the policy instead is instead applied to a user who then needs to sign the request using their access keys.
This can be tested using Postman:
With this done you should now be able to test your IP address restrictions. One thing I did notice is that policy changes do not seem to take effect immediately - instead I had to disable and re-enable IAM authorization on the resource after changing my policy.
Final thoughts
AWS API Gateway is a great service but I find it odd that it doesn’t support what I would class as a standard feature of API Gateways. Given that the API I was testing is only going to be used by a single client, creating an IAM user isn’t the end of the world, however, I wouldn’t want to do this for APIs with a large number of clients.
Finally in order to make use of usage plans you need to require an API key. This means to achieve IP restrictions and rate limiting, clients will need to send two authentication tokens which isn’t an ideal integration experience.
When I first started my investigation it was based on achieving the following architecture:
Unfortunately running API Gateway in-front of ELB still requires your load balancers to be publicly accessible which makes the security features void if a client can figure our your ELB address. It seems API Gateway geared more towards Lambda than ELB so it looks like we’ll need to consider other options for now.