I created a microservice project with a gateway & stuff, and I've some interrogation on one of the gateway spring property.
I've this one on my gateway's application-dev.yml (also prod):
jhipster:
gateway:
authorized-microservices-endpoints:
app1: /api,/v2/api-docs
I'm suspecting that the 'app1' shall be replaced by one or all my microservices (and maybe the UAA one too), but I don't know what it does.
Any description or insight on it?
Regards,
The jhipster.gateway.authorized-microservices-endpoints config variable controls access to your microservices when requested through the gateway. In the case of the example, only /api (API endpoints) and /v2/api-docs (Swagger docs) are accessible through the gateway for the app1 microservice.
This means if you try to request an API mapping that is not present in the list (such as an actuator endpoint http://gateway:8080/app1/management/info) it will fail. You can still make the request directly to the microservice if you needed to.
By default, all paths are open to any microservice. To secure your apps, you will need to add your microservices to the list and set the accessible endpoints.
In summary, this config lets you reduce the attack surface of your microservices. Here's a link to the related JHipster issue where this was added. You can also find details in JHipster's Gateway documentation.
Related
I use jhipster to generate UAA and gateway, but when I access their API interfaces through the gateway, it's like this: “http://xxx.xxx.xxx.xxx:8080/services/uaa/api/account ”, I want to remove the word "services", what should I do?
Please have a look at how to write a custom RouteLocator in Spring Cloud Gateway doc and you may have also to modify GatewayResource and of course frontend code.
Also, you must understand that gateway routing should be determined on something in the incoming request or it will not work for resources which have same path in all services like swagger-ui JSON spec.
#here, please help me understanding microservice authentication with API Gateway.
Let's take an example - I have 10 different independent deployed microservices and I have implemented the API Gateway for all of them meaning all the request will be passed through that gateway, also instead of adding authorization/JWt in every microservice I added in API Gateway with this approach all is working fine, but my doubt and question is
1 What if an end user has the URL of deployed microservice and he tries to connect it without gateway (as I don't have the authorization place here, how do I stop this, do I need to add same authorization logic in every microservice as well but that would end in duplicating the code, then what is the use of API gateway.
let me know if any other input required, hoping I explained my problem correctly.
Thanks
CP Variyani
Generally speaking: your microservice(s) will either be internal or public. In other words, they either are or are not reachable by the outside world. If they are internal, you can opt to leave them unprotected, since the protection is basically coming from your firewall. If they are public, then they should require authentication, regardless of whether they are used directly or not.
However, it's often best to just require authentication always, even if they are internal-only. It's easy enough to employ client auth and scopes to ensure that only your application(s) can access the service(s). Then, if there is some sort of misconfiguration where the service(s) are leaked to the external network (i.e. Internet at large) or a hole is opened in the firewall, you're still protected.
API gateway is used to handle cross cutting concerns like "Authorziation", TLS etc and also Single point of entry to your services.
Coming to your question, If your API services are exposed for public access then you have to secure them. Normally API gateway is the only point exposed to public , rest of the services are behind firewall (virtual network) that can only be accessed by API gateway , unless you have some reason to expose your services publicly.
e.g. if you are using Kubernetes for your services deployment, your can set your services to be accessible only inside the cluster (services have private IPs) , and the only way to access them is API gateway. You don't need to do anything special then.
However if your services are exposed publicly (have public IPs) for any reason then you have to secure them. So in short it depends how you have deployed them and if they have public IP associated with them.
Based on your comments below. You should do the authentication in your API gateway and pass the token in your request to your services. Your services will only authenticate the token not redo the whole authentication. This way if you want to update/change the authentication provider or flow , it's easier to do if you keep it in API gateway.
We are splitting rest api monolith into microservices and we encountered following issue
Let us assume the following
project is asp.net mvc, hosted on iis
project is hosted on dedicated server (not a cloud)
monolith rest api had urls defined such as www.domain.com/orders/ www.domain.com/tickets/ etc
When splitting monolith to microservice, ideal situation would be that we end up with
ms1 -> www.domain.com/orders/
ms2 -> www.domain.com/tickets/
Since microservices do not usually correlate with resources this could get messy, for example one microservice could serve more then one resource, or on resource could be served by more then one microservice.
fe.
www.domain.com/tickets/ (ms1)
www.domain.com/tickets/reports (ms2)
or
www.domain.com/tickets (ms1)
www.domain.com/orders (ms1)
What would be solution for this?
Use IIS rewrite to match resource with microservice
fe. GET www.domain.com/tickets/5 via iis rewrite to call -> ticketsms.domain.com/tickets/5
Use API gateway to route request to proper microservice endpoint
fe.
GET www.domain.com/tickets/5 via API gateway to call -> ticketsms.domain.com/tickets/5
So basically the primary goal is to have full rest api apear like
GET www.domain.com/tickets/5
GET www.domain.com/orders/5
POST www.domain.com/orders/
GET www.domain.com/invoices/100
etc
So are iis rewrite and api gateway are the only two options here?
Should microservices be exposed directly to the clients, or should they go trought API gateway. Is API gateway overkill in this scenario?
The API gateway definitely adds value - what you split is your implementation into smaller units (the microservices) - it allows you to manage, monitor and govern the API interfaces centrally as a single unit, separately from the implementation(s).
Exposing individual microservice endpoints might not be easy to manage - for instance, you would need to apply access control policies separately to each.
I have setup my Jhipster Uaa server, gateways and others micro services and i want to use #AuthorizedFeignClient annotation for inter-service-communication as well explained here : https://jhipster.github.io/using-uaa/
But i cannot find it into the java source generated(Jhispter Release 3.11.0).
Did i have to copy manually in my project this only 2 classes found in jhispter github generator for the moment ? (because still in beta ?) :
.../client/_AuthorizedFeignClient.java
and
.../client/_OAuth2InterceptedFeignConfiguration.java
Thanks,
Francois
currently the #AuthorizedFeignClient annotation is only available for microservice applications using UAA as authentication type, but not for gateways and UAA server itself!
I guess you were looking for the annoation in the gateway, or the the UAA server.
Why is this like this? For the gateway it is because the gateway already has a couple of responsibilities, so building composite logic in there is not a good idea.
If you generate a microservice (not gateway, not uaa server), you should have the client package in your Java root with this annoatation, as well as some more configurations (feign client config, load balanced resource details...)
You can copy those to your gateway, to make it working there.
You can copy them to the UAA, too. More on that, this even will work, but with some weird fact...when UAA will ask service "foo" for some data, it will first ask the UAA for a client credentials authentication....like performing a query to itself...while it could just access grant it itself. There is no accurate way to do it, but I didn't want to keep it in this uncool way in JHipster, so the annotation is for microservice only.
I was working on a side project and i deiced to redesign my Skelton project to be as Microservices, so far i didn't find any opensource project that follow this pattern. After a lot of reading and searching i conclude to this design but i still have some questions and thought.
Here are my questions and thoughts:
How to make the API gateway smart enough to load balnce the request if i have 2 node from the same microservice?
if one of the microservice is down how the discovery should know?
is there any similar implementation? is my design is right?
should i use Eureka or similar things?
Your design seems OK. We are also building our microservice project using API Gateway approach. All the services including the Gateway service(GW) are containerized(we use docker) Java applications(spring boot or dropwizard). Similar architecture could be built using nodejs as well. Some topics to mention related with your question:
Authentication/Authorization: The GW service is the single entry point for the clients. All the authentication/authorization operations are handled in the GW using JSON web tokens(JWT) which has nodejs libray as well. We keep authorization information like user's roles in the JWT token. Once the token is generated in the GW and returned to client, at each request the client sends the token in HTTP header then we check the token whether the client has the required role to call the specific service or the token has expired. In this approach, you don't need to keep track user's session in the server side. Actually there is no session. The required information is in the JWT token.
Service Discovery/ Load balance: We use docker, docker swarm which is a docker engine clustering tool bundled in docker engine (after docker v.12.1). Our services are docker containers. Containerized approach using docker makes it easy to deploy, maintain and scale the services. At the beginning of the project, we used Haproxy, Registrator and Consul together to implement service discovery and load balancing, similar to your drawing. Then we realized, we don't need them for service discovery and load balancing as long as we create a docker network and deploy our services using docker swarm. With this approach you can easily create isolated environments for your services like dev,beta,prod in one or multiple machines by creating different networks for each environment. Once you create the network and deploy services, service discovery and load balancing is not your concern. In same docker network, each container has the DNS records of other containers and can communicate with them. With docker swarm, you can easily scale services, with one command. At each request to a service, docker distributes(load balances) the request to a instance of the service.
Your design is OK.
If your API gateway needs to implement (and thats probably the case) CAS/ some kind of Auth (via one of the services - i. e. some kind of User Service) and also should track all requests and modify the headers to bear the requester metadata (for internal ACL/scoping usage) - Your API Gateway should be done in Node, but should be under Haproxy which will care about load-balancing/HTTPS
Discovery is in correct position - if you seek one that fits your design look nowhere but Consul.
You can use consul-template or use own micro-discovery-framework for the services and API-Gateway, so they share end-point data on boot.
ACL/Authorization should be implemented per service, and first request from API Gateway should be subject to all authorization middleware.
It's smart to track the requests with API Gateway providing request ID to each request so it lifecycle could be tracked within the "inner" system.
I would add Redis for messaging/workers/queues/fast in-memory stuff like cache/cache invalidation (you can't handle all MS architecture without one) - or take RabbitMQ if you have much more distributed transaction and alot of messaging
Spin all this on containers (Docker) so it will be easier to maintain and assemble.
As for BI why you would need a service for that? You could have external ELK Elastisearch, Logstash, Kibana) and have dashboards, log aggregation, and huge big data warehouse at once.