Is it possible to do SSL termination at the AWS API Gateway itself rather than terminating at a downstream application load balancer (ALB)? I am considering an architecture that routes requests from API Gateway to a network load balancer (NLB) to Fargate container tasks using a VPC link. I prefer not to terminate SSL at the Fargate task level because I believe that requires application code changes, but without an ALB in the mix to do SSL termination, it seems I need to terminate either at the API Gateway or at the Fargate task level.
I found some sites that reference SSL termination at the API Gateway, but I don't see AWS docs about that and don't see how to do that via the AWS console. Is it possible, and if so, how is it done?
I've used info at these links:
Allow request from API Gateway to private ALB
https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/
If you mean specifically AWS API Gateway, TLS termination will always happen at the gateway, since it only provides a TLS endpoint. It works as an proxy that only handles incoming HTTPS connections. You don't have the option to pass the incoming HTTPS call directly across the proxy. However the backend can use other transports like HTTP or HTTPS.
You don't do anything special to turn on this behavior (TLS termination on the gateway), since it is the only way AWS API gateway operantes.
For AWS, yes it happens on API Gateway but in general it can either happen on API Gateway or Load balancer
Related
I have a cluster of private EC2 instances serving http requests behind a public ALB. https termination happens on the ALB, with authentication on the EC2 instances. I want to move authentication to the ALB, ideally via mTLS. But ALB does not support mTLS. From some initial reading, it sounds like API Gateway can replace load balancing/firewall functions of the ALB in this design, while also supporting mTLS? Is that correct?
If so, I wonder what would be the best way to implement sticky sessions, which seem not supported by API Gateway, but needed by my app. I guess client request could initially target an API served by any instance, but then subsequent requests would target API unique to the instance that replied?
Are there other drawbacks to API Gateway, other than higher cost at high volume? Is there a better approach to this problem?
My initial assumptions were incorrect. API Gateway is not an alternative to ALB except in some specialized circumstances. So, the solution for me is to put an API Gateway in front of a private ALB, e.g., as described in AWS example
https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-alb-integration/
I'm trying to expose an HTTP server to the internet. The server runs on a Fargate container inside a dedicated VPC. I could just expose it through a public Application Load Balancer (ALB) if it wasn't for the fact that requests to this server must be authenticated using IAM.
My approach was to put an AWS Gateway v1 in front of the service's load balancer. This Gateway verifies authentication through IAM, then relays the request to a Network Load Balancer (NLB) using a VPC Link. The NLB in turn routes it to the server itself.
Here's the problem: Api Gateway v1 does not support VPC Links to ALBs, only NLBs, but NLBs use TCP, while I'm exposing an HTTP server. This way I can't relay paths and other HTTP features through the Network Load Balancer.
Api Gateway v2 does support VPC Links to ALBs, but it does not have a way to authenticate using IAM.
Is there any way to work around this problem?
I am not sure why you think api gtw 2 does not allow IAM authentication or where you got that from?
Can you put your cloudformation here or point to a git so I can test it with a policy?
Can you put the link where it says that API GTW 2 does not suport IAM Authorization?
The documentation clearly mentions that you can use IAM Authorisers?
https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/doc-history.html
Here is a blog that might help?
https://aws.amazon.com/premiumsupport/knowledge-center/iam-authentication-api-gateway/
You could go the long way and use Cognito Pool, link that to you API GTW, if what you say is true.
https://aws.amazon.com/blogs/security/building-fine-grained-authorization-using-amazon-cognito-api-gateway-and-iam/
hope this helps, I'd be curious of your Cloud Formation if you are willing to share.
We have a microservice architecture and trying to deploy on AWS while leveraging its API Gateway.
Our API Gateway is using a public TSL certificate for client requests, but we wonder how we should be encrypting the communication from the API Gateway to the Load Balancer and then to the services. The API Gateway can also issue "Client Certificates" but it's not clear how we should utilize that.
We are hoping not to have a private CA on AWS as it is quite costly and we don't have any burning use for it.
I think the traffic between API Gateway and internal AWS services is always going through HTTPS. This is based on the comments from BobK#AWS:
HTTPS is used for traffic between CloudFront and API Gateway.
Communication from API Gateway to other services, such as Lambda, is
also over HTTPS.
The only time API Gateway would not use SSL is if you configured an
HTTP integration and chose not to enable HTTPS on that integration.
I want AWS gateway API to be entry point of application cluster. I have 20+ machines running in my VPC which are required for various purposes (RMQ, Worker, etc). I was expecting gateway api to offload the SSL, authenticate request with AWS signature and then forward it to my ELB. And then, some way to secure my internet facing ELB to accept requests just from API gateway. Turns out it's not possible. I have to run SSL on my deployed NGINX server and use AWS client certificate authentication to validate the origin of request. This still keeps my end points exposed to DDos and there is overhead of SSL as well.
Now, with newly launched network load balancer and VPC link at gateway api level is is possible to achieve above?
Suppose I have a RESTful API that sits on a Windows EC2 cluster, behind an ELB. The existing API is a .NET application and hosted in IIS.
I want to try and put AWS API Gateway in front of the existing API, so that security, scalability, etc. is handled by AWS. Essentially set up AWS Gateway as a HTTP proxy to the existing API.
From the AWS documentation it states that the existing API must be made public. But it should be secured by verifying the calls are originating from Amazon API Gateway by checking the client side certificate.
http://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html
However the SSL connections for the existing API are terminated at the ELB. Hence when we check the client certificate, on the request, in code - it doesn't exist.
What would need to be done to get the client certificate at the EC2/IIS/code level?
Or is there an alternative way to secure the existing API and ensure AWS API Gateway can still communicate with it?
You will need to configure your set up your ELB to do TCP based load balancing and terminate SSL connection on your IIS/EC2 hosts. This will require distributing the SSL certificate to the hosts and configuring them to bind the certificate to the appropriate port.
Usually people prefer to offload SSL at their API gateway to save administrative overhead since ELB termination effectively moves the management to a single point in the infrastructure, rather than requiring management of the SSL certs on multiple servers.
It also helps if you are having a EC2 cluster managed by some orchestrator [ECS, kubernetes, Docker Swarm]. As you already mentioned that API gateway to load balancer is secured by SSL certificates, you can add access policy at load balancer to provide required permission to interact with your EC2 cluster, while your EC2 exist in private VPC, you may don't need to add certificates to your EC2 machines as all communication is already secured.
Hope it make sense.