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/
Related
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
We are having several microservices on AWS ECS. We have single ALB which has different target group for different microservices. We want to expose some endpoints externally while some endpoints just for internal communication.
The problem is that if we put our load balancer in public VPC than it means that we are exposing all register endpoints externally. If we move load balancer to private VPC, we have to use some sort of proxy in public VPC, which required additional infra/cost and custom implementation of all security concerns like D-DOS etc.
What possible approaches we can have or does AWS provide some sort of out of the box solution for this ?
I would strongly recommend running 2 albs for this. Sure, it will cost you more (not double because the traffic costs won't be doubled), but it's much more straight forward to have an internal load balancer and an external load balancer. Work hours cost money too! Running 2 albs will be the least admin and probably the cheapest overall.
Checkout WAF. It stands for web application firewall and is available as AWS service. Follow these steps as guidance:
Create a WAF ACL.
Add "String and regex matching" condition for your private endpoints.
Add "IP addresses" condition for your IP list/range that are allowed to access private endpoints.
Create a rule in your ACL to Allow access if both conditions above are met.
Assign ALB to your WAF ACL.
UPDATE:
In this case you have to use external facing ALB in a public subnet as mentioned by Dan Farrell in comment below.
I would suggest doing it like this:
one internal ALB
one target group per microservice, as limited by ECS.
one Network load balancer(NLB), with one ip based target group.
The Ip based target group will have the internal ALB ip addresses,as the private ip addresses for ALB are not static, you will need to setup cloudwatch cron rule with this lambda function(forked from aws documentation and modified to work on public endpoints as well):
https://github.com/talal-shobaita/populate-nlb-tg-withalb/
Both ALB and NLB are scalable and protected from DDOS by AWS, AWS WAF is another great tool that can be attached directly to your ALB listener for extended protection.
Alternatively, you can wait for AWS to support multiple target group registration per service, it is already in their roadmap:
https://github.com/aws/containers-roadmap/issues/104
This how we eventually solved.
Two LB one in private and one in public subnet.
Some APIs meant to be public, so directly exposed through public LB.
For some private APIs endpoints need to be exposed, added a proxy in public LB and routed those particular paths from public LB to private LB through this proxy.
These days API Gateway is the best way to do this. You can have your API serve a number of different endpoints while serving only the public ones via API Gateway and proxying back to the API.
I don't see it mentioned yet so I'll note that we use a CloudMap for internal routing and an ALB for "external" (in our case simply intra/inter-VPC) communication. I didn't read in depth, but I think this article describes it.
AWS Cloud Map is a managed solution that lets you map logical names to the components/resources for an application. It allows applications to discover the resources using one of the AWS SDKs, RESTful API calls, or DNS queries. AWS Cloud Map serves registered resources, which can be Amazon DynamoDB tables, Amazon Simple Queue Service (SQS) queues, any higher-level application services that are built using EC2 instances or ECS tasks, or using a serverless stack.
...
Amazon ECS is tightly integrated with AWS Cloud Map to enable service discovery for compute workloads running in ECS. When you enable service discovery for ECS services, it automatically keeps track of all task instances in AWS Cloud Map.
You want to look at AWS Security Groups.
A security group acts as a virtual firewall for your instance to control inbound and outbound traffic.
For each security group, you add rules that control the inbound traffic to instances, and a separate set of rules that control the outbound traffic.
Even more specific to your use-case though might be their doc on ELB Security Groups. These are, as you may expect, security groups that are applied at the ELB level rather than the Instance level.
Using security groups, you can specify who has access to which endpoints.
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?
I have a Python server (basic REST API) running on an AWS EC2 instance. The server supplies the data for a mobile application. I want my mobile app to connect to the python server securely over HTTPS. What is the easiest way that I can do this?
Thus far, I've tried setting up an HTTP/HTTPS load balancer with an Amazon certificate, but it seems that the connection between the ELB and the EC2 instance would still not be totally secure (HTTP in a VPC).
When you are securing access to an REST API in an EC2 instance, there are several considerations you need to look upon.
Authentication & Authorization.
Monitoring of API calls.
Load balancing & life cycle management.
Throttling.
Firewall rules.
Secure access to the API.
Usage information by consumers & etc.
Several considerations are mandatory to secure a REST API such as
Having SSL for communication (Note: Here SSL termination at AWS Load Balancer Level is accepted, since there onwards, the traffic goes within the VPC and also can be hardened using Security Groups.)
If you plan on getting most of the capabilities around REST APIs stated above, I would recommend to proxy your service in EC2 to AWS API Gateway which will provide most of the capabilities out of the box.
In addition you can configure AWS WAF for additional security at Load Balancer(Supports AWS Application Load Balancer).
You can leverage some of the AWS Services to Handle these.
Question answered in the comments.
It's fine to leave traffic between ELB and EC2 unencrypted as long as they are in the same VPC and the security group for the EC2 instance(s) is properly configured.
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.