KubeArmor 通过 LSM（如 BPF-LSM、AppArmor、SELinux）在内核层面拦截系统调用，结合 Pod 上下文实现细粒度审计；需启用 --enable-kubearmor-audit=true、内核支持对应 LSM，并配置 action: Audit 策略触发日志记录。
KubeArmor 能在 Kubernetes 中实现细粒度的 Pod 系统调用审计，核心在于它不依赖容器层抽象，而是直接利用 Linux 安全模块（LSM）——如 AppArmor、SELinux 或 BPF-LSM —— 在内核层面捕获并标记系统调用事件，并将这些事件与 Kubernetes 的 Pod、容器、命名空间等上下文强绑定。
LSM 是审计能力的基础
KubeArmor 本身不替代 LSM，而是作为策略编排与事件增强层运行在 LSM 之上。它通过以下方式激活审计能力：
- 检测节点内核启用的 LSM 类型（如
bpf-lsm可用时优先使用，否则回退到apparmor或selinux） - 为每个受保护的 Pod 自动注入对应 LSM 配置（例如生成 AppArmor profile 或加载 eBPF 程序）
- 利用 LSM 的
security_bprm_check、security_file_open、security_socket_connect等钩子，拦截关键系统调用 - 所有拦截事件默认记录为“audit”级别日志，含完整容器身份（
PodName、ContainerName、Namespace、HostPID）
启用系统调用审计的必要配置
默认部署下 KubeArmor 已开启基础审计，但要获得完整系统调用上下文（如参数、返回值、调用栈），需确认以下几点：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 集群节点内核需启用
CONFIG_BPF_LSM=y（推荐）或至少启用CONFIG_SECURITY_APPARMOR=y；可通过zcat /proc/config.gz | grep LSM或检查/sys/kernel/security/lsm验证 - 部署时启用
--enable-kubearmor-policy=true和--enable-kubearmor-audit=true（Helm values 或 DaemonSet args） - 确保
kubearmor-feeder组件正常运行，它负责收集、富化并转发 LSM 原始事件 - 审计日志默认输出到
stdout和kubearmor-audit日志流，也可配置输出到 Fluentd、Loki 或 Kafka
定义带审计意图的安全策略
审计行为由策略中的 action: Audit 显式触发，而非仅靠默认拒绝。例如：
apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
name: audit-sensitive-file-access
spec:
selector:
matchLabels:
app: payment-service
file:
matchPaths:
- path: /etc/ssl/private/
recursive: true
action: Audit
该策略不会阻止访问，但会为任何进程尝试打开该目录下文件的行为生成一条含 Pod 标识的审计日志，包括：ProcessName、ParentProcessName、Source、Operation（openat）、Resource（具体路径）、Result（success/failure）。
验证和排查审计日志
快速确认审计是否生效：
- 执行
kubectl logs -n kubearmor deploy/kubearmor -c feeder | grep "Audit"查看实时审计事件 - 在目标 Pod 内触发被监控行为（如
cat /etc/ssl/private/key.pem），观察是否产生日志 - 若无日志，检查节点是否缺失 LSM 支持（
dmesg | grep -i lsm）、KubeArmor 是否以privileged模式运行、eBPF 程序是否加载成功（bpftool prog list | grep kubearmor） - 审计日志中若缺少容器上下文，说明
systemMonitor未正确关联 cgroup2 路径，需确认容器运行时使用 cgroup v2（如 containerd 默认已启用）
