EUREKA-89 Spike - Design solution for scheduled system calls

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 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.

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)

Research Questions

1. How should mod-scheduler calls be routed to system interfaces?

2. 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:

1. Route system interfaces in Kong, but in such a way that only mod-scheduler is the only valid source of these requests.

2. 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, let’s call it Private Resources Barrier (PRB) 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 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.

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.

1. At first Tenant Entitlement manager (MTE) enables an application with Module A for a tenant. During this process MTE gets Module Descriptor of Module A and

Open