What is Edge Computing?

More data is being created from more locations than ever before. With the increase in IOT devices and the need to process information in real-time creates edge computing a necessity for the future.

Edge computing is a way to bring computational and storage workloads close to the edge where the data is created. The aim is to reduce latency by doing data analysis outside the cloud at the edge of the network where real-time processing of data is required. This also reduces the bandwidth as fewer processes are sent to the cloud.

Edge computing provides reliability as it continues to operate even when the communication channels are down. Furthermore it provides resiliency by reducing a central point of failure, as is the case of centralized cloud servers.

High-level topology for a typical edge computing setup (Source: LF Edge – Open Horizon

Key benefits offered by edge computing:

• Improved performance and reduced latency
• Cost efficient
• Reliability and Flexibility

Open Horizon

Open Horizon is a platform for managing the service software lifecycle of containerized workloads and related machine learning assets.

Open Horizon provides features to help manage and deploy workloads from a management hub cluster to edge devices and remote instances of orchestrated clusters. It is:

• Edge Native
• Decentralized – Minimal central Management Hub with independent Agents on each node
• Zero Touch – Installation and device-specific configuration is fully automated
• Disconnected – Fully autonomous agent continues to monitor and manage applications even when disconnected from their Management Hub

Open Horizon components (Source: LF Edge – Open Horizon)

The biggest hurdle – Security

The most identified downside of edge computing is that it can increase attack vectors.

Data at the edge can be difficult to handle when it’s being collected from multiple sources that might not be as secure as a centralized systems. These devices often contains sensitive user data so it becomes more important to protect both the host edge node and the applications running on it.

Open Horizon addresses most of these security issues by following ways:

• All participants are untrusted and must formally establish trust
• Agents are autonomous and each of them has authority only for their node
• Switchboards enable secure communication but can neither read nor write anything
• Exchange relies on an external authn/authz mechanisms
• All code and configuration is hashed and cryptographically signed
• All participants are anonymous and known by the public keys and a node ID

Due to Open Horizon’s autonomous agents, a compromised node doesn’t affect the larger system. But even after all the above security measures, if a malevolent actor somehow gets control of an edge node, they will be able to access and execute anything they want on the node thus compromising the local agent.

Thus it becomes equally important to protect these independent agents too.

KubeArmor x Open Horizon

Accuknox’s open source application hardening solution based on KubeArmor and Discovery Engine provides:

• Deep observability of edge workloads
• Ability to do policy enforcement at granular level
• Ability to automatically generate least permissive security posture

KubeArmor

KubeArmor is a cloud-native runtime security enforcement system that restricts the behavior (such as process execution, file access, and networking operation) of containers and nodes (VMs) at the system level

KubeArmor operates on top of Linux Security Modules (LSMs) like AppArmor, BPF-LSM and SELinux which provides a kernel-level security enforcement. It uses eBPF based system monitoring for providing container aware logs for policy violations by monitoring the container’s processes operations.

KubeArmor on Open Horizon

Enforcement: KubeArmor allows operators to apply security postures at the kernel-level (using LSMs like AppArmor, BPF-LSM). It can protect both the host and workloads running on it by enforcing either some predefined security policies or automatically generated least permissive security policies (using Discovery Engine).

The generated logs can provide great insight on the current operations happening inside the workloads. Further, the alerts on policy violation provide detailed reason for the violation.

Let’s apply a sample policy to prevent unauthorized updates to root certificates and restrict access to certificates folders.

The subsequent alert generated on violation of above policy:

Here the alert shows that the process update-ca-certificates (with full path) when run by parent process /bin/bash resulted in a “Permission denied” due to a policy action of “Block” being applied.

KubeArmor can be run both on the Open Horizon Management Hub and the Agents as a system service or in container mode.

Note: The PodName field in the alert makes more sense in context of k8s workloads

Observability: KubeArmor can provide container-aware observability information about the operations happening:

1. from Agent node to Management Hub (and vice-versa)
2. between the containers and the agent edge node
3. inside the containers running on the Agent node

For providing container-aware observability, KubeArmor takes use of an eBPF-based system monitor, which tracks process life cycles in containers and nodes.

Discovery Engine

Discovery Engine discovers the security posture for your workloads and auto-discovers the policy-set required to put the workload in least-permissive mode.

The engine leverages the rich visibility provided by KubeArmor and Cilium to auto discover the systems and network security posture.

Auto policy discovery is an open source policy recommendation system. It is a plug-in for Kubernetes environments that discovers network and system policies based on the collected network and system logs from the various container network interfaces (CNIs). The engine leverages aggregation techniques to reduce the number of policies discovered, uses pod labels for rules specification, and handles the discovery across multiple dimensions (networks, systems).

The Discovery Engine can be used to generate least-permissive allow policies for both host and the containers running on it. These policies when applied provides an isolated Zero Trust environment where only necessary operations are allowed rest everything is denied by default.

Conclusion

Containers are lightweight with a very low footprint making them a natural fit for edge devices.

With edge computing shifting towards containerized workloads and in few cases to orchestrated kubernetes workloads, it becomes important to have a security solution which can not only provides enforcement into different forms of deployment but can also provide real-time container-rich observability.

KubeArmor supporting un-orchestrated containers, k8s workloads and bare metal VMs makes it an ideal universal engine. It’s kernel-level runtime security enforcement and container aware observability brings best of both the worlds.