I am interested in why we might use one over the other, i.e. the pros and cons of these approaches.
From what I understood both provide fault-handling and Endpoint Resolution. My assumption is to use ReverseProxy for external clients (outside the cluster) and ServicePartitionClient within a cluster.
The reverse proxy works on the service side, as a gateway that routes Http requests to other services running inside the cluster. Reverse proxy users can be inside or outside the cluster.
Pro: Can be accessed by anyone who understands Http.
Con: Restricted to Http. Requires intimate knowledge about service name and partitioning strategy at the caller side.
The partition client runs client side, to call services. Depending on the underlying communication technology implemented by TCommunicationClient, partition clients can be used inside or outside the cluster. (it's not restricted to Service Remoting)
You could write code that uses the partition client to call the reverse proxy with retry support.
Pro: Can be accessed by anyone who has the TCommunicationClient.
Con: Requires intimate knowledge about service name and partitioning strategy at the caller side.
Related
Background
I have a system running on Azure iot edge. The system is composed of multiple modules that expose REST interfaces. To make everything look tidy from the client's perspective (a browser on another machine in the same network) we use an Azure Function and its reverse proxy capabilities.
So, basically, the client makes a request to an endpoint of the function, if the route matches one in the "proxies" config, it is routed to the correct module using the docker network provided by the iot edge product.
Problem
Now, what I would like to accomplish is that the client would use an https connection to make the request to the function.
So the browser would make a request to https://:8000/Somemodule/Resource and this request would be routed by the af proxy to http://Somemodule:80/Resource .
So my question is, how do I enable https in a function running locally in a docker container, and can the reverse proxy work as described above?
Thanks for any help!
For HTTPS, you primarily need a SSL certificate and reverse proxy like nginx that can do SSL Termination since I believe Azure Functions doesn't support it as part of the runtime itself (which is what the docker container has).
Nginx is a popular and fairly common choice to use for SSL Termination. You would have to configure it for SSL with your domain information and setup your Azure Function as its upstream.
That being said, you could actually just use nginx as your proxy directly too, completely removing the need for Azure Functions, unless you are using it for Functions and Proxies. Your current proxy entries would just become an upstream definition for each module and separate locations (basically path) that would route the requests.
We use Google App Engine and the provided load balancer to do SSL offloading for our API requests which are served by NodeJs. A third part is using Fortify to determine that even though it is https to the outside, because it is http inside the containers, it is considered a vulnerability.
Everything we read suggests setting the environment up this way.
Is this really a vulnerability and if so, how would we best mitigate against this without having to add paid certificates into our Node app.
Thanks in advance
Is this really a vulnerability and if so, how would we best mitigate
against this without having to add paid certificates into our Node
app.
Yes, the proxy of HTTPS to HTTP is a vulnerability as data is decrypted in transit. However, the connection between the frontend and your application is very hard to exploit outside the Google data center. I am not aware of a method to exploit this item.
In the cloud and on-premises data centers, proxying of HTTPS to HTTP is very popular. This offloads the CPU intensive process of encryption and decryption.
In security, there are almost always exceptions that need to be documented. This is one of them.
For the second part of your question, the proxy is HTTPS -> HTTP. This means that you cannot add your own SSL certificate to your backend code. If you did, you would have connection protocol errors.
If you must mitigate this problem, then you must select a different service and deploy your code with frontends/backends (web servers/proxies/load balancers) you configure and control.
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.
Hi We have a UI component deployed to Bluemix on Noedjs which makes REST service calls (JSON/XML) to services deployed in Data-center. These calls will go through the IBM Data Power gateway as a security proxy.
Data Power establishes an HTTPS Mutual Authentication connection (using certs that are exchanged offline) to the caller.
Although this method is secure it is time consuming to set up and if this connection is in setup for each service request it will create a slow response for the end user.
To optimize response time we are looking for any solution which can pool connections between nodejs app deployed on Bluemix and DataPower security proxy. Any one has any experience in this area?
In regards to "it is time-consuming to set up", in datapower you can create a multi-protocol gateway (MPGW) in front of your services to act as router. The MPGW will match services calls based on their URI and route them accordingly. In this scenario, you will only need to configure a single endpoint in the Bluemix Cloud Integration service in order to work with all your services. One downside to this approach is that it will be harder to control access to specific on-premise services because they will all be exposed to your Bluemix app as a single service.
In regards to optimizing response times, where are you seeing the bottleneck?
If the establishment of the tcp connections is causing too much overhead, you should be able to configure your Node.js app to use or re-use persistent connections via keepalive settings or you can look into setting up a connection pool that manages that for you (e.g. https://www.npmjs.com/package/generic-pool seems a popular choice).
On the datapower side, make sure the front/back persistent timeout is set according to your requirements:http://www-01.ibm.com/support/knowledgecenter/SS9H2Y_7.2.0/com.ibm.dp.doc/mpgw_availableproperties_serviceview.html?lang=en
Other timeout values in datapower can be found at http://www-01.ibm.com/support/docview.wss?uid=swg21469404
I'm designing a custom client server tcp/ip app. The networking requirements for the app are:
Be able to speak a custom application layer protocol through a secure TCP/IP channel (opened at a designated port)
The client-server connection/channel needs to remain persistent.
If multiple instances of the server side app is running, be able to dispatch the client connection to a specific instance of the server side app (based on a server side unique ID).
One of the design goals is to make the app scale so load balancing is particularly important. I've been researching the load-balancing capabilities of EC2 and Windows Azure. I believe requirement 1 is supported by most offerings today. However I'm not so sure about requirement 2 and 3. In particular:
Do any of these services (EC2, Azure) allow the app to influence the load-balancing policy, by specifying additional application-layer requirements? Azure, for example, uses round-robin job allocation for cloud services, but requirement 3 above clearly needs to be factored in as part of the load balancing decision, i.e. forward based on unique ID, but uses round-robin allocation if the unique ID is not found at any of the server side instances.
Do the load-balancer work with persistent connection, per requirement 2? My understanding from Azure is that you can specify a public and private port-pair as an end-point, so the load-balancer monitors the public port and forward the connection request to the private port of some running instance, so basically you can do whatever you want with that connection thereafter. Is this the correct understanding?
Any help would be appreciated.
Windows Azure has input endpoints on a hosted service, which are public-facing ports. If you have one or more instances of a VM (Web or Worker role), the traffic will be distributed amongst the instances; you cannot choose which instance to route to (e.g. you must support a stateless app model).
If you wanted to enforce a sticky-session model, you'd need to run your own front-end load-balancer (in a Web / Worker role). For instance: You could use IIS + ARR (application request routing), or maybe nginx or other servers supporting this.
What I said above also applies to Windows Azure IaaS (Virtual Machines). In this case, you create load-balanced endpoints. But you also have the option of non-load-balanced endpoints: Maybe 3 servers, each with a unique port number. This bypasses any type of load balancing, but gives direct access to each Virtual Machine. You could also just run a single Virtual Machine running a server (again, nginx, IIS+ARR, etc.) which then routes traffic to one of several app-server Virtual Machines (accessed via direct communication between load-balancer Virtual Machine and app server Virtual Machine).
Note: The public-to-private-port mapping does not let you do any load-balancing. This is more of a convenience to you: Sometimes you'll run software that absolutely has to listen on a specific port, regardless of the port you want your clients to visit.