Skip to content

v0.6 Release Blog

Jump to bottom
achrefbensaad edited this page Sep 2, 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.

Introducing a lenient way to whitelisting policies

Whitelisting is a security strategy where you predefine all the entities that are to be permitted to execute and access resources. It is a fairly extreme containment measure that, if properly implemented, can prevent many security issues. KubeArmor supports whitelisting by leveraging "Allow" Action in the Policy Specification. But as mentioned it's an extreme containment measure and is fairly hard to implement. What if we want to confine what processes a particular resource can be accessed by. With v0.6 release, KubeArmor has a way to confine what processes a particular resource can be accessed by.

An example policy :

  file:
    matchDirectories:
      - dir: /run/secrets/kubernetes.io/serviceaccount/
        recursive: true
        action: Block # Block access to service account token to everyone
      - dir: /
        recursive: true
      - dir: /run/secrets/kubernetes.io/serviceaccount/
        recursive: true
        fromSource:
          - path: /bin/cat # Allow access to service account token to only cat
  process:
    matchDirectories:
      - dir: /
        recursive: true # Allow all other process execution in general

Service Account Tokens are automounted to Pods, it helps provide better access to the Kubernetes API server. But this token becomes problematic if an attacker gains access to a container via some other exploit. We can set automountServiceAccountToken: false but for Pods where Service Account Tokens are needed, the token is still exposed to all the entities available inside the pod. The above KubeArmor Policy helps restrict the access to Service Account Token to some particular binaries (in this case /bin/cat).

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

{
  "Timestamp": 1661936575,
  "UpdatedTime": "2022-08-31T09:02:55.841537Z",
  "ClusterName": "default",
  "HostName": "vagrant",
  "NamespaceName": "default",
  "PodName": "ubuntu-1-6779f689b5-jjcvh",
  "Labels": "container=ubuntu-1",
  "ContainerID": "1f613df8390b9d2e4e89d0323ac0b9a2e7d7ddcc460720e15074f8c497aec0df",
  "ContainerName": "nginx",
  "ContainerImage": "nginx:latest@sha256:b95a99feebf7797479e0c5eb5ec0bdfa5d9f504bc94da550c2f58e839ea6914f",
  "HostPPID": 255296,
  "HostPID": 302715,
  "PPID": 47,
  "PID": 67,
  "ParentProcessName": "/bin/bash",
  "ProcessName": "/bin/rmdir",
  "PolicyName": "audit-home-rmdir",
  "Severity": "3",
  "Type": "MatchedPolicy",
  "Source": "/bin/rmdir home/jane-doe/",
  "Operation": "Syscall",
  "Resource": "/home/jane-doe",
  "Data": "syscall=SYS_RMDIR",
  "Action": "Audit",
  "Result": "Passed"
}

For more informations, Please checkout our policy specification documentation.

KubeArmorPolicy specification: https://docs.kubearmor.com/kubearmor/getting-started/security_policy_specification

KubeArmorHostPolicy specification: https://docs.kubearmor.com/kubearmor/getting-started/host_security_policy_specification

BCC deprectation in favor of cilium/ebpf

OpenShift support

Clone this wiki locally