Page Comparison

...

Route all timer request (for regular and system interfaces) through Kong, but in the case of system interfaces, allow requests coming from the internal sub-net only and block any calls to system interfaces from the outside. This type of barrier can be enforced with custom Kong plugin, let’s call it Private Resource Access Resources Barrier (PRAPRB) plugin.

The plugin should be aware of network boundaries where Eureka cluster with Folio modules is deployed. How exactly this information can provided to the plugin is TBD. With that knowledge requests to system interfaces can be filtered by requestor’s IP address:

• request comes from internal node (including a node with mod-scheduler) → let it pass through;

• request comes from external network (internet) → forbid and return “404 "404 Route not found“found", as it’s it's done in case of unknown route.

The following diagram displays main components and actors involved in the flow

Folio modules and their sidecars are deployed inside a cluster with predefined private network (marked as Intranet on the diagram). Among other modules, the deployment contains mod-scheduler , to run scheduled jobs, and some business module, named “Module A”. Module A provides regular interface /regular-url-A along with _timer interface /timer-url-A. Detailed information about Module A interfaces contained as usual in its Module Descriptor.

...

b. creates routes in Kong for _timer interfaces. Each newly created route marked with a special tag “private“ (or “internal“, or “system“ – up to us to decide on the naming) to identify interface as internally available only

...

2. scheduled job is triggered for /timer-url-A endpoint. Request goes from mod-scheduler to its sidecar, which in turns forwards the request to Kong, since the request URL is not registered inside sidecar’s egress routing table

   1. Kong receives the request and searches for known routes associated with the given URL and method.

   2. Once the route is found, PRA PRB plugin checks if it has “private“ tag assigned.

      • For /timer-url-A the tag

      assigned, in case of scheduler

      • is assigned and the plugin additionally checks if the request comes from the internal network

      • in case of a call from mod-scheduler it’s true and the plugin let the request be forwarded to target Module A sidecar.

   3. Finally the sidecar calls /timer-url-A interface of the module and the chain of calls succeeds.

3. External actor (UI or another system) attempts to request /timer-url-A system interface. Kong performs the same steps to handle the request as it does in case of a call from mod-scheduler:

   1. the route is searched in the list of registered routes

   2. then PRB plugin is called to apply additional validation:

      • since the route has “private“ tag assigned it is also tested to check if the caller belongs to internal network

      • external actor doesn’t belong to internal network so the plugin rejects this call with "404 Route not found" error.

Open questions

1. what are the options for defining boundaries of internal network and providing this information to PRB plugin

2. what are the ways to inject the plugin into Kong request processing flow

   1. is it possible to execute the plugin just right after Kong has found a route

   2. will the route be available to the plugin

Pros

• Mod-scheduler and the mod-sidecar remain unchanged

• the approach can also address Public/Private API problem

Cons

• Possible security / entitlement issues

...