# 关于 KubeArmor 的闲言碎语

早上看到了一篇关于 [KubeArmor 的简介](https://mp.weixin.qq.com/s/OCn9VPjxXLx0p4djD8hg3A)，觉得还挺新鲜的，就坐下看了一下介绍，并没有进行实际的测试，把它和我之前比较熟悉的一些类似技术做一点比较。

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745897233722/b259807d-24d1-4312-816d-5fec7e96b7fa.png align="center")

上图是官方提供的架构说明，它依赖于 AppArmor、SeLinux（下个版本）以及 KRSI（未来）这样的 LSM，对容器中的进程进行监控和限制，借助 eBPF 技术将进程信息和 Kubernetes 关联起来，从而获取到进程的 K8s 相关信息，能够根据策略阻止或者上报违规行为，并把过程发送到日志、标准输出以及 gRPC 目标之中，未来还会支持数据库、Kafka、ES 等。目前关注的行为包括以下几个方面

* 进程执行
    
* 文件访问
    
* 网络操作
    
* Capabilities
    

它的定义和 PSP 以及 SecurityContext 都不同，采用了类似 Kyverno 类似的方式，定义规则，然后用 Label Selector 将策略关联到 Pod 上，例如源码中提供的例子：

```yaml
apiVersion: security.accuknox.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-ubuntu-1-proc-dir-block
  namespace: multiubuntu
spec:
  selector:
    matchLabels:
      container: ubuntu-1
  process:
    matchDirectories:
    - dir: /sbin/
  action:
    Block
```

规则针对标签 `container=ubuntu-1` 的 Pod 中的容器，禁止执行 `/sbin/` 下的命令。

个人觉得功能方面最相似的工具就是 Falco 了，它的配置无疑比相对“传统”的 Falco 方便了许多，并且还有 **BLOCK** 能力；但是其输入条件的丰富程度是远不如 Falco 的，例如对 ServiceAccount、Verb、Subresource 等 K8s 特定元数据的输入支持，条件语法也不如 Falco 灵活。

## 以下结论纯属胡说

> OPA/Kyverno 有这种功能就有意思了。

项目地址：`https://github.com/accuknox/KubeArmor`