I plan to use Kong in our project. I'm currently working on a POC to see how we can integrate it in our platform as the main API gateway. I also want to use the JWT plugin for authentication and authorisation. I know that all the API calls should go through the Kong gateway to be authenticated. Then, if the authentication is validated they can go to the API.
Clients ---> Kong gateway ----> Apis
The part that is not very clear in my mind is how the APIs and Kong fit together.
Imagine a scenario where a client try to call directly an API with a token (bypassing the Gateway). How can the API use Kong to validate this token ?
How does Kong authenticates the APIs (not the Client) ? In the examples I have seen so far, only the authentication of the clients is documented, not the authentication of the APIs that are "protected" by Kong.
When using kong as an API Gateway (or for that matter any gateway) we tend to put it at the point where external clients talk to your service. It is a means to discover the individual services. And kong can do good enough job to validate such request.
For the calls you make to other services from within your set of microservices, you may allow for the free passage by means of directly invoking the service. Challenge in that case will be how the services will discover each other. (One way is to rely on DNS entries. We used to do that but later moved to kubernetes and started using their service discovery), and restrict all the incoming traffic to a given service from outside world. So they can only get in via gateway (and thats where we have all the security)
The reason behind the above philosophy is that we trust the services we have created (This may or may not be true for you and if its not then you need to route all your traffic via an api gateway and consider your APIs as just another client and they need to get hold of access token to proceed further or may be have another service discovery for internal traffic)
Or you may write a custom plugin in kong that filters out all the traffic that originates from within your subnet and validates everything else.
Related
Lets say I have 2 Microservices (customer and payment), both consume APIs of external system (e.g. Stripe).
API Authentication
Assume that before consuming any business API of Stripe, API Consumer (in my case Customer & Payment Service) has to first authentication itself using API Keys (AppId and secret).
Stripe provides access token which must be passed into HTTP header into subsequent API calls to Stripe.
below can be possible approaches,
Approach1
https://drive.google.com/file/d/1BGn-hiNwZT4u3BIBmEv-HkJC0w0dk5CB/view?usp=sharing
Approach2: https://drive.google.com/file/d/1JA1hFq7l7-4Ow3b32XNyb2co4tqxKZQ6/view?usp=sharing
Approach1
Multiple auth token though Stripe account is single (per service instance)
Each service to manage auth token expiration/renewal
Approach2
Single auth-token exists with all services.
dependency on auth service.
auth token expiration/renewal managed by single service (Auth Service)
would like know which should be best fit in Microservice architecture? Any other suggestion?
Approach 2 is slightly more scalable and maintainable if more services will require API access to external APIs.
However the correct implementation would be an egress gateway for all your external API calls.
If your going to spend the time to build an Auth service, you might as well go all the way and centralize your external API routing as well.
Benefits:
Single internal endpoint for external APIs, reduces duplication.
Handles all authn and authz with external APIs for your services.
Centralizes all logging, auditing, disaster recover, load balancing etc....
Most gateway products like kong can be used for egress as well.
I don't have much experience with api gateways. I've looked into (and setup) Kong with some auth mechanisms. For all of these the user details are added to Kong through their admin API.
How do I setup a complex authentication flow with Kong. i.e: A user registers, some custom business code is run to validate the user then an email is sent to them for confirmation.
The only way I see is having a microservice which talks to the admin api. The UI would then simply talk to this microservice (which would in turn add users to the admin api), am I on the right path?
Using Kong Admin API you could create API consumers which then you can add authentication methods to (JWT, auth0 ...).
The way I have always implemented this was through my backend talking to the kong admin. of course, this means all your backend application then have access to the kong admin fully but that can be prevented by either having a proxy service on top of kong admin which only allows consumer creation and auth management (technically this can be your user service) or add kong admin to kong as a service and restrict the use cases (less secure since any mistakes might expose your admin API).
One thing you should definitely avoid is to access kong admin directly from your frontend app.
I'm using KONG API Gateway, and I want to implement JWT authentication as separate microservice (not using KONG plugin), now I can easily register this service with KONG, and so users can register and login. Assume an authenticated user had sent a request with a token attached in the header, how to make KONG forwards the request to the authentication service first, then if it is valid the request is forwarded to the requested service?
Yes you can (But I have not used them) there is as far as I know two options:
https://docs.konghq.com/hub/kong-inc/openid-connect/ Enterprise
https://github.com/aunkenlabs/kong-external-auth Free
I'm experimenting with Kong API gateway. It has nice features such as API key and HMAC authentication via plugin, so I don't have to implement my own security into each of my API.
But it seems to be trade-off. Suppose I have Payment service. In it I need to check for API key, so I create request interceptor for each request to payment service, needs to provide valid API key.
I use kong as reverse proxy to payment server upstream. I also want to move this API key validation into kong, so my payment service (and other service) become plain-not-secured API. It seems nice since I don't have to re-write interceptors for each service. But if somebody know the IP of payment service, then they can directly hit payment service without Kong API gateway.
What should I do to achieve these:
use kong as API gateway (reverse proxy)
use kong plugin for validation (API key / basic / HMAC) so I don't need to re-configure them in my services
avoid security hole if somebody knows the address of API, and hit them directly (bypassing kong security), but keeps #1 and #2, so the API programmers write is simple API but keep secure
Thanks in advance
In my webapp architecture i have an api gateway which proxies requests to my microservices, also there is a a common microservice which other microservices can query via rest api. All of these run on node servers.
i want the microservices to only be approachable from the api gateway, besides the common server which can also be approachable from the other microservices. what is the best network architecture to make this happen and do i need to handle authentication between the servers in some way?
Security needs to be handled at multiple layers and as such its a really broad topic. I will however share some pointers which you can explore further.
First thing first any security comes at a cost. And it's a trade off that you need to do.
If you can ensure that services are available only to the other services and API gateway, then you can delegate application layer security to API gateway and strip the security headers at API gateway itself and continue to have free communication between services. It is like creating restricted zone with ip restrictions (or other means on from where can service be accessed), and api gateway or reverse proxy handling all the external traffic. This will allow you to concentrate on few services as far as security is concerned. Point that you should note here is that you will be losing on authorization part as well but you can retain it if you want to.
If you are using AWS you need to look into security groups and VPN etc to set up a secure layer.
A part of security is also to ensure the service is accessible all the time and is not susceptible to DDOS. API gateways do have a means of safeguarding against such threats.
For the ‘API gateway’ front-end authentication you could use OATH2 and for the back-end part you can use OpenID connect which will allow you to use a key value that is relevant to the user, like for example a uuid and use this to set access control at the Microservice level, behind the API Gateway.
You can find in the next link further information about OpenID connect authentication.