I'm setting up an environment with an API Gateway (KONG) and microservices (Spring-boot apps), but I have a lot of doubts/concerns with the SSL communication between them.
Should I put the SSL settings in the API Gateway or on the microservices?
Currently my microservice app has its own SSL certificate and it runs in a container through 8443 port.
But now implementing the API Gateway, I'm not sure if I have to remove it from my microservice and setting up in the API Gateway or add it in both.
I expect the correct communication between my microservice and the API Gateway in order to the clients are able to consume the services through 8443/ssl.
Your API gateway will be facing the clients. So for secure communication, your API gateway must be behind the SSL.
Regarding microservice, it's up to you to have it behind SSL or not. Both way it will work. According to me, if your microservices are restricted within the VPC (and API gateway is part of the same VPC) and not exposed publicly, then there is no need to have microservices as well behind SSL.
Related
Currently I am working on spring microservices. It has zuul proxy and eureka server registry.
All the web API calls are being handled by zuul proxy.
Now I want to design a light weight mobile app, where the API call request body dont match. So, Decided to have one more gateway for mobile. What is the best approach to design this?
From mobile gateway, is it worth calling zuul proxy with modified request body which then calls the microservices?
Or the mobile gateway calls the microservices through RestAPIs ?
where mobile gateway and zuul proxy service will be running independently
I need to convert monothic application to micro service architecture. Few suggestion/confirmation are required before i finalize the design.
I will be using docker containers and kubernetes. Structure will be like this
Ingress -> Zuul API Gateway--> Microservice
-> Angular PODS
Ingress Router to route traffic to
Angular PODS where angular code will be present
API Gateway Zuul API Gateway where we will perform Authorization and
Authentication
So my doubt is, for inter service communication do we need to configure SSL ?
It depends on the level of security you need for inter-service communication. If that is required, I would recommend to use service mesh for the same. It will give mutual TLS for your services and many other benefits. Istio (https://istio.io/) is the most widely used service mesh.
I have three spring boot micro services which uses spring Eureka server and zuul as gateway. I have auth micro service which is zuul gateway which validates user. I have two other services which is running in different ports. I am able to protect the two services with the help of jwt, if i call via zuul gateway but since i know two micro services port and url i can able to call and get the response directly without via gateway url . So i how to protect the the two micro services. Please help me to share the security context between two micro services.
I think you are looking for security settings in each other the microservices that are not zuul or eureka.
With help of the WebSecurityConfigurerAdapter you could override the CORS settings and only accept requests from a certain service, that way zuul can talk to the services, and maybe even each service to each other. But postman and other clients couldn't do that.
I'm wondering what to do with an API Endpoint when using a API Gateway. For example when you following the tutorial here: https://wiredcraft.com/blog/securing-components-in-a-microservice-context
You are using keycloak and kong (api-gateway) to secure the api. With kong you're getting an new Endpoint under http://localhost:8000/data. But the "original" express Server is still listening on http://localhost:3001/data.
That means that when a user/attacker knows the url of the "orignal" service and doesn't use the kong url (port 8000) he/she can still work with the api.
So my question is about the strategy and what to do with the original api? How could that be secured. Shall we implement the keycloak request on the api as well? But where are the benefits of kong then?
Your API gateway gives you a single entrypoint that simplifies how client applications access your services. You could add keycloak security on the gateway and not on the services behind - perhaps if you've a setup where you can block network access for clients to any services except the gateway. But even then you might still want the gateway and keycloak on the services behind.
The reason you might put keycloak on the services behind is because they are likely to need to know the identity of the user making the request. If they are going to read the token anyway then it might be most straightforward to add keycloak to them. And you'd still want the gateway to simplify life for clients. You'd then also want the gateway to forward the token to the services behind the gateway. (We're using keycloak and spring cloud gateway on the Activiti Cloud project and this is essentially how we decided to secure the services themselves with keycloak and have the gateway forward the token to them.)
i have created two java spring-boot micro services they are
1) producer
2) consumer
and i have used spring eureka server for service registration and discovery . it worked fine . then what is the use of Netflix Zuul.
Let's suppose you have 20 services to which user can interact to, and of course we are not going to expose each and every services publicly because that will be madness (because all services will have different ports and context), so the best approach will be to use an API gateway which will act as single entry point access to our application (developed in micro service pattern) and that is where Zuul comes into picture. Zuul act as a reverse proxy to all your micro-services running behind it and is capable of following
Authentication
Dynamic Routing
Service Migration
Load Shedding
Security
Static Response handling
Active/Active traffic management
You can go through documentation here
If you have enough experience in the domain, you could look at zuul as an API gateway like Apigee. It is very feature rich and touches up on a lot of different concerns like routing, monitoring and most importantly, security. And eureka as a service discovery platform that allows you to load balance (in Linux terms the nginx or haproxy) and fail over between your service instances.
Typically the backend services that perform the server side business operations (i.e. core) are not exposed publicly due to many reasons. They are shielded by some Gateway layer that also serves as reverse-proxy. Netflix Zuul serves as this gateway layer which easily gives you the capabilities as mentioned by #Apollo and here