Local systems in production are often connected to the cloud. For example, if the local application is to benefit from continuous access to advanced artificial intelligence algorithms and data analysis packages in the cloud. As these systems are critical to the manufacturing process, they need to be protected against hacking and malfunctions of another program running on the same hardware. How can this be achieved?

The current security context

Virtualization technology, which allows multiple operating systems to run on shared hardware, is well known and well understood, even if it is somewhat inefficient in its use of resources. Just a few decades ago, everyone was using virtual machines (VM) to host and manage infrastructure. More recently, industries have shifted to the use of containers with systems such as Docker and Kubernetes.

The original system of virtualization architecture was based on the implementation of a series of VMs. Each virtual machine has to run its own instance of an operating system, which leads to a duplication of responsibility. It is also difficult to manage such an infrastructure as there are multiple servers, all of which are independent virtual machines.

Containers try to achieve the same concept as virtual machines, but avoid duplication of effort between machines. Instead of loading a complete operating system for an application, Docker containers can use the kernel of the host operating system and simultaneously load application-specific libraries and programs. By customizing the container and its image, it is possible to fine-tune the specific libraries and configuration that each application will use. This leads to increased performance without the overhead of a complete operating system.

A modern application consists of many containers. Running them in production is the task of Kubernetes. As containers are easy to replicate, applications can be scaled automatically: Processing capacities are expanded or reduced according to user requirements.

One of the challenges with containers is security, as the containers must be made effectively usable with a zero-trust approach. Consequently, their use in mission-critical environments requires a "least privilege" approach, where applications are given the minimum amount of system resources required to perform their task, as well as strong isolation between applications so that operations or facility managers can be confident that the solution meets OT requirements for security, availability and performance.

Introducing Google Anthos

The Lynx Mosa.ic platform now supports the deployment of Google Anthos Bare Metal. This creates a solution that allows any containerized service to be brought to the mission-critical "edge" without compromising security or performance. For example, software services from the cloud such as the Google Cloud Visual Inspection AI Service can now be implemented to realize a validated solution for safe, video-based quality inspection in industrial and energy facilities.

The use of Anthos Bare Metal means that an entire Kubernetes cluster can now run locally on just one hardware system at the edge - with enterprise-grade Kubernetes and workload management, fully managed service mesh with built-in visibility, and a consistent development and operational experience for on-premise and on-cloud deployments. Lynx enabled a virtual air-gap that provides isolation between the different parts of the system.

Historically, merging the worlds of operational technology (OT) and IT - training AI and machine learning models in the cloud and deploying cloud-based workloads at the edge - has been a challenge for security in mission-critical industrial environments. For example, Lynx ensures that the three functions - image capture (camera), insight via the inference engine (Anthos) and action with a higher-level controller - are fully sandboxed, with the ability to establish secure one-way (data diode) connections between them.

For example, in a visual inspection (VI) application, model generation could be an on-cloud service. Pre-classified data would be generated on site and forwarded to the VI model creation service in the cloud. Alternatively, a hybrid cloud service could be used, where the VI model generated in the cloud is anchored in a local Anthos environment to perform image inference at the edge. There is also the option of a pure on-premise solution, where both the VI model generation and image inference services are available on-premise.

The Anthos deployment model

The solution uses Anthos as a managed application platform that enables organizations to run Kubernetes and associated workloads across multiple public clouds, hybrid clouds and on-premise compute clusters. What does the deployment of this platform look like at the mission-critical edge? The primary building blocks of a typical mission-critical edge deployment include:

• The platform software - this is deployed on the target systems (or nodes) and allows multiple workloads to be hosted on the target systems;
• The controller software - it is (usually) deployed on-premises to manage different nodes;
• The application framework - it provides a unified control plane for end-user workloads (either as standalone applications or as containers);
• The workloads: software that end users deploy on the above application framework.

Anthos clusters on bare metal support three deployment models to meet different requirements: Standalone Cluster Deployment, Multi-Cluster Deployment and Hybrid Cluster Deployment. Although all three deployment models of Anthos are relevant to the mission-critical space, this article will focus on the standalone standalone cluster deployment, where a single Kubernetes cluster supports both the admin and user cluster functions. An Anthos user cluster is a Kubernetes cluster that runs user workloads, while an admin cluster manages user clusters.

Both the control plane and the worker nodes are required for a standalone deployment model.

The block diagram (Figure 1) provides an overview of a standalone Anthos cluster running on a separation kernel hypervisor, LynxSecure, within the Mosa.ic software framework.

Five VMs are set up to perform specific tasks:

° Four Anthos cluster VMs.

• 1 control plane Kubernetes cluster node (as VM) - no support for high availability
• 2 worker Kubernetes cluster nodes (as VMs) - with high availability support
• 1 workstation VM - used for provisioning the control plane and worker nodes

A fifth VM for device management, which handles the incoming management requests. Typically this is used in conjunction with management software (either the company's own backend infrastructure or a third-party technology such as ServiceNow).

The author: Ian Ferguson is Vice President of Sales & Marketing at Lynx Software Technologies.

© Lynx Software

Due to the strict isolation provided by the LynxSecure separation kernel, the individual VMs operate in their own fault zones. The cluster VMs - control plane and worker nodes - and the workstation VM are connected via virtual Ethernet links (implemented via a managed shared memory). Although the VM hosting the device management has access to the Lynx Management Center, it has no internal connection to the cluster VMs. This arrangement, combined with the strict isolation guarantees of the LynxSecure Separation Kernel hypervisor, ensures that the Anthos workloads are virtually separated from the management plane activities.