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.
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
I have a use case where i am supposed to connect my client to apigateway using websockets. I have seen the API gateway can be configured with WAF rules in case of a REST api but i am not able to see the websockets API gateway under the list of resources that can be added to WAF protected resource in AWS console. Does it mean that websocket connections to API gateway cannot be protected using WAF ?
As of now, WAF cannot be used with a WebSocket API in Amazon API Gateway. However, by configuring authorizer and throttling, you can protect your API.
Reference: https://docs.aws.amazon.com/apigateway/latest/developerguide/websocket-api-protect.html
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 use AWS API Gateway that proxies HTTP queries to my services. How could my services check that HTTP requests are originating from AWS API Gateway?
You can use client-side certificates to authenticate requests between API-Gateway and your server.
http://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html
You can use API Gateway to generate an SSL certificate and use its public key in the backend to verify that HTTP requests to your backend system are from API Gateway. This allows your HTTP backend to control and accept only requests originating from Amazon API Gateway, even if the backend is publicly accessible.
The SSL certificates that are generated by API Gateway are self-signed and only the public key of a certificate is visible in the API Gateway console or through the APIs.
Since Nov 30, 2017 Amazon API Gateway Supports Endpoint Integrations with Private VPCs.
You create an endpoint to your VPC by setting up a VPC link between your VPC and a Network Load Balancer (NLB), which is provided by Elastic Load Balancing. The NLB send requests to multiple destinations in your VPC such as Amazon EC2 instances, Auto Scaling groups, or Amazon ECS services.
How to Set up API Gateway Private Integrations
I have a situation when my product(some Web API) is living inside of VPC, i.e. with no any any external access. I'd like to expose the part of this APIs(just a couple of HTTP methods) to be accessible from the internet. I'm trying to achieve this using AWS API Gateway but it looks like I cannot make internal ELB endpoint the API Gateway resource. Any ideas how can I do this?
Thanks,
--Vovan
This was originally not possible, and then was solved with support for client certificates that API Gateway could use to authenticate itself to your services. This was a good solution, and is still available, but still required your services to be exposed -- at least in some sense -- to the Internet.
In November, 2017, AWS released a new capability that allows you to actually provision a network path between API Gateway and your internal services.
You can now provide access to HTTP(S) resources within your Amazon Virtual Private Cloud (VPC) without exposing them directly to the public Internet. You can use API Gateway to create an API endpoint that is integrated with your VPC. You create an endpoint to your VPC by setting up a VPC link between your VPC and a Network Load Balancer (NLB), which is provided by Elastic Load Balancing.
https://aws.amazon.com/about-aws/whats-new/2017/11/amazon-api-gateway-supports-endpoint-integrations-with-private-vpcs/
Historical context follows.
As of now, there is no simple and foolproof way to do this, because your services that are accessible to API Gateway need to be accessible via/exposed to the public Internet and there is no built in trust mechanism by which you can be assured that such a request actually originated from any API Gateway deployment, much less your API Gateway deployment.
Amazon seems to have solved the issue of authenticating requests to your back-end services as having assuredly come, not only from API Gateway, but from your API Gateway instance. As before, endpoints still need to be exposed to the Internet, since the source IP address is not predictable -- but API gateway now supports client SSL certificates, which the back-side of API Gateway uses to authenticate itself to the front-side of your back-end service, that API gateway is calling.
Q: Can Amazon API Gateway work within an Amazon VPC?
No. Amazon API Gateway endpoints are always public to the Internet. Proxy requests to backend operations also need to be publicly accessible on the Internet. However, you can generate a client-side SSL certificate in Amazon API Gateway to verify that requests to your backend systems were sent by API Gateway using the public key of the certificate.
Q: Can I verify that it is API Gateway calling my backend?
Yes. Amazon API Gateway can generate a client-side SSL certificate and make the public key of that certificate available to you. Calls to your backend can be made with the generated certificate, and you can verify calls originating from Amazon API Gateway using the public key of the certificate.
— https://aws.amazon.com/api-gateway/faqs/#security
When you generate a client certificate in the API Gateway console, you're provided with the public key for that certificate. For security, the private key is retained by API Gateway and is not accessible to you. API Gateway will present the public key to your back-end when negotiating SSL. Any peer not presenting that same public key is not API gateway, and your back-end should deny SSL negotiation.
If a malicious actor should ever come into possession of the public key, they would not still be able to communicate with your back-end over SSL, because they would lack the mated private key, which is only known to API Gateway. (Your side of the interaction would be encrypted using your SSL certificate and it's mated private key, which is of course, known only to you.)
This capability addresses what previously appeared to be a significant limitation of the utility of API Gateway's HTTP proxy functionality... a limitation of such significance, in fact, that when I discovered the revised information, above, I began to doubt myself: Had this been there all along, and I had somehow managed to overlook it? The Wayback Machine says no, it's new. This information was added in September, 2015.
It's somewhat of a circuitous path, but you can proxy your Web service endpoints that are in a VPC through a Lambda function. That Lambda function can be called directly from the API Gateway. This blog post gives details on how to do that.