Architecture¶
To run the IEM on a customer-managed Kubernetes cluster, on an OpenShift cluster, or even on other flavors of Kubernetes distributions, the system was redesigned to be installable on any K8s cluster. To do this, all OS dependencies were removed and the design was updated from a distributed monolithic architecture to a more modular architecture. In addition, the IAM subsystem is rebuilt to use standard protocols and approaches by introducing an authentication gateway and Keycloak as the IAM server.
By using Helm charts, customers get the flexibility to configure the Kubernetes cluster according to their organizational needs. But consequently, they are responsible for running that cluster (shared responsibility).
K8s Centric Setup¶
| No | Components | Description |
|---|---|---|
| ① | Provisioning CLI | Cli Tool to bootstrap the K8s deployment. |
| ② | Device Catalog | A set of services extending the basic device managment capability of IEM, like Firmware Management, new Device Types with custom properties and more. |
| ③ | Webserver | Web server hosting static files, like Launchpad and OS Bar. |
| ④ | IEMA | Services of the Core Domain: Portal Service: Manages Applications and Devices. ws: Endpoint for Device Communication. Registry (6): Docker Registry hosting images. |
| ⑤ | Auth | Components providing IAM, Gateway and token exchange functionalities. |
| ⑥ | Registry Server | Docker Registry containing IEM and IED Applications´ Container Images. |
| ⑦ | License Manager | Monitors, Reports and enforces the Liceses on the system. |
| ⑧ | PSQL | Shared postgres database. |
| ⑨ | Secret Generator (RegSecGen) | Cron Job which will update k8s registry secret to pull private images. |
| ⑩ | App Manager | Install, Update and Maintain IEM Extensions. |
| ⑫ | Disaster Recovery | Services to store and restore the device state. |
| ⑬ | Tunnel Server | Service to enable remote access to IEDs. |
Industrial Edge Management App (IEMA)¶
The Industrial Edge Management App (IEMA) is the main component that manages the IED application and devices. It is deployed as a K8s stateful set.
Overview¶
| No | Components | Description |
|---|---|---|
| ① | NGINX (UI) | This components is responsible for serving UI and forwarding API requests to Backend. |
| ② | Web Socket Server | Receives web socket calls from IED (e.g. install jobs). |
| ③ | Portal App | Responsible for managing devices and applications, main component of the system |
| ④ | Registry | Container Registry for Edge Applications. |
| ⑤ | Crane | Component to communicate with container registry. |
| ⑥ | OPA(Open Policy Agent) | Policy Engine that validates app installation requests. |
Application Management Service (AMS)¶
Overview¶
Application Management Service is responsible for managing the Industrial Edge Management Applications.
Core Use Cases¶
Industrial Management Extensions are services designed for k8s clusters and integrated with Industrial Edge Management (IEM). These key use cases are fulfilled by AMS:
- Download/import the extension bundle (IEM extension) from IEHub (open).
- Parse and store the bundle in IEM.
- Install/Update/Uninstall the bundle on the k8s cluster.
- Monitor system health and report installation statistics to IEHUB.
- Provide logs and metrics of the installation (k8s namespace and all pods within the namespace) for support use cases.
Component View¶
| No | Components | Description |
|---|---|---|
| ① | Kong Gateway | API and App Gateway as single entrypoint to the system. |
| ② | AMS | Application Management Service parse the bundles and deploy the extensions. |
| ③ | K8s | Kubernetes Cluster provided by the customer. |
| ④ | Launchpad | Webserver hosting static files. |
| ⑤ | Chart Museum | Helm Repository managing helm charts. |
| ⑥ | Registry | Container Registry. |
| ⑦ | Keycloak | IAM System of IEM. |
Disaster Recovery with State Service¶
Key Use Cases¶
The State Service takes states (=backups) of devices and device-related data. Therefore, the State Service provides a possibility to have a disaster recovery strategy for Edge devices. A typical scenario can be the outage of an IPC which is replaced with a new one. Afterwards, the backup of the broken IPC can be restored on the new one.
As of now, the device state includes the following:
- installed catalog apps
- installed project apps
- configurations of installed apps
- the state of installed apps (running vs. stopped)
- connector app configurations (limited to S7, Databus, External Databus & Cloud Connector)
- app volumes (type: host; apps on IED are stopped during backup)
Component View¶
| No | Description |
|---|---|
| ① | As of now, it is intended to use the State Service API via a browser session. Technically, it is possible to trigger the API with a valid session token. |
| ② | Internally, the State Service can access the Fileservice with admin credentials. The Fileservice is used to store the app-volumes files. The State Service takes care that temporary access to the IED is granted and that the storage size boundaries are kept. |
| ③ | The State Service utilizes the Portal API to retrieve the information which is available on IEM level. |
| ④ | The connector applications store device-related information centrally on IEM level. Therefore, the State Service communicates with the Connector applications to import and export this data. |
| ⑤ | The IED communicates with the Portal to keep the Portal in sync with the IED. Furthermore, it polls for jobs which should be executed on the IED. |
| ⑥ | For backing up/restoring app-volumes, the IED directly communicates with the State Service to reserve storage space and to gain temporary Fileservice access. |
| ⑦ | The Fileservice is used to upload and download the app-volume data. |
NOTICE
All communication to the IEM works through the Kong API Gateway.
Communication¶
The following describes the communication between the components and their means of authentication and authorization.
| No | Description |
|---|---|
| ① | Communication between State Service and IEMA/Portal happens via user's session token. |
| ② | State Service is using credentials with full administrative rights, generated during deployment, to communicate with the fileservice. |
| ③ | IED's job engine & IEMA's job engine communication follows the default mechanism within the system, using a JWT token signed with generated private key on the device, verified with the public key located in IEM. |
| ④ | Communication between disaster recovery client and State Service is re-using the default mechanism within the system, using a JWT token signed with a generated private key on the device, verification done by the Portal. |
| ⑤ | Communication between disaster recovery client and Fileservice to upload/download volumes, uses previously generated credentials with specific rights (read-only/read-write) via https, based on required action only valid for current operation (store/restore). |
| ⑥ | Communication between State Service and the Connector application APIs works via user's session token. |
Tunnel Server¶
Some IEM extensions require a communication channel from the IEM to the IED. IEDs are often placed in critical network infrastructures that require special protection, such as production lines. These are often protected by firewalls that block incoming traffic. Since the IEM is typically placed on a corporate network or the Internet, for example, it is necessary for the communication to be initiated by the IED.
Component Overview¶
| No | Component | Description |
|---|---|---|
| 1 | Tunnel Controller | Manages Tunnel Functionality |
| 2 | Tunnel Server | WS Endpoint for Tunneling clients |
| 3 | Tunnel Client | Establishes the connection to Tunnel Server and routes the traffic to appropriate tcp ports |
| 4 | Websocket (wss) connection | Connection is always established from client to server |
| 5 | Port mirroring of Client site | Allows the communication on TCP Level in both directions. |