Page Comparison

...

Objective: Select an approach to the problem of routing mod-scheduler calls to system interfaces invoked by predefined schedule (aka timers)

Background

Timers defined in module descriptors sometimes specify endpoints which are not defined as part of regular/standard interfaces. That means information about these is not included in the bootstrap/discovery information sidecars use to route module-to-module calls. Presently, mod-scheduler sidecar sends timer requests directly to Kong in order to simplify things. Also mgr-tenant-entitlement registers timer interfaces as routes in Kong. Without that sidecars would need to either get all discovery information, or obtain new discovery info whenever a new timer is created.

...

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 on Kong’s side:

• 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 Route not found", as it's done in case of unknown route.

...

Folio modules and their sidecars are deployed inside a cluster with predefined private network (marked as Intranet “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, PRB plugin checks if it has “private“ tag assigned.

      • For /timer-url-A the tag 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 Module A 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 , the request 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.

...

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 selected route be available to the plugin

...