There are two versions of the AWS API Gateway:
REST version
HTTP version (v2)
I am using the newer HTTP version with a lambda authorizer and would like to protect my staging/test environments from outside requests. One idea is to put a WAF in front of the API gateway, but unfortunately only the REST version of the gateway supports a WAF.
Any suggestions for how to protect these resources so they can only be accessed from a specific IP range? (Company VPN)
When using API Gateway, the HTTP API type misses some of the Security options that we have available when comparing it with a REST API, as we can see in the following table:
Security
HTTP API
REST API
Mutual TLS authentication
✓
✓
Certificates for backend authentication
✓
AWS WAF
✓
Resource policies
✓
A full comparison can be found here.
To protect your HTTP API from certain threats, like malicious users or spikes in traffic the API Gateway provides by default the options of setting throttling targets or/and enabling mutual TLS.
To understand more about these default options, take a look on this page Protecting your HTTP API.
If you want to use WAF, you can create a private integration with ALBs, that supports WAF, which means you can get the benefits of WAF while still enjoying the lower cost and higher performance of HTTP APIs.
Your architecture can be similar with the following one:
To understand more about these integrations, take a look on this page: Best Practices for Designing Amazon API Gateway Private APIs and Private Integration.
You can create private Api Gateways using the tags aws:SourceVpc and aws:SourceVpce in the Api resource policy.
link to aws official documentation
Related
We need to provide static IPs to our API GW using HTTP API GW - and not REST API GW. 🎯
It's a tricky process, but here is a good resource about it from AWS official docs.
The problem is there are only a few articles about it, and it seems that is not possible by using HTTP API GW, and only by using REST API GW. 😞
Suggestions?
From the AWS Support team reply:
As you have correctly indicated, this can be configured for an API Gateway REST API by making use of AWS Global Accelerator [1]. However, this would unfortunately not be possible for an API Gateway HTTP API. The closest recommendation that I can make to achieve your use-case would be to possibly use an EC2 instance or a proxy service where you can configure a static IP and then forward the requests to your HTTP API.
As #Marcin has commented.
We are in the process of setting up api gateway with Lamba function behind it. The setup uses aws cognito authorizer. We have the VPC endpoint for api gateway so that is reachable through private IP.
But cognito does not support private links so we can't have the VPC endpoint for it. So this means the token issued by Cognito has to travel from https://ourdomain.auth.ap-southeast-2.amazoncognito.com to client over the internet.
Cognito documentation says following for data in transit:-
" Encryption in transit
All requests to Amazon Cognito must be made over the Transport Layer Security protocol (TLS). Clients must support Transport Layer Security (TLS) 1.0 or later. We recommend TLS 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Most modern systems such as Java 7 and later support these modes."
According to above the token should be encrypted.
But I have following questions:
Is TLS (1.2) enforced for Cognito?
with encryption in transit being available would security best practices still dictate having Cognito available through VPC endpoint so that the token does not need to travel on internet.
if a client application is coming from on-prem environment and accessing the api then if we make it go through a proxy in AWS then will the traffic remain in AWS backbone network or still flow through internet?
Is TLS (1.2) enforced for Cognito:
Unfortunately, no. For most API calls you could use API gateway as a layer in between and enforce TLS1.2 there. However, for the AUTHORIZATION and TOKEN endpoints this does not work.
Alternatively, you can enforce it for all endpoints by deploying cognito to the US regions and using the FIPS endpoints of cognito there. See https://docs.aws.amazon.com/general/latest/gr/cognito_identity.html for the available fips endpoints.
with encryption in transit being available would security best practices still dictate having Cognito available through VPC endpoint so that the token does not need to travel on internet:
That all depends on your risk apetite. For most organizations, encryption will be sufficient. However if your risk apetite is lower, you'll want extra mitigations, following the "defense in depth" best practice. Private connectivity is just one option if many you could add. Monitoring on suapicious user activity and adaptable MFA are other methods for example.
if a client application is coming from on-prem environment and accessing the api then if we make it go through a proxy in AWS then will the traffic remain in AWS backbone network or still flow through internet?
As the api endpoints are public, they will go over the internet (public ip address, so it's routed to a NAT gateway or internet gateway).
EDIT:
In this press release, AWS states all endpoints have TLS1.2 minimum:
https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/. However, I haven't tested if this also applies to non-control-plane API's like the ones mentioned above.
I have created a sample API Gateway using "HTTP API".
I then add a custom domain and added the relevant CNAME record to the DNS.
I then go on Configure API mappings, to add the HTTP API but I get the following error message:
Mixing of REST APIs and HTTP APIs on the same domain name can only be accomplished through API Gateway's V2 DomainName interface. Currently, WebSocket APIs can only be attached to a domain name with other WebSocket APIs. This must also occur through API Gateway's V2 DomainName interface.
Note that adding normal "REST API" works fine.
What is the problem exactly and how do I fix it?
Note that I have since deleted all custom domains, and added this domain fresh, and it still does not work..
I got a second error message and this may explain the reason:
The error message says: "These API types may only be associated to REGIONAL domain names": this means that an HTTP API can only be associated with a REGIONAL custom domain so EDGE is not (hopefully yet) supported with EDGE custom domains.
You only have the option to use a REST API, in order to associate it with an EDGE custom domain, or to create multiple HTTP API deployments in multiple AWS Regions and use Route53 (or you own DNS provider) to map each regional deployment endpoint based on a low-latency strategy.
I am building application deployed to Appsync in AWS. And appsync doesn't support custom domain so that I have to choose a workaround.
I have read some doc and all of them mention to use cloudfront. I wonder whether I can use API gateways instead of cloudfront. For me, I don't want to use any CDN for my backend (even I know I can disable cache).
And I'd like to support subscription over websocket. Does it work with api gateway?
We can setup proxy from Api Gateway both HTTP and REST. Considering this is just proxy and no customizations, we can go with cheaper option of HTTP API.
Here is the documentation.
Step by Step:
Create a HTTP Api
Add a route for /{proxy+} with ANY method.
Add an integration to ANY method pointing to appsync api suffixing with {proxy} https://kkkkabcd1efgxyzeabcdefg4.appsync-api.us-east-1.amazonaws.com/{proxy}
Route53 to point to Api Gateway.
I need to make a secure HTTP callout from Salesforce (using Apex) to AWS Lambda and I build my first version using AWS API Gateway. I realized I can get a client certificate from API Gateway (.crt) but this looks like it is only for AWS backend and is not meant to be for the HTTP request sent to API Gateway. What are my alternatives to establish a secure connection from outside AWS (Salesforce) to a Lambda function?
So far I've found this, which is a disappointing dead-end for now.
Like the link you posted says, API Gateway does not currently support MTLS. Other options for you to add security to the calls at the moment are:
IAM permissions, and here.
API Gateway custom authorizers.
Cognito User Pools.
If you need a custom domain associated with the API Gateway:
Go to Route53 and add your domain (new Hosted Zone), if you haven't done it already.
On AWS Certificate Manager, import or request a certificat for the custom domain you intend to use in your API Gateway endpoints.
Open the API Gateway dashboard and go to "Custom Domain Names". Click "Create a custom domain name" and, in the option "ACM Certificate (region)", select the certificate you generated/imported in item 2 above.
That's it, now you should be able to trigger your Lambda functions using API Gateway from a secure connection (HTTPS). Please note that, if you do this, API Gateway will refuse connections over insecure HTTP protocol.