How to make an API only accessible through AWS API Gateway? - api

I've built an API with Spring Boot and deployed it into an AWS EC2 instance. I want to make this Spring Boot API to be accessible only through AWS API Gateway. I mean no one could bypass AWS API Gateway and call the that API directly. I want to do this in order to be able to apply some policies like throttling and others.
Is possible to make that API to receive calls through AWS API Gateway only?

Your current best option to achieve this is to use the Client-Side SSL feature of API Gateway: http://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html
Note that if you front your EC2 instances with an ELB you will need to set them to TCP mode and terminate SSL on your EC2 instances.

Related

Azure APIM with App gateway integration question

I'm using Azure API Management.
Since APIM does not provide built in WAF, i'd like to use app gateway in front of APIM.
According to the following article, it is possible.
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-integrate-internal-vnet-appgateway
But some of my APIM are Not integrated with VNet or integrated VNet as external.
And i'd like to integrate those APIM with app gateway as well.
So is this possible scenario or Do i need to migrate existing APIMs to internal VNet?
Thanks a lot.
Advices or documentations.
As per the Microsoft documentation Backend Pools of Application Gateway can contain public ip address, so for your external APIM you can specify the public IP of the APIM, in you Application Gateway backend Pool.
But this doesn't make any sense, because now you are planning to use the application gateway and it supports a way to expose your APIs even if it is in internal vnet mode. As a security point of view it is better to move external APIM to internal mode.
If you want keep the external apim , then you have to find a way to restrict access to this external APIM only via application gateway, and all other direct access to APS should be blocked.

Using one user database to authenticate users in 2 different cloud based (aws/gcp) and only once

So this is the case:
What we have:
We have a Service (webApp) in kubernetes API + Vue.js frontend hosted in AWS.
And we also have some Services (webApp) in Kubernetes API + React.js frontend hosted in GCP.
We are able to use same domain subdomains for each (like: a.domain.com and b.domain.com).
What we need:
We need to let the user think this 2 servers are only one.
The idea is that the user uses the same Username/password for both servers, but
the most immportant part is that he only needs to log in to one of this to be logged in the other automaticaly.
We have the parent domain in Google, and we prefer a solution that is implemented in GCP and the AWS server should just consume this auth method/config/etc.
Love to hear some ideas
If you have multiple replicas of the webApp frontend distributed in multi-cloud environments, you can use dynamic DNS and load balancing services like Cloudflare provides to distribute the access to your app frontend as explained here.
Then you need connect the multi-cloud VPCs and make accessible your backend to your multiple frontends.
You can use managed VPN services from both cloud providers to have an encrypted channel between VPCs in both cloud environments and to transfer data by using private IP addresses.
Google offers Cloud VPN as a managed VPN service for encrypted IPsec tunnels, which can be used on the Google end. AWS offers AWS Site-to-Site VPN and Azure offers Azure VPN gateway. You can connect your VPCs between the environments by using one or multiple VPN tunnels.
With that you can operate your webApp on multi cloud.

Consul vs API Gateway

I would like to ask about the functionalities of Consul and API Gateway. Is Consul can replace API Gateway as a service referrer ?
Or how to use both of them in term of microservices architecture ?
Thank You
Consul is multi datacenter service discovery (+health checking) and distributed K/V store.
API Gateway is a service that handles all the tasks involved in accepting and processing API calls, including traffic management, authorization and access control, monitoring, and API version management.
so they're quite different..
depends on what you're trying to achieve and your current API Gateway use case, you may be able to use Consul + Consul aware load balancers, such as https://github.com/fabiolb/fabio and https://traefik.io/.
At a high-level, an API gateway would become the single point of entry to your micro services. It would allow you to give a consistent user experience to your clients - irrespective of the backend services.
They act as an abstraction - when you hit a /product/{productId} endpoint, you shouldn't need to know about the internal microservices e.g. /reviews, /recommendations etc - the gateway can do this for you and return a single response.
API gateways will be configured to receive a request on a listen path e.g.
curl http://gateway.com/myservice/mypath -H 'Authorization: secret_auth_token'
Internally, the gateway will receive the request and will see that myservice points to a specific api definition.
And based on that auth-token, will be able to establish whether the user is allowed access, what rate limit / quotas and also what upstream targets & paths they are allowed access. A few typical features:
Authentication & Authorisation
Rate Limits
Body Transforms (Filters / Map Reduce / Json -> XML, XML -> Json)
Header Injection
Json Schema Validation
Method Transforms
Mock Responses
API Versioning Strategy
Send requests to multiple targets
the list goes on.
So the gateway will then proxy the request to myservice.com/mypath for example and return the response to the client.
Now let's assume you want your upstream to be highly available - e.g. you may have myservice1.com and myservice2.com.
The gateway can be configured to load balance requests between these services. And you could use features of the gateway for testing the health of the upstreams, but there are also dedicated tools for this. One such tool is Consul.
API gateways should be able to integrate with service discovery tools. So let's assume myservice1.com goes down for maintenance, the gateway will know never to send traffic there and to only send to service2.com till service1 comes back up.
Screenshot below is example of tyk.io api gateway integration support for Consul.

Security considerations for API Gateway clustering?

Clients that communicate against a single point of entry via an API Gateway over HTTPS against a RESTful API
API Gateway: API Keys for tracking and analytics, oAuth for API platform authentication
User Micro service provides user authentication and authorization, generates JWT that is signed and encrypted (JWS,JWE)
Other micro services determine permissions based on claims inside JWT
Micro services communicate internally via PUB/SUB using JWT in the message and other info. Each micro service could be scaled out with multiple instances (cluster with a load balancer).
Question: Can I cluster the the API Gateway and have the load balancer in front of it. What do I need to consider with respect to managing authentication? ie: sharing of API Keys across the API Gateway cluster?
Extra notes, I'm planning on terminating SSL at the gateway and the use of bcrypt for passwords in the db.
Any feedback would be great, thank you.
Can I cluster the the API Gateway and have the load balancer in front
of it.
Yes, you can. Most of the good Api Gateway solutions will provide the ability to do clustering. e.g. https://getkong.org/docs/0.9.x/clustering/ or you can use cloud based Api Gateway: Azure API Management or AWS API Gateway
What do I need to consider with respect to managing authentication?
These specifics depends on your selection of API Gateway solution.

Monitoring access to AWS API Gateway resources using api-keys

I have built a gateway (using aws api gateway) in front of my rest api. I want to monitor the usage of resources on that api using the api-keys generated by api gateway. By 'usage' I mean which resources were requested and served to clients associated with an api key. Amazon claims that cloudtrail can be used to track gateway requests but the x-api-key header does not show up in cloudtrail logs. Has amazon provided an idiomatic way of doing this? Has anyone implemented this functionality in a custom manner? It seems reasonable that this functionality should be built in, however I cannot find how to do this anywhere.