Kubernetes集群每天产生的日志量相当惊人，apiserver的审计日志、kubelet的事件记录、容器运行时的安全事件、网络策略的拒绝记录，这些信息分散在不同的组件里。如果只靠人工grep或者简单的告警脚本，攻击行为很容易被淹没在海量噪音中。SIEM（Security Information and Event Management，安全信息与事件管理）平台的价值就在于把这些分散的安全数据集中起来，做关联分析、异常检测和统一告警。本文将详细讲解集群安全数据的特点、采集方案以及与SIEM系统集成的完整实践。
一、理解SIEM的核心能力与集群安全数据的特点
SIEM平台的核心能力可以概括为三点：日志聚合、关联分析和告警响应。日志聚合负责把不同来源、不同格式的数据统一收集和标准化；关联分析基于规则或机器学习模型，把多个看似孤立的事件串联起来，比如同一个Pod在短时间内先执行了敏感文件读取、又发起了异常外连，单独看每条日志都没问题，但组合起来就是典型的入侵迹象；告警响应则负责把分析结果推送给运维人员或者触发自动化处置流程。
常见的SIEM平台包括商业产品Splunk、IBM QRadar，以及开源方案ELK Stack（Elasticsearch、Logstash、Kibana）、OpenSearch和Wazuh。选型时主要考虑数据吞吐量、解析能力、存储成本和团队熟悉度。对于日均日志量在百GB以内的中小团队，ELK或OpenSearch配合自建规则通常够用；金融、政务等合规要求高的场景，商业产品的报表和合规模板更有优势。
Kubernetes环境下的安全数据有几个鲜明特点。第一是来源分散，审计日志在apiserver、网络事件在网络插件、运行时事件在容器层、应用日志在Pod内部；第二是格式不统一，有JSON、有protobuf转换后的结构化文本，也有纯文本；第三是动态性强，Pod随时创建销毁，IP和主机名不断变化，传统的基于固定IP的SIEM规则会大量失效。因此集成方案必须解决采集、标准化和上下文补充三个问题。
二、开启审计日志并搭建采集管道
审计日志是集群安全分析中最重要的数据源，它记录了所有对apiserver的请求，包括谁在什么时间对什么资源做了什么操作。默认情况下审计功能是关闭的，需要手动配置。先准备一份审计策略文件，重点记录secrets访问和RBAC变更等敏感操作，同时对系统组件的高频心跳请求降低级别以减少噪音。
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# 记录所有secret的访问
- level: Metadata
resources:
- group: ""
resources: ["secrets"]
# 记录RBAC变更的完整请求响应
- level: RequestResponse
verbs: ["create", "update", "patch", "delete"]
resources:
- group: "rbac.authorization.k8s.io"
# 忽略系统组件的低风险读操作
- level: None
users: ["system:kube-proxy"]
verbs: ["get", "watch", "list"]
# 其余请求记录元数据
- level: Metadata
然后在apiserver的启动参数中指定策略文件和日志后端。如果集群由kubeadm部署，修改静态Pod清单即可，文件路径为C:\等Windows路径不适用，Linux下通常是/etc/kubernetes/manifests/kube-apiserver.yaml，挂载好策略文件并添加以下参数：
apiVersion: v1
kind: Pod
metadata:
name: kube-apiserver
spec:
containers:
- name: kube-apiserver
command:
- kube-apiserver
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml
- --audit-log-path=/var/log/kubernetes/audit.log
- --audit-log-maxage=7
- --audit-log-maxbackup=5
- --audit-log-format=json
采集管道方面，推荐使用Fluent Bit以DaemonSet方式部署在每个节点上，它资源占用低、插件生态丰富，能直接对接Elasticsearch、Splunk、Kafka等后端。关键配置如下：
[INPUT]
Name tail
Path /var/log/kubernetes/audit.log
Tag kube.audit
Parser json
DB /var/log/flb_audit.db
[FILTER]
Name kubernetes
Match kube.*
Merge_Log On
[OUTPUT]
Name es
Match kube.audit
Host siem-es.ipipp.com
Port 9200
Index k8s-audit
Logstash_Format On
这份配置把审计日志以JSON格式解析后写入Elasticsearch的k8s-audit索引。如果目标是Splunk，把OUTPUT段换成splunk插件并配置HTTP Event Collector地址即可。对于多集群场景，建议在采集端与SIEM之间加一层Kafka做缓冲，即使SIEM后端短暂故障，日志也不会丢失。
三、补充运行时与网络事件，构建完整检测视图
仅有apiserver审计日志还不够，很多攻击发生在审计视野之外，比如容器内执行的恶意进程、文件篡改、反弹Shell。这就需要引入运行时安全组件，例如Falco。它基于内核态事件监控系统调用，能检测容器内的异常行为并输出结构化告警，规则写法如下：
- rule: Read sensitive file in container
desc: 检测容器内读取敏感文件的行为
condition: container and open_read and
(fd.name startswith /etc/shadow or
fd.name startswith /root/.ssh)
output: "敏感文件被读取 (user=%user.name pod=%k8s.pod.name file=%fd.name)"
priority: WARNING
Falco的告警可以直接发送到Elasticsearch，或者经由fluentd中转。网络层面，如果使用Cilium作为CNI，其配套的Hubble组件能记录网络流量的可观测数据，包括被NetworkPolicy拒绝的连接尝试，这些数据对检测横向移动非常有价值。
把多源数据统一接入SIEM后，就可以编写关联规则了。举个例子：当Falco报告某个Pod存在提权行为，同时Hubble显示该Pod向外部可疑IP发起连接，且审计日志显示该Pod的ServiceAccount最近被修改过RBAC权限，三条事件在同一时间窗口内出现时触发高危告警。这种多源关联能力正是SIEM相比单点监控工具的核心价值，在OpenSearch中可用告警插件配置，在Splunk中则通过SPL搜索语言实现。
四、集成过程中的关键问题与优化建议
第一是性能与成本。审计日志设置为RequestResponse级别时，体积可能是Metadata级别的十倍以上，大规模集群一天能产生数百GB日志。建议分级设置策略：secrets、RBAC相关操作用高详细级别，日常的get、list、watch用Metadata甚至None级别，并通过轮转参数控制磁盘占用。采集Agent也要设置资源限额，避免Fluent Bit占用过多内存影响业务容器。
第二是日志规范化。不同数据源的时间戳格式、字段命名差异很大，建议在采集端就完成字段映射，统一使用ISO8601时间格式，把k8s.pod.name、k8s.namespace、k8s.node等上下文字段提取为标准字段，方便后续跨源关联查询。可以在Fluent Bit中用Lua脚本或record_modifier过滤器完成这项工作，避免把清洗压力留给后端。
第三是误报治理。SIEM接入初期告警量往往爆炸，正确做法是先以观察模式运行规则两周，统计各类告警的频率和准确性，逐步调优阈值，再把低置信度规则降级为只记录不告警。同时建立告警分级机制，高危事件立即通知，中低危事件汇总成日报。另外别忘了合规要求，等保等监管通常要求日志保留六个月以上，要提前规划SIEM索引的生命周期策略，冷数据转对象存储能大幅降低成本。
总结来看，集群与SIEM的集成不是简单地把日志堆到一起，而是一套从审计策略制定、采集管道搭建、多源数据关联到告警治理的完整工程。先把apiserver审计日志这条主线跑通，再逐步接入Falco和Hubble等运行时与网络数据源，配合持续调优的关联规则，才能让集群安全监控从被动查看进化为主动发现威胁。