如何在Kubernetes中利用Kube-Armor实现基于LSM的Pod系统审计-linux运维-PHP中文网

kube-armor 不替代 kubernetes 原生审计日志，它专注运行时系统调用层策略执行与事件捕获，仅在 execve、openat、connect 等系统调用发生时触发，不记录 kubectl 等 api 请求。

如何在kubernetes中利用kube-armor实现基于lsm的pod系统审计

Kube-Armor 不能替代 Kubernetes 原生审计（audit log），它做的是运行时系统调用层的细粒度策略执行与事件捕获，不是 API 层审计。 如果你期望看到 kubectl delete pod 这类请求记录，Kube-Armor 不会生成；它只在容器进程实际执行 execve、openat、connect 等系统调用时触发策略匹配和日志上报。

为什么 Kube-Armor 日志看起来“不像审计”

Kube-Armor 依赖 eBPF + LSM（如 bpf、apparmor、selinux）拦截内核态行为，它的事件本质是「进程做了什么」，而非「谁通过 API 请求了什么」。典型输出字段包括：hostPID、containerID、syscall、operation、resource、policyName —— 这些和 kube-apiserver 的 RequestResponse 级审计日志结构完全不同。

原生审计日志路径通常是 /var/log/kubernetes/audit.log 或转发到 webhook/rsyslog，由 --audit-policy-file 控制
Kube-Armor 日志默认走 stdout（DaemonSet 容器），也可配置输出到 Kafka / Loki / Fluentd，但内容维度固定为 LSM 层行为
两者无数据重叠：API 请求未到达 kubelet 时，Kube-Armor 还没机会介入；Pod 被删后，其进程已不存在，Kube-Armor 也不会再产生对应事件

启用 Kube-Armor 后必须确认的 3 个 LSM 基础条件

即使 YAML 部署成功，Kube-Armor 也可能静默失效。关键检查点不在 Kubernetes manifest，而在节点内核环境：

Kubernetes Security Posture Scorecard

评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……

下载

确认节点内核启用了 CONFIG_BPF_SYSCALL=y 和 CONFIG_LSM="...,bpf"（或含 apparmor）—— 运行 zcat /proc/config.gz | grep -E "(BPF_SYSCALL|LSM)"，若无输出需重编译内核或换发行版（如 Ubuntu 22.04+、RHEL 9+ 默认满足）
检查 /sys/kernel/security/lsm 是否包含 bpf：执行 cat /sys/kernel/security/lsm，输出应类似 capability,landlock,bpf,apparmor
Kube-Armor DaemonSet 容器必须有 privileged: true 且挂载 /sys/fs/bpf 和 /run/containerd（或 /run/docker）—— 缺任一都会导致 eBPF 程序加载失败，kubectl logs -n kube-system ds/kube-armo 里会出现 "failed to load probe" 或 "permission denied"

Kube-Armor Policy 中 audit 模式的真实含义

action: AUDIT 并非开启“审计模式”，而是让策略仅记录不阻断。它和 action: BLOCK 共享同一套 LSM hook，区别仅在于是否调用 bpf_override_return()。常见误用：

以为 AUDIT 能捕获所有系统调用 —— 实际只捕获该 policy rule 中明确列出的 syscall（如 exec、file、network）子类，未声明的调用不会上报
在 process 规则里写 matchPaths: ["/bin/sh"] 却收不到日志 —— 因为实际执行的是 /bin/bash 或 shell wrapper，需用 matchDirectories 或通配符 "/bin/*"
对 network 规则设 destinationPort: 3306 但 Pod 用域名连接 MySQL —— DNS 解析发生在用户态，connect() 系统调用的目标地址已是 IP，端口匹配仍有效；但若应用使用连接池复用 socket，则首次 connect 后的读写不会再次触发该规则

把 Kube-Armor 日志接入 SIEM 的实用建议

原生输出是 JSON 行格式，但字段深度嵌套（如 data.process.executable）、部分值含二进制（data.process.args 是 base64），直接喂给 Splunk/Elasticsearch 易解析失败：

用 Fluent Bit 的 json 插件 + modify 过滤器展平关键字段：data.process.executable → executable，data.resource → target，避免深层点号造成索引问题
对 data.process.args 字段，加一条 lua 过滤器自动 base64-decode 并截断超长参数（防止字段爆炸），命令行参数过长时 Kube-Armor 本身就会截断，无需额外处理
不要依赖 data.hostPID 关联宿主机进程 —— 容器重启后 PID 变化，且多容器共享 PID namespace 时该值无意义；优先用 data.containerID 关联 CRI 日志或 data.podName/data.namespace