容器集群日志审计与安全分析实战

摘要：

容器集群的安全运行离不开对操作行为的全面审计和事件的及时响应。本文介绍如何将各类容器平台的审计日志与事件日志统一接入腾讯云 CLS，实现集群操作的可视化分析和异常行为检测，为容器安全保驾护航。

一、容器集群安全面临的现实挑战

随着 Kubernetes 成为容器编排的事实标准，越来越多的企业将核心业务部署在容器平台上——无论是云厂商托管的 Kubernetes 服务（如腾讯云 TKE、阿里云 ACK、AWS EKS、华为 CCE），还是自建的 K8s 集群，它们都面临着相似的安全挑战。Pod 的频繁创建和销毁使得故障现场难以保留，多租户环境下的权限边界容易模糊，API Server 作为集群的统一入口则面临着各种未授权访问的风险。

在这些挑战中，可观测性是最基础也是最关键的一环。Kubernetes 原生提供了两类核心日志：审计日志（Audit Log）记录所有对 API Server 的操作请求——谁在什么时候做了什么，事件日志（Event Log）记录集群组件产生的运行时事件——系统发生了什么。将这两类日志统一接入腾讯云 CLS（Cloud Log Service）后，可以在一个平台上完成从日志采集到检索分析、仪表盘可视化和告警通知的全流程。CLS 作为一体化可观测 SaaS 服务，提供亿级日志秒级返回的检索性能，配合兼容 SQL 92 标准的统计分析能力（内置 200+ SQL 函数），大幅缩短安全事件的响应时间。此外，CLS 已上线 AI 助手（支持自然语言生成检索分析语句）和 MCP Server（让大模型直接查日志）等智能化能力，进一步降低使用门槛。

二、容器日志接入 CLS 的方式

2.1 不同容器平台的接入方法

根据容器平台的类型和部署位置，接入 CLS 的方式有所不同：

腾讯云 TKE：在 TKE 控制台的"日志管理"或 CLS 控制台的"云产品日志"中，可以直接开启集群审计日志和事件日志采集功能。系统会自动在集群中以 DaemonSet 方式部署采集代理，完成日志的实时收集与上报。TKE 云产品中心还提供了开箱即用的审计与事件分析仪表盘，覆盖集群操作类型分布、状态码分布、敏感操作用户等多个维度。

其他云平台的 Kubernetes 服务：对于阿里云 ACK、AWS EKS、华为 CCE 等产品，可以通过其日志导出功能将审计日志和事件日志写入对象存储或消息队列，然后利用 CLS 的数据导入功能定期拉取；或者通过 API/SDK 将日志直接写入 CLS。部分平台也支持通过 Fluentd/Fluent Bit 等开源采集器转发到 CLS。

自建 Kubernetes 集群：在集群中部署 CLS 提供的采集组件（以 DaemonSet 方式运行），配置好审计日志和事件日志的采集规则即可。采集组件会自动监听 API Server 的审计日志文件和 etcd 的事件数据，实时上报到 CLS。对于已经部署了 Fluentd/Fluent Bit 的集群，也可以通过配置 Output 插件将日志转发到 CLS。

无论采用哪种接入方式，最终日志都会以结构化格式存储在 CLS 日志主题中，后续的分析方法和 SQL 语句完全一致。

2.2 审计日志的核心字段

Kubernetes 审计日志遵循标准的 Audit Event 格式，关键字段如下：

2.3 事件日志的核心字段

Kubernetes 事件日志的关键字段如下：

在接入日志后，建议在 CLS 索引配置中对上述关键字段建立键值索引，并对数值字段（如 responseStatus.code、count）勾选"开启统计"选项，以便后续进行聚合分析。

如果同时接入了多个容器平台的日志，可以使用 CLS 的数据加工功能先将各来源的字段名标准化为统一的 Schema，然后再进行分析查询。

三、基于 CLS 的安全分析实战

3.1 排查工作负载消失问题

当发现某个重要的 Deployment 或 Pod 突然消失时，第一时间需要确认是谁执行了删除操作。在 CLS 检索分析页面输入以下 SQL，可以快速定位到删除操作的执行者和时间：

verb:delete AND objectRef.resource:pods | select count(*) as cnt, user.username, sourceIPs[1] as source_ip, requestReceivedTimestamp group by user.username, sourceIPs, requestReceivedTimestamp order by requestReceivedTimestamp desc limit 10

管道符前的 verb:delete AND objectRef.resource:pods 利用 CLS 的倒排索引先过滤出所有删除 Pod 的审计日志，再执行 SQL 聚合分析。这种"检索+SQL"两段式语法是 CLS 的特色，既发挥了倒排索引的快速筛选能力，又利用了 SQL 的灵活统计能力。

如果要追踪某个特定资源的完整操作历史：

objectRef.name:"nginx-deployment" | select verb, user.username, responseStatus.code, requestReceivedTimestamp order by requestReceivedTimestamp desc limit 20

3.2 检测未授权的访问尝试

审计日志中记录了每次 API 调用的响应状态码。大量的 403 状态码可能意味着有人在尝试访问没有权限的资源，而频繁的 401 则暗示着认证环节存在问题。

按用户统计 403 错误频率，识别潜在的越权行为：

responseStatus.code:403 | select count(*) as forbidden_count, user.username, sourceIPs[1] as source_ip group by user.username, sourceIPs order by forbidden_count desc limit 10

检测针对敏感资源的异常操作（如 secrets、RBAC 相关资源）：

(objectRef.resource:secrets OR objectRef.resource:roles OR objectRef.resource:rolebindings OR objectRef.resource:clusterroles) AND (verb:create OR verb:delete OR verb:update) | select count(*) as cnt, user.username, verb, objectRef.resource group by user.username, verb, objectRef.resource order by cnt desc limit 15

这条语句可以找出所有对敏感资源执行创建、删除、修改操作的用户和行为类型。对于特权操作的审计尤为关键——创建 ServiceAccount、修改 RBAC 策略、提升用户权限等操作都直接关系到集群的安全边界。

3.3 异常操作模式识别

通过 SQL 分析可以发现异常的操作模式。例如，统计每个用户在单位时间内的操作频率，找出异常活跃账号：

* | select count(*) as ops_count, user.username, time_series(cast(requestReceivedTimestamp as timestamp), '5m', '%H:%i:%s', '0') as time_window group by user.username, time_window having ops_count > 100 order by ops_count desc limit 10

time_series 函数会按 5 分钟间隔对时间轴进行分组，帮助识别短时间内的高频操作行为。正常情况下，单个用户的操作频率应该是相对平稳的；如果出现突增，可能是自动化脚本失控或被恶意利用。

按操作类型统计分布，发现不寻常的行为模式：

* | select verb, count(*) as cnt, round(count(*) * 100.0 / sum(count(*)) over(), 2) as percentage group by verb order by cnt desc

sum(...) over() 是 CLS 支持的窗口函数，用于计算总数以便得出百分比。正常情况下，get 和 list 操作应该占绝大多数；如果 delete、create 等写操作的比例异常偏高，就需要进一步调查。

3.4 事件日志中的异常信号检测

事件日志中的 Warning 类型事件往往预示着集群的健康问题。快速查看最近一段时间内最频繁的警告事件：

type:Warning | select count(*) as cnt, reason, involvedObject.kind, involvedObject.namespace group by reason, involvedObject.kind, involvedObject.namespace order by cnt desc limit 15

检测反复失败的 Pod 调度或容器启动：

type:Warning AND (reason:FailedScheduling OR reason:BackOff OR reason:Unhealthy OR reason:ErrImagePull) | select count(*) as cnt, reason, message, involvedObject.name group by reason, message, involvedObject.name having cnt > 3 order by cnt desc limit 10

having cnt > 3 用于排除偶发性事件，只关注反复出现的问题。BackOff 通常意味着容器反复崩溃重启，FailedScheduling 说明集群资源不足或调度约束无法满足，ErrImagePull 则指向镜像仓库连接或认证问题。

四、构建容器安全的持续监控体系

4.1 定时 SQL 分析与告警联动

对于需要持续监控的安全指标，可以使用 CLS 的定时 SQL 功能自动检测并触发告警：

responseStatus.code:403 | select count(*) as forbidden_count, user.username where __TIMESTAMP__ > now() - interval '5' minute group by user.username having forbidden_count > 20

将此查询设置为告警条件，当任意用户在 5 分钟内出现超过 20 次 403 错误时，系统会通过电话、短信、邮件、企业微信、钉钉、飞书等多种渠道通知安全值班人员。CLS 的告警支持多维分析附加——告警消息中可以附带具体的用户名、来源 IP 和被拒绝的资源列表，帮助快速判断是否为真实的安全威胁。

类似的告警场景还包括：

• 非工作时间段的敏感操作（如深夜对 secrets 的批量读取）
• 来自未知 IP 段的 API 调用
• 对 kube-system 命名空间中资源的异常修改
• 短时间内大量 Pod 被删除

4.2 审计仪表盘的固化与共享

将常用的安全分析查询保存为 CLS 仪表盘，可以让安全团队持续关注关键指标的变化。建议创建的仪表盘面板包括：

• 操作概览：总请求量、各动词分布、状态码分布
• 敏感操作监控：对 secrets/RBAC 资源的操作趋势
• 异常行为检测：403/401 错误率、高频操作用户 TOP 10
• 集群健康事件：Warning 事件按原因分类统计
• 命名空间资源变更：各命名空间的创建/删除/修改操作趋势

CLS 支持 20+ 种图表类型（时序图、柱状图、饼图、单值图、桑基图等），可以根据不同角色的需求定制专属视图。仪表盘还支持订阅功能——可以定期将截图通过邮件或企业微信推送给相关负责人，确保关键信息不被遗漏。

4.3 日志保留与合规要求

对于金融、医疗、政务等受监管行业，审计日志的保留期限有明确要求。等保 2.0 要求网络日志留存不少于 6 个月，某些行业标准甚至要求保留 1 年以上。CLS 支持 1-3600 天或永久的日志存储周期配置，可以满足各类合规要求。

对于需要长期保留但访问频率较低的审计日志，可以沉降到 CLS 低频存储，存储成本可降低约 60%。需要注意的是，低频存储仅支持全文索引，不支持键值检索——因此建议将近期日志（如 30 天内）保持在标准存储以支持高频检索和分析，历史日志再沉降到冷存储。

想要为容器集群搭建 CLS 日志审计体系，新用户开通即可领取 10U × 3 个月 免费资源包用于体验，首单特惠最低至 0.8 折起；新老用户购买资源包常规档位最低可享 6.3 折优惠。如需了解更多详情或领取优惠，可访问 腾讯云 CLS 产品页 及 特惠活动页。