Kubernetes 审计日志安全分析实战从 JSON Lines 事件格式到五大威胁检测规则(基于 Anthropic-Cybersecurity-Skills)【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills本篇指南基于 Anthropic-Cybersecurity-Skills 仓库中analyzing-kubernetes-audit-logs技能的 API 参考文档,系统讲解 Kubernetes API Server 审计日志的 JSON Lines 事件结构、安全关键事件识别、审计策略级别差异,以及如何用 Python 编写可落地的威胁检测规则。读完后,你将能够独立解析集群审计日志,识别 Pod 内执行、Secret 访问、RBAC 变更、特权容器创建与匿名 API 访问等高危行为,并将其转化为 Kubernetes 专属的 SIEM 检测规则。1. Kubernetes 审计日志的事件结构(JSON Lines 格式)Kubernetes 审计日志由 API Server 按 JSON Lines 格式输出——每一行是一条独立、自包含的 JSON 事件,对应一次 API 请求。参考文档给出的标准事件样例如下:{ kind: Event, apiVersion: audit.k8s.io/v1, level: RequestResponse, verb: create, user: {username: admin, groups: [system:masters]}, sourceIPs: [10.0.0.5], objectRef: { resource: pods, subresource: exec, namespace: default, name: web-pod }, responseStatus: {code: 200}, requestReceivedTimestamp: 2025-03-15T14:00:00Z }逐字段理解是编写检测规则的基础:字段含义检测用途kind/apiVersion事件类型,固定为Event与audit.k8s.io/v1区分审计事件与其他日志行level该事件被记录时的审计级别判断能否获取请求/响应体verbAPI 动词:create、get、list、update、delete、watch等区分读操作与写操作,写操作通常是提权信号user请求方身份,含username与groups识别system:anonymous等未认证身份与system:masters等高权组sourceIPs请求源 IP 数组定位发起请求的节点、客户端或代理objectRef被操作的资源定位:resource、subresource、namespace、name检测规则的核心匹配键,如podsexec子资源responseStatus.codeAPI 响应码判断请求是否成功,例如只对成功(4xx 以下)的匿名访问告警requestReceivedTimestamp请求接收时间(UTC)事件排序、时间线与频率分析值得注意的是objectRef中resource与subresource的组合方式:kubectl exec进入容器在审计日志中表现为resource: pods、subresource: exec,而不是简单的pods/exec字符串。仓库中 SKILL.md 的示例代码里用了resource pods/exec的简写判断,而正式实现 agent.py 则采用更严谨的subresource in (exec, attach)判断,后者能同时覆盖 exec 与 attach 两种进入容器行为,编写规则时建议以后者为准。2. 五类安全关键审计事件及严重度分级API 参考文档将安全关键事件归纳为一张速查表,这是整个检测逻辑的骨架:事件objectRef 特征严重度Pod execresource: pods, subresource: execHIGHSecret 访问resource: secrets, verb: get/listHIGHRBAC 变更resource: clusterrolebindingsCRITICAL特权 PodrequestObject.spec.containers[].securityContext.privilegedCRITICAL匿名访问user.username: system:anonymousCRITICAL结合 scripts/agent.py 的源码,可以逐条展开每类事件的检测语义:2.1 Pod exec/attach(容器内执行)detect_pod_exec()遍历所有事件,只要objectRef.subresource为exec或attach即记为 HIGH 级发现,并提取时间戳、用户、所属组、命名空间、Pod 名与源 IP 组成完整证据。这类事件意味着操作者获得了容器内的进程执行能力,是入侵者进入工作负载的直接信号;攻击者利用被窃取的合法凭据执行kubectl exec时,审计日志中会留下system:masters等高权组的痕迹,可与 MITRE ATTCK 的有效账户(Valid Accounts)类技术对应。2.2 Secret 访问(凭证窃取前置动作)detect_secret_access()匹配resource secrets且动词在get/list/watch/create/update/delete范围内的所有事件,并做精细的严重度分级:severity: HIGH if verb in (list, delete) else MEDIUM,即list(批量枚举 Secret)与delete(破坏性操作)直接定为 HIGH,而单次get等为 MEDIUM。这一分级值得在自研 SIEM 规则中复用:一次get可能是正常发布流程,但对同一 Secret 的高频get或全命名空间list则高度可疑。每条发现都会带上secret_name与source_ip,便于定位具体泄露的凭证。2.3 RBAC 变更(权限提升通道)detect_rbac_changes()监控四类资源的写操作:rbac_resources {clusterroles, clusterrolebindings, roles, rolebindings} # 且 verb in (create, update, patch, delete)严重度按资源作用域区分:资源名包含cluster(如clusterrolebindings)判为 CRITICAL,命名空间级(roles/rolebindings)判为 HIGH。创建 ClusterRoleBinding 将任意 ServiceAccount 或用户绑定到cluster-admin是典型的集群权限提升路径,属于 SKILL.md 中列出的RBAC escalation核心检测场景。2.4 特权 Pod 创建detect_privileged_pods()的实现展示了依赖请求体的检测模式:它只在verb create且resource pods时,深入解析requestObject.spec.containers[],逐一检查securityContext.privileged是否为真:request_obj event.get(requestObject, {}) spec request_obj.get(spec, {}) containers spec.get(containers, []) for container in containers: sc container.get(securityContext, {}) if sc.get(privileged): # 记录为 CRITICAL这与参考文档表格中requestObject.spec.containers[].securityContext.privileged的写法完全一致,也点出了关键前提:只有审计级别为RequestResponse(或至少Request)时日志中才存在requestObject字段,否则该规则将全部落空(详见第 4 节)。特权容器可逃逸到宿主机,故直接定级 CRITICAL。2.5 匿名/未认证访问detect_anonymous_access()识别两类身份:username属于{system:anonymous, system:unauthenticated},或groups中包含system:unauthenticated。更关键的是它附加了一个结果码过滤:status_code event.get(responseStatus, {}).get(code, 0) if status_code 400: # 记为 CRITICAL 发现即只有当匿名请求成功(响应码 400 以下)时才告警。被 RBAC 拒绝的匿名探测(如 403)属于背景噪声,而成功的匿名读请求说明 API Server 认证/授权配置存在漏洞——这通常是集群被利用的第一步。2.6 附加信号:403 Forbidden 激增除上述五类外,agent.py 还实现了detect_forbidden_surge():按用户聚合所有responseStatus.code 403的事件,默认阈值threshold20,超过阈值的用户进入按次数降序排列的告警列表。这一逻辑用于捕获探测—枚举—暴力尝试行为模式:攻击者在凭据权限不足时批量试探 API,会留下密集 403。3. 审计策略级别(Audit Policy Levels)决定检测能力边界参考文档中的审计级别表明确了各级别捕获的信息量:级别捕获内容None不记录Metadata时间戳、用户、动词、资源RequestMetadata 请求体RequestResponse请求 响应体这张表直接决定了检测规则的可实现性,可以推断出以下工程结论:Metadata 级别足以支撑 2.1、2.2、2.3、2.5 四类基于verb/objectRef/user的规则,但无法检测特权 Pod(需要requestObject);Request 级别起,requestObject进入日志,特权容器检测规则才可生效;RequestResponse 级别额外包含responseObject,可用于确认创建对象的最终状态,但日志体积最大、且 Secret 数据会以明文进入日志文件,需要配合日志存储的访问控制与脱敏策略;实践中常见做法是:对clusterrolebindings、secrets等敏感资源规则设为RequestResponse,对集群其余 API 设为Metadata或Request,在可观测性与性能、日志间平衡。此外,不同级别下字段缺失是常态(如 Metadata 事件没有requestObject),因此解析代码必须使用event.get(requestObject, {})这类带默认值的防御式取值——agent.py 的所有检测函数均遵循这一写法,保证同一脚本可处理混合级别的日志文件。4. Python 解析与完整分析管线4.1 最简解析参考文档给出的最小解析器如下,足以快速浏览事件流:import json with open(audit.log) as f: for line in f: event json.loads(line) print(event[verb], event[objectRef][resource])4.2 生产级解析(健壮性处理)真实日志中可能存在空行或截断的 JSON。agent.py 的parse_audit_log()在最小解析器之上增加了三项健壮性处理,建议作为基线写法:def parse_audit_log(log_path): Parse Kubernetes audit log file (JSON lines format). events [] with open(log_path) as f: for line in f: line line.strip() if not line: continue try: events.append(json.loads(line)) except json.JSONDecodeError: continue return events要点:逐行strip()后跳过空行;对json.JSONDecodeError静默容错(跳过坏行),避免单条损坏事件中断整个分析。4.3 命令行运行方式agent.py 是一个独立的 CLI 工具,核心参数与默认值如下(取自 agent.py 的 argparse 定义):参数说明默认值--audit-log审计日志文件路径(必填)—--outputJSON 报告输出路径k8s_audit_report.json--action检测动作:exec/secrets/rbac/privileged/anonymous/full_analysisfull_analysis运行示例:# 全量分析(五大类 403 激增) python3 skills/analyzing-kubernetes-audit-logs/scripts/agent.py \ --audit-log /var/log/kubernetes/audit.log \ --output k8s_audit_report.json # 只查 Pod exec/attach 行为 python3 skills/analyzing-kubernetes-audit-logs/scripts/agent.py \ --audit-log audit.log --action exec报告结构固定为四段:日志文件名(log_file)、成功解析的事件总数(total_events)、生成时间(generated_at)与按类别分组的findings(pod_exec、secret_access、rbac_changes、privileged_pods、anonymous_access、forbidden_surges)。运行过程会打印每类命中的计数,例如[] Parsed 1024 audit events、[] Pod exec/attach events: 3,便于快速判断日志规模与命中面。5. 从检测规则到威胁框架映射该技能并非孤立的日志脚本,在 SKILL.md 的 frontmatter 中,它被映射到完整的合规与威胁框架体系:MITRE ATTCK:T1610(利用执行)、T1613(容器/主机间移动)、T1078(有效账户)、T1552.007(从容器密钥库获取凭证)——分别对应 Pod exec、容器横向、高权账户滥用与 Secret 窃取场景;NIST CSF 2.0:PR.PS-01、PR.IR-01、ID.AM-08、DE.CM-01,覆盖最小特权、安全数据访问、资产清单与持续监控等控制域。这给出了审计日志检测规则 → ATTCK 技术的落地示例:例如 2.2 节的 Secret 访问规则可标注 T1552.007,2.3 节的 ClusterRoleBinding 写操作规则可标注 T1078。仓库的 mappings/mitre-attack 目录维护了全库技能与 ATTCK 技术的映射汇总,可作为编写检测规则元数据时的参照格式。同时,SKILL.md 的 When to Use 段落明确了这套分析的适用场景:调查需要 Kubernetes 审计日志的安全事件、为容器域构建检测规则或威胁狩猎查询、为 SOC 分析师提供结构化分析流程,以及验证与相关攻击技术对应的监控覆盖度。其前置条件要求 Python 3.8 与一个安全的测试环境。6. 落地建议与适用前提先确认审计级别再部署规则:部署 2.4 节特权 Pod 检测前,必须验证审计策略对相关规则达到了Request级别以上,否则requestObject字段不存在,规则空转;严重度分级可直接复用:agent.py 中的分级策略(execHIGH、list/delete secretHIGH、cluster 级 RBACCRITICAL、成功匿名访问CRITICAL)是一套可直接移植到 SIEM 的基线;规则要带结果码过滤:参照匿名访问检测中status_code 400的写法,区分被拒绝的探测与成功的越权,可显著降低误报;频率维度补充单点规则:单次get secret可能是正常操作,应叠加同用户 403 激增(默认阈值 20 次)与Secret get 频次等聚合维度;字段取值全部防御式:不同审计级别下字段可缺失,统一使用event.get(objectRef, {}).get(resource)风格取值;注意合规边界:本仓库为 Apache-2.0 许可的社区安全技能库,相关分析仅应在自有集群或获得明确授权的环境中进行。7. 仓库内延伸阅读技能主文档与使用前提:SKILL.md完整检测实现:scripts/agent.py(约 200 行,含全部六个检测函数与 CLI 入口)API 参考原文:references/api-reference.md(事件样例、关键事件表、审计级别表)技能许可:LICENSE审计日志是 Kubernetes 集群中唯一不可抵赖的行为记录源:谁、在何时、从哪个 IP、以什么身份、对什么资源做了什么,全部落在 API Server 的 JSON Lines 里。掌握第 1 节的字段语义、第 2 节的五类关键事件特征与第 3 节的级别约束,再配合 agent.py 的完整实现,即可构建起一套可审计、可移植、可映射到 ATTCK 的容器集群检测基线。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考