Spike Overview
User Story: EUREKA-89 Spike - Design solution for scheduled system calls
Objective: Select an approach to the problem of routing mod-scheduler calls to system interfaces 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.
Problem Statement
We discovered that some _timer interfaces point to system interfaces, which, for good reason should not be routed through Kong or at least made publicly available in Kong. This means that calls from mod-scheduler to these endpoints will fail. We must find a solution which works for requests to both public and system interfaces.
Scope
In Scope
Egress request routing from mod-scheduler
Requests to both public and system interfaces
Changes/enhancements to Eureka core components (i.e module sidecars, and/or mod-scheduler, and/or Kong)
Out of Scope
…
Research Questions
How should mod-scheduler calls be routed to system interfaces?
What is the relative effort and complexity for each of the solutions?
Deliverables
There are several options but all of them originates from two ideas:
Route system interfaces in Kong, but in such a way that only mod-scheduler is the only valid source of these requests.
Have mod-scheduler send egress requests to its sidecar like every other module, and extend sidecar with ability to retrieve necessary routing information to handle these requests.
Option 1.1
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.
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 Route not found“, as it’s done in case of unknown route.
The following diagram displays
Folio modules and their sidecars deployed inside a cluster with predefined private network. Among other modules the deployment contains mod-scheduler, to run scheduled jobs, and an arbitrary business module, named “Module A” on the diagram. 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.
Tenant Entitlement manager enables an application with Module A
Pros
Mod-scheduler and the mod-sidecar remain unchanged
Cons
Possible security / entitlement issues
Option 2
Have mod-scheduler send egress requests to it’s sidecar like every other module, and add a switch to the module-sidecar which indicates it should retrieve ALL bootstrap info at startup, and consume all discovery events.
Pros
No special handling required in Kong
No security concerns
Cons
the sidecar needs to retrieve and manage discovery and interface/endpoint information for all APIs in the system.
Risks & Assumptions
Risk 1
Risk 2 ...
Assumption 1
Assumption 2 ...
Conclusion
Summarize the results of the spike, key findings, and any recommendations or next steps
Spike Status: COMPLETED IN PROGRESS ON HOLD
Attachments
Include any relevant attachments, such as documents, diagrams, or presentations that support the spike