Kubearmor x Open Horizon Protecting Edge Workloads
Open Horizon is a platform for managing the service software lifecycle of containerized workloads and related machine learning assets. It enables management of applications deployed to distributed webscale fleets of edge computing nodes and devices without requiring on-premise administrators.
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 (created and maintained by AccuKnox) can now protect these edge workloads. KubeArmor is a runtime security engine that can protect k8s-orchestrated, or pure containerized workloads as well as VM/Bare-Metal based workloads. LF Edge-led Open Horizon deploys the edge workloads in either containerized mode or k8s orchestrated mode. The Open Horizon Edge Agent operates directly on the host as a systemd process, or in a K8s cluster.
The most identified downside of edge computing is that it can increase attack vectors if implemented incorrectly.
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 in the 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 running on the edge node provides visibility and protection for all the processes, files, or network operations in the containers as well as those running directly on the host.
Observability: KubeArmor can provide container-aware observability information about the operations happening:
- from Agent node to Management Hub (and vice-versa)
- between the containers and the agent edge node
- inside the containers running on the Agent node
- The nodes and containers in a K8s cluster
Enforcement: KubeArmor can be used 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).
KubeArmor already supports k8s-orchestrated workloads and provides KVMService that allows orchestrating security policies to VMs for non-k8s environments. KubeArmor also supports standalone un-orchestrated containers. KubeArmor in this mode supports both enforcement and observability of the host and the containers running on it.
• Increased wear and tear, leading to potential hardware failures. • Additional power consumption, driving up utility costs.
- KubeArmor empowers DevSecOp teams to create and enforce granular security policies that prevent the execution of known crypto-mining software within their Kubernetes clusters.
- The provided policy template demonstrates how KubeArmor can block the execution of popular mining tools like xmrig, Dero miner, and PwnRig miner, effectively thwarting cryptojacking attempts before they take hold.
Kubearmor Policy to prevent cryptojacking attacks:
apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
name: prevent-crypto-miners
namespace: wordpress-mysql
spec:
selector:
matchLabels:
app: wordpress
message: cryptominer detected and blocked
severity: 2
action: Block
tags: [ "cryptominer", "fim" ]
process:
matchPaths:
# do not allow execution of binaries from /tmp/ folder
# do not allow execution of xmrig (xmrig.com)
- execname: xmrig
# prevent execution of Dero miner
- execname: dero
- execname: dero-miner-linux-amd64
- execname: dero-wallet-cli-linux-amd64
- execname: derod-linux-amd64
# do not allow execution of masscan/zgrab2/nmap used for recon
- execname: zgrab2
- execname: masscan
- execname: nmap
# do not allow package management tools execution
# execname allows to bloc
- execname: apt
- execname: apk
# time sync is important for miners. typically ntpdate is used.
- execname: ntpdate
# Do not allow overwriting system binaries
file:
matchDirectories:
- dir: /usr/local/bin/
- dir: /sbin/
- dir: /bin/
- dir: /usr/bin/
- dir: /var/local/bin/
- dir: /boot/
- dir: /tmp/
readOnly: true
recursive: true
Critical applications, especially privileged ones, are major attack surfaces for an attack. Implement the notion of "Trust no one" for the best security.
- KubeArmor helps organizations enforce a zero trust posture within their Kubernetes clusters. It allows users to define an allow-based policy that allows specific operations, and denies or audits all other operations.
- This helps to ensure that only authorized activities are allowed within the cluster, and that any deviations from the expected behavior are denied and flagged for further investigation.
Kubearmor Policy for zero trust:
apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
name: only-allow-nginx-exec
spec:
selector:
matchLabels:
app: nginx
file:
matchDirectories:
- dir: /
recursive: true
process:
matchPaths:
- path: /usr/sbin/nginx
- path: /bin/bash
action:
Allow
• An attacker might want to update the configuration so as to disable security controls or access logs. • Changes to system binary folders, configuration paths, credentials paths needs to be monitored for change.
- With KubeArmor, one can not only monitor for changes but also block any write attempts in such system folders. Compliance frameworks such as PCI-DSS, SOX, NERC CIP, FISMA, HIPAA, SANS expect FIM to be in place.
Kubearmor Policy for File Monitoring:
apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
name: fim-for-system-paths
namespace: wordpress-mysql
spec:
action: Block
selector:
matchLabels:
app: wordpress
file:
matchDirectories:
- dir: /bin/
readOnly: true
recursive: true
- dir: /sbin/
readOnly: true
recursive: true
- dir: /usr/sbin/
readOnly: true
recursive: true
- dir: /usr/bin/
readOnly: true
recursive: true
message: Alert! An attempt to write to system directories denied.
severity: 5
tags:
- NIST
- PCI-DSS
- In an attack scenario, a hacker may attempt to inject malicious scripts into the /tmp folder through a web application exploit.
- Once the script is uploaded, the attacker may try to execute it on the server in order to take it down.
- By hardening the /tmp folder, the attacker will not be able to execute the script, preventing such attacks. It's essential to implement these security measures to protect against these types of attacks and ensure the safety of the system.
Kubearmor Policy for noexec:
apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
name: ksp-block-exec-inside-tmp
namespace: wordpress-mysql
spec:
tags:
- config-files
message: Alert! Execution attempted inside tmp folder
selector:
matchLabels:
app: wordpress
process:
matchPatterns:
- pattern: /tmp/*
- pattern: /var/tmp/*
action: Block
