Advanced Microgateway Functions in a Service Mesh without Adding Gateways

A recent Gartner report (ID G00373257) defines elegantly a general Service Mesh architecture and how a set of microgateways are needed for East/West or lateral API mediation (Figure 1).

Figure 1. (source Gartner Report)

A few things worth highlighting in this architecture:  

  1. The definition of Service Mesh isn’t limited to containerized microservices. It contains Miniservices, monolithic app Macroservices, and Macroservices based on a legacy app adapter. This definition fits most, if not all, existing enterprise applications environments. 

  2. North-south mediation is separated from east-west mediation. This seemingly obvious separation is important in truly defining what a microgateway function should be. Many API Gateway products simply port their implementation to a microservice architecture (usually using containers) and then self-proclaim to be a “microgateway.” In light of this architecture, it is still performing a North-south mediation function, albeit microservices themselves. 

  3. The microgateway layer is a functional layer. This means that actual network traffic or API calls in the wire do not necessarily have to pass through one additional gateway/proxy, as long as a network component inline of the API call flow performs the Monitoring/Security/Traffic Management functions sufficiently. 

It is the point number 3 that we would like to expand further. In the physical world, if we want to enhance monitoring/security/traffic control of flows into a building, the best approach may not be to add yet another gate. Perhaps adding a set of video surveillance systems with proper alarming in combination with automatic lock-down to existing doors would be a lighter-weight, non-intrusive, more effective way.

In fact, in most service meshes today, there are built-in “gateways” through which inter-service API calls flow. Figure 2 shows a few of these “gateways”:

  • Some enterprises use API Gateways to mediate API calls. They do provide Monitoring/Security/Traffic Management functions to the API calls that they are front-ending, but naturally, they can only manage API calls that go through them – but not all service API calls are leveraging an API gateway. It is hard to find a real service mesh in which the majority of API calls are mediated by an API Gateway these days. Moreover, some of the functions are relatively limited. For example, most traffic management is about rate limiting. 

  • Load Balancers and proxies, including sidecar proxies implemented in a container system, are naturally gateways. They are not purpose-built API gateways and hence lack many of the API mediation functionalities.  

  • A message bus cannot be considered a gateway in the strictest sense. However, API calls do flow through them in a message-oriented implementation. 

  • Enterprise Id Providers can be considered logical gateways as they are the “gatekeeper” of any API transaction. They control the generation, validation, authorization of tokens used to make API calls. 

Figure 2: Gateways in a Service Mesh

Now, the question becomes: what if we can build enough surveillance into the service mesh, then leverage existing gateways to perform the security policy functions in case of anomaly/attacks? After all, what is needed is not yet another gateway, but intelligence knowing what the user and API activities are and what might be anomalous about those activities. 

ArecaBay’s Network Engine is a better and frictionless approach to performing the microgateway functions without adding more network gateways. The Network Engine consists of two parts: 

 

  1. A collection of micro-sensors deployed into the service mesh infrastructure. They can be of the following types: 

    • A plug-in to Load Balancer Proxy 

    • A plug-in to API Gateway 

    • A plug-in to sidecar proxy 

    • A network tap (physical or virtual) 

    • A sidecar sniffer 

    • A consumer of the message bus 

    • An IdP callback function 

  2. A central correlation and policy enforcement function that takes API call data and performs advanced microgateway functions. The network of microsensors capable of filtering and capturing highly targeted API object level data enables advanced functions much beyond what point gateway products can provide. Here are a few examples(more examples are available in a whitepaper):

  • Monitoring

  1. API object level tracking allows us to provide a set of Dynamic API Risk Trackers that are able to detect, for example, out-of-range parameter input or access token/user mismatch.  

  2. Multi-point capturing enables API calls originating from a single front-end action be traced across services. 

  • Traffic Management

  1. As we can track cross-service calls at object level, we can track data movements that are otherwise permitted by the app implementation but are in violation of data locale rules (e.g. GDPR) 

  2. As a monolithic app is broken down into smaller microservices, sometimes a smaller number of front-end calls may result in an excessive number of backend calls. An advanced rate-limit policy can control cross-service call rates.  

  • Security

  1. Out-of-band actions do not require an “inline” device. For example, leveraging IdP callback, if a particular user is suspected of generating abnormal API calls, the user session can be invalidated, and the user be required to perform a “Step-up” authentication.  

  2. In-line actions are performed by leveraging various gateway plug-in microsensors.

In summary, a set of intelligent microsensors can enable advanced microgateway functions without having to add yet another inline gateway layer to the service mesh implementation. Such No-gateway approach is the most seamless and non-disruptive implementation of a service mesh microgateway. If interested, we will be delighted to demo to you.