v0.9 Release Blog
KubeArmor v0.9 added support for new managed kubernetes platforms such as Oracle Container Engine for Kubernetes (OKE), IBM Cloud Kubernetes Service, and AWS Amazon Linux 2.
Support for ARM based cloud platforms such as AWS Graviton, and Oracle Ampere are added in v0.9.
Check out full KubeArmor support matrix here.
KubeArmor in-kernel event filtering changes were added in v0.9. The intention was to filter the events early in its cycle i.e., in the kernel space itself such that performance penalty of user space context switch is not incurred. Note that KubeArmor uses existing LSM (Linux Security Modules) hooks for policy enforcement. The LSM hooks are already enabled by default in all the Linux kernel images. Overall based on the benchmarking data taken on the docker sock-shop example, we found that the impact of KubeArmor is <3% on the overall requests per second performance of the sock-shop example.
Before v0.9, KubeArmor enabled telemetry across all the namespaces, deployments within the cluster. This caused significant telemetry events generated across non-user workload namespaces (such as kube-system). With v0.9, one can selectively enable process, file, network related telemetry across different namespaces.
KubeArmor supports multiple modes of deployment today, including using manifests files, helm, and using karmor cli tool.
However, operator-based installation was desired for KubeArmor for the following reasons:
- To handle the scenario where the cluster contains multiple nodes supporting different LSM (Linux Security Modules). KubeArmor cannot set the AppArmor annotation in context to the workload deployed on the node not supporting AppArmor.
- There are certain services such as Kubearmor relay whose resource utilization depends on the number of nodes operating within the cluster.
Operator-based installation and subsequent monitoring simplify the handling of such scenarios.
With this release, the karmor cli tool or the helm/manifests will install the operator and then the operator will install the relevant Daemonset and services needed.
Explain what changes had to be done? What Enforcement logic had to be used?
Multiple controllers such as policy-controller and host-policy-controller were separately installed. The new release consolidates multiple controllers into a single pod reducing the overall number of kubearmor pods deployed in the cluster.
- Full Enforcement on BPF LSM with Path based hooks. BPF-LSM based enforcement lacked certain enforcement support previously wherein file open related events were handled but a simple inode creation events were not handled. This resulted in certain operations (such as
touch) to succeed even if the path is marked as blocked.
