Skip to content

v0.6 Release Blog

achrefbensaad edited this page Aug 31, 2022 · 22 revisions

THIS IS A WORK-IN-PROGRESS ...

Support for non-orchestrated containers

KubeArmor already has support for K8s orchestrated and Bare-Metal/VM workloads. With the v0.6 stable release, KubeArmor will also support un-orchestrated containerized workloads. KubeArmor supports both observability and policy enforcement in this mode.

The need for supporting non-orchestrated containers?

KubeArmor recently did a POC with LFEdge Open Horizon project. Open Horizon supports using containerized workloads on the edge such that multiple applications from different vendors could be deployed on the edge node as different containers. It is imperative that the security aspects of such a multi-tenant solution needs to be taken into consideration. It is required that the security gaps in one of the container should not lead to compromises in other containers or at the host level. Container isolation and hardening has to be ensured such that the blast radius and containment of security flaws is localized.

Path to Zero Trust Edge

Discovering and enforcing least-permissive policies...

For the enforcement, KubeArmor generates AppArmor profiles for individual containers based on the policy specified. The containers are required to start with the AppArmor profiles attached (using security-opt apparmor='profile-name'). These profiles can later be dynamically updated by KubeArmor to insert, modify or remove the AppArmor enforcement. Un-orchestrated workloads have a real use case in edge devices where orchestration is hard due to resource restrictions. KubeArmor can now help protect such environment.

Improvements to policy allow listing

Karmor Probe, ability to probe for support of kubearmor

Performance improvements

Ability to watch for system calls events

Starting from v0.6, KubeArmor introduced the ability to explicitly monitor for system calls and alert based on rules set by the user. The system calls rules matching engine offers multiple options for our users to slice and dice system calls to obtain useful informations about their systems.

How can I levrage this new functionality ?

Our users can set policies to alerts for system call based on many criterias such as:

  • system call name
  • system call source (binary or directory)
  • system call target (binary or directory)

Real life example

In this example we want to watch for file deletions via the unlink system calls that impacts any directory under /home/.

KubeArmorPolicy:

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: audit-home-rmdir
  namespace: default
spec:
  severity: 3
  selector:
    matchLabels:
      container: ubuntu-1
  syscalls:
    matchPaths:
    - syscall:
      - rmdir
      path: /home/
      recursive: true
  action:
    Audit

Generated telemetry

ksp-rmdir-syscall

BCC deprectation in favor of cilium/ebpf

OpenShift support

Clone this wiki locally