AI Agent 运维的审计与合规体系：从日志设计到 DORA/SLSA 合规实战

![[Gemini_Generated_Image_cl7unacl7unacl7u.png]]

🔥 一句话理解

AI Agent 不会因为你"相信它"而值得被信任——审计日志，是 AI 运维从"信仰"走向"证据"的唯一路径。

🎯 本文产出

• AI Agent 双层审计架构（应用层 + K8s 层通过 audit_id 关联，附时序图）
• 审计日志 JSON Schema（可直接集成到 Tool 调用装饰器）
• ELK 管道核心配置（Filebeat + Logstash + ILM 策略，含关键参数决策逻辑）
• DORA 合规技术映射表（Article → K8s 控制 → 验证方法，含 2025 年执行案例）
• SLSA L2 实施路径（cosign + Tekton Chains + Witness，含 SBOM 误区分析）
• 审计证明包生成器代码（in-toto 格式，集成到 AI Agent Tool 层）

💰 商业价值

读完本文，你可以在 3 天内搭建完整的 AI Agent 审计合规基础设施：审计日志记录器集成到每个 Tool 调用（1天）、ELK 管道与看板（1天）、DORA/SLSA 合规证据链自动化（1天）。节省团队 15-20 人天的摸索成本，规避 DORA 法规下最高全球年营业额 2% 的合规罚款风险。

一、一个真实的审计噩梦，从凌晨 3 点开始

2026 年 3 月某日凌晨 3:17，你们的 AI 运维 Agent 检测到 payment 服务的 P99 延迟飙升至 8 秒，自动判断为 P2 级别，触发了"重启 Deployment"操作。重启成功，延迟恢复正常。

早上 9 点，财务团队发现凌晨 3:17 到 3:31 之间有 14 分钟的交易中断，损失金额约 23 万元。

接下来是噩梦的开始：

你无法回答以下任何一个问题。

• AI Agent 当时看到了什么监控数据，才决定重启？
• 重启前它有没有尝试其他方案？
• 是哪个服务账号发起的 K8s 操作？
• 这个操作有没有经过审批，审批记录在哪？
• 这 14 分钟里，K8s 实际执行了哪些 API 调用？

监管机构的问询邮件在下午 2 点到达。

这不是假设的场景——它是 AI Agent 在没有完整审计基础设施的情况下运行的必然结局。

这就是审计是 AI Agent 安全治理最后一块拼图的真正原因： 不是因为监管要求，而是因为当你把操作权限交给 AI 时，"出了事能复盘"是你唯一的安全网。

AI Agent 审计的本质差异

人工运维的每步操作都有一个"在场的人"：操作者知道自己做了什么，为什么这样做，当时看到了什么。

AI Agent 的操作是一串自动执行的代码链。没有"在场者"，只有日志。

这带来了一个根本不同：人工运维的审计是事后补充，AI 运维的审计必须是实时织入。 事后补日志这件事，AI Agent 做不到——它没有记忆，没有意识，也没有动机去解释自己的决策。你只能在设计阶段，把审计能力嵌入到每一次 Tool 调用里。

监管视角： "出故障不可怕，复盘时找不到原因才可怕"
工程师视角： "不是不信任 AI，是出了事我需要证据证明不是自己的锅"
管理者视角： "DORA 2025 年生效，不合规罚款可达年营收 2%"

本章要解决的就是这三个视角的交叉点，用四个具体问题作为索引：

二、双层审计架构：AI Agent 的审计设计原点

这是本章最核心的设计。理解这个架构，其余所有配置都是它的延伸。

2.1 为什么需要两层？

K8s 原生审计记录了"谁对什么资源做了什么操作"，但它不知道"AI 为什么要做这个操作"。

应用层的 AI Agent 日志记录了"AI 的推理链和决策过程"，但它不知道"K8s 实际执行了哪些 API 调用"。

两层日志单独存在都是残缺的。 双层审计架构通过一个共享的 audit_id，把"AI 的思维链"和"K8s 的操作链"关联成一条完整的证据链。

审计管道（ELK）

K8s API Server

AI Agent（应用层）

用户

审计管道（ELK）

K8s API Server

AI Agent（应用层）

用户

#mermaid-svg-AlF3u9IeMWGpViJ1{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-AlF3u9IeMWGpViJ1 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-AlF3u9IeMWGpViJ1 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-AlF3u9IeMWGpViJ1 .error-icon{fill:#552222;}#mermaid-svg-AlF3u9IeMWGpViJ1 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-AlF3u9IeMWGpViJ1 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-AlF3u9IeMWGpViJ1 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-AlF3u9IeMWGpViJ1 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-AlF3u9IeMWGpViJ1 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-AlF3u9IeMWGpViJ1 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-AlF3u9IeMWGpViJ1 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-AlF3u9IeMWGpViJ1 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-AlF3u9IeMWGpViJ1 .marker.cross{stroke:#333333;}#mermaid-svg-AlF3u9IeMWGpViJ1 svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-AlF3u9IeMWGpViJ1 p{margin:0;}#mermaid-svg-AlF3u9IeMWGpViJ1 .actor{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-AlF3u9IeMWGpViJ1 text.actor>tspan{fill:black;stroke:none;}#mermaid-svg-AlF3u9IeMWGpViJ1 .actor-line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-AlF3u9IeMWGpViJ1 .innerArc{stroke-width:1.5;stroke-dasharray:none;}#mermaid-svg-AlF3u9IeMWGpViJ1 .messageLine0{stroke-width:1.5;stroke-dasharray:none;stroke:#333;}#mermaid-svg-AlF3u9IeMWGpViJ1 .messageLine1{stroke-width:1.5;stroke-dasharray:2,2;stroke:#333;}#mermaid-svg-AlF3u9IeMWGpViJ1 #arrowhead path{fill:#333;stroke:#333;}#mermaid-svg-AlF3u9IeMWGpViJ1 .sequenceNumber{fill:white;}#mermaid-svg-AlF3u9IeMWGpViJ1 #sequencenumber{fill:#333;}#mermaid-svg-AlF3u9IeMWGpViJ1 #crosshead path{fill:#333;stroke:#333;}#mermaid-svg-AlF3u9IeMWGpViJ1 .messageText{fill:#333;stroke:none;}#mermaid-svg-AlF3u9IeMWGpViJ1 .labelBox{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-AlF3u9IeMWGpViJ1 .labelText,#mermaid-svg-AlF3u9IeMWGpViJ1 .labelText>tspan{fill:black;stroke:none;}#mermaid-svg-AlF3u9IeMWGpViJ1 .loopText,#mermaid-svg-AlF3u9IeMWGpViJ1 .loopText>tspan{fill:black;stroke:none;}#mermaid-svg-AlF3u9IeMWGpViJ1 .loopLine{stroke-width:2px;stroke-dasharray:2,2;stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-AlF3u9IeMWGpViJ1 .note{stroke:#aaaa33;fill:#fff5ad;}#mermaid-svg-AlF3u9IeMWGpViJ1 .noteText,#mermaid-svg-AlF3u9IeMWGpViJ1 .noteText>tspan{fill:black;stroke:none;}#mermaid-svg-AlF3u9IeMWGpViJ1 .activation0{fill:#f4f4f4;stroke:#666;}#mermaid-svg-AlF3u9IeMWGpViJ1 .activation1{fill:#f4f4f4;stroke:#666;}#mermaid-svg-AlF3u9IeMWGpViJ1 .activation2{fill:#f4f4f4;stroke:#666;}#mermaid-svg-AlF3u9IeMWGpViJ1 .actorPopupMenu{position:absolute;}#mermaid-svg-AlF3u9IeMWGpViJ1 .actorPopupMenuPanel{position:absolute;fill:#ECECFF;box-shadow:0px 8px 16px 0px rgba(0,0,0,0.2);filter:drop-shadow(3px 5px 2px rgb(0 0 0 / 0.4));}#mermaid-svg-AlF3u9IeMWGpViJ1 .actor-man line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-AlF3u9IeMWGpViJ1 .actor-man circle,#mermaid-svg-AlF3u9IeMWGpViJ1 line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;stroke-width:2px;}#mermaid-svg-AlF3u9IeMWGpViJ1 :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

生成 audit_id: aud_20260516_001

生成 audit_id: aud_20260516_002

risk_level: P2 → 触发审批流

Kibana 查询

audit_id = 'aud_001'

↓ 还原完整决策链

· AI 看到了 OOMKilled

· 发起了哪些 K8s 调用

· 最终做了什么决定

"排查 payment 服务重启原因"

审计记录①

tool: get_pod_status

audit_id: aud_001

risk_level: P3

reason: P99 latency 8s

kubectl get pods -n prod

Header: X-Audit-ID: aud_001

K8s Audit Log

user: ai-agent

resource: pods

verb: get

X-Audit-ID: aud_001

审计记录②

tool: get_pod_logs

audit_id: aud_001

result: OOMKilled found

"重启 payment 服务"

审计记录③

tool: restart_deployment

audit_id: aud_002

approval_id: apr_789

status: pending_approval

这个时序图揭示了双层审计的关键设计模式：

每次 Tool 调用生成一个唯一 audit_id，通过 HTTP Header 传递给 K8s API。在 ELK 中通过 audit_id 做 JOIN，就能同时看到"AI 的推理依据"和"K8s 的实际执行"——这两层加在一起，才能回答凌晨 3 点那个场景里的所有问题。

2.2 审计日志 Schema 设计

Schema 设计是架构落地的基础。每个字段的存在都有明确的审计目的：

{
"audit_id": "aud_20260516_001_a1b2c3d4",
"timestamp": "2026-05-16T19:30:00.123Z",
"operator": {
"type": "ai-agent",
"name": "hermes-agent",
"version": "0.5.2",
"session_id": "sess_abc123",
"user_id": "user_liuzhupeng"
},
"operation": {
"tool": "get_pod_status",
"action": "query",
"reason": "P99 latency exceeded 8000ms, investigating root cause",
"parameters": {
"namespace": "production",
"pod_name": "payment-7d8f9"
}
},
"resource": {
"type": "pod",
"name": "payment-7d8f9",
"namespace": "production",
"cluster": "prod-k8s-01"
},
"security": {
"risk_level": "P3",
"approval_id": null,
"dry_run": false
},
"result": {
"status": "success",
"duration_ms": 1234,
"error_message": null
},
"audit_trail": {
"k8s_audit_ids": ["k8s_audit_20260516_001_001"],
"provenance_link": null
}
}

关键字段设计意图：

2.3 审计记录器集成（核心实现）

审计能力要织入每一次 Tool 调用，最干净的方式是装饰器模式：

class AuditLogger:
"""AI Agent 审计日志记录器"""

def log_tool_call(self, tool_func):
"""装饰器：自动记录每次 Tool 调用"""
@wraps(tool_func)
def wrapper(*args, **kwargs):
audit_id = self._generate_audit_id()
start_time = datetime.datetime.utcnow()

# 注入 audit_id 到调用上下文
kwargs["_audit_id"] = audit_id

entry = {
"audit_id": audit_id,
"timestamp": start_time.isoformat() + "Z",
"operation": {
"tool": tool_func.__name__,
"reason": kwargs.pop("_reason", "not specified"),
"parameters": self._safe_params(kwargs)
},
"status": "in_progress"
}
self._send_async(entry)

try:
result = tool_func(*args, **kwargs)
entry["status"] = "completed"
entry["result"] = {
"success": True,
"duration_ms": (datetime.datetime.utcnow() – start_time).total_seconds() * 1000
}
self._send_async(entry)
return result
except Exception as e:
entry["status"] = "failed"
entry["result"] = {"success": False, "error": str(e)}
self._send_async(entry)
raise

return wrapper

# 使用方式
audit = AuditLogger(elk_endpoint="…", signing_key=os.environ["AUDIT_SIGNING_KEY"])

@audit.log_tool_call
def restart_deployment(namespace: str, deployment: str, _audit_id: str = None):
"""重启 Deployment，_audit_id 由装饰器自动注入并传递给 kubectl"""
return run_kubectl(
["rollout", "restart", f"deployment/{deployment}", "-n", namespace],
extra_headers={"X-Audit-ID": _audit_id}
)

装饰器模式的核心价值是零侵入：已有的所有 Tool 函数只需加一行 @audit.log_tool_call，审计就自动覆盖。不需要在每个函数里手动写日志逻辑。

三、K8s 审计策略：双层架构的基础设施底座

应用层审计解决了"AI 的推理链"，K8s 层审计解决了"操作是否真的执行了"。两层缺一不可。

⚠️ 很多团队的第一道审计是空的： 大多数托管 K8s 集群（如 EKS、AKS、GKE）默认审计策略为 None。这意味着集群跑了几个月，一旦发生安全事故，你拿不出任何合规证据。开启审计策略不是可选项，是合规基线。

3.1 四个审计级别的本质权衡

K8s 定义了四个审计级别，选择不当会带来两种对称的灾难：

过低（None/Metadata）：审计记录里看不到变更内容，Secret 被改了什么值，RBAC 增加了什么权限——这些关键信息全部丢失。

过高（RequestResponse）：每日存储 TB 级，API Server 内存和 CPU 明显上升，更严重的是，存了太多数据等于没存，查询性能让日志形同虚设。

隐性知识：多数人认为"开启审计会显著降低 API Server 性能"。实测在 Metadata 级别、1000 QPS 集群中，内存增长不超过 200MB，CPU 增长不超过 5%。真正消耗资源的是 RequestResponse 级别——而绝大多数场景根本不需要它。

一个值得记住的换算公式： API Server 每接收 100 QPS 的请求，审计日志生成速率约为 200 事件/秒（每个请求触发 RequestReceived 和 ResponseComplete 两个事件）。1000 QPS 的集群每天产生约 1.73 亿条审计事件——理解了这几个数字，你才能做出合理的 ILM 配置和存储规划。

3.2 混合策略：生产环境的正确答案

单一级别无法兼顾完整性和性能。混合策略是唯一实用的选择：

# audit-policy.yaml — 生产级混合审计策略
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# 第一层：屏蔽高频噪声（降低 60-70% 事件量）
– level: None
verbs: ["get", "watch", "list"]
resources:
group: ""
resources: ["events", "healthz", "livez", "readyz"]

# 第二层：敏感资源全量记录（必须看到"改了什么"）
– level: Request
resources:
– group: ""
resources: ["secrets", "configmaps"]
– group: "rbac.authorization.k8s.io"
resources: ["roles", "clusterroles", "rolebindings", "clusterrolebindings"]

# 第三层：变更操作记录元数据（平衡可见性与成本）
– level: Metadata
verbs: ["create", "update", "patch", "delete"]
resources:
– group: ""
resources: ["pods", "deployments", "services", "namespaces"]

# 兜底：Metadata（保证任何漏网操作也有记录）
– level: Metadata
omitStages:
– "RequestReceived" # 跳过请求接收阶段，减少约 50% 事件量

这三层过滤在 1000 QPS 集群中，将审计事件从全量 RequestResponse 的 2000 条/秒压缩到约 300 条/秒，存储从 TB 级/日降到 GB 级/日。

3.3 Webhook 后端：为什么不用本地日志文件

本地日志文件有两个致命问题：节点重启时日志丢失，以及日志文件可以被有权限的 Pod 修改——这违反了审计日志"不可篡改"的基本要求。

生产环境必须用 Webhook 后端，将审计日志发送到独立的 Logstash 进行集中存储：

# kube-apiserver 关键启动参数
––audit–policy–file=/etc/kubernetes/audit–policy.yaml
––audit–webhook–config–file=/etc/kubernetes/audit–webhook.yaml
––audit–webhook–batch–max–size=400 # 每批最多 400 条
––audit–webhook–batch–max–wait=30s # 最多等待 30 秒
––audit–webhook–initial–backoff=10s # 首次失败后等待 10 秒重试

K8s 1.28+ 默认 batch-max-wait 为 30 秒。如果 Webhook 后端写入延迟超过 5 秒，建议将缓冲区调整到至少容纳 5 秒事件量，否则高峰期事件会在内存中积压触发 OOM。

四、ELK 管道：把审计日志变成可查询的资产

一个检验标准： 能不能在 30 秒内回答"昨晚 11 点，AI Agent 对 production namespace 做了哪些操作"？如果不能，你的审计日志是存储成本，不是审计资产。

4.1 管道架构全貌

#mermaid-svg-ERhCQ56l2jtmBjo2{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-ERhCQ56l2jtmBjo2 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-ERhCQ56l2jtmBjo2 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-ERhCQ56l2jtmBjo2 .error-icon{fill:#552222;}#mermaid-svg-ERhCQ56l2jtmBjo2 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-ERhCQ56l2jtmBjo2 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-ERhCQ56l2jtmBjo2 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-ERhCQ56l2jtmBjo2 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-ERhCQ56l2jtmBjo2 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-ERhCQ56l2jtmBjo2 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-ERhCQ56l2jtmBjo2 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-ERhCQ56l2jtmBjo2 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-ERhCQ56l2jtmBjo2 .marker.cross{stroke:#333333;}#mermaid-svg-ERhCQ56l2jtmBjo2 svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-ERhCQ56l2jtmBjo2 p{margin:0;}#mermaid-svg-ERhCQ56l2jtmBjo2 .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-ERhCQ56l2jtmBjo2 .cluster-label text{fill:#333;}#mermaid-svg-ERhCQ56l2jtmBjo2 .cluster-label span{color:#333;}#mermaid-svg-ERhCQ56l2jtmBjo2 .cluster-label span p{background-color:transparent;}#mermaid-svg-ERhCQ56l2jtmBjo2 .label text,#mermaid-svg-ERhCQ56l2jtmBjo2 span{fill:#333;color:#333;}#mermaid-svg-ERhCQ56l2jtmBjo2 .node rect,#mermaid-svg-ERhCQ56l2jtmBjo2 .node circle,#mermaid-svg-ERhCQ56l2jtmBjo2 .node ellipse,#mermaid-svg-ERhCQ56l2jtmBjo2 .node polygon,#mermaid-svg-ERhCQ56l2jtmBjo2 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-ERhCQ56l2jtmBjo2 .rough-node .label text,#mermaid-svg-ERhCQ56l2jtmBjo2 .node .label text,#mermaid-svg-ERhCQ56l2jtmBjo2 .image-shape .label,#mermaid-svg-ERhCQ56l2jtmBjo2 .icon-shape .label{text-anchor:middle;}#mermaid-svg-ERhCQ56l2jtmBjo2 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-ERhCQ56l2jtmBjo2 .rough-node .label,#mermaid-svg-ERhCQ56l2jtmBjo2 .node .label,#mermaid-svg-ERhCQ56l2jtmBjo2 .image-shape .label,#mermaid-svg-ERhCQ56l2jtmBjo2 .icon-shape .label{text-align:center;}#mermaid-svg-ERhCQ56l2jtmBjo2 .node.clickable{cursor:pointer;}#mermaid-svg-ERhCQ56l2jtmBjo2 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-ERhCQ56l2jtmBjo2 .arrowheadPath{fill:#333333;}#mermaid-svg-ERhCQ56l2jtmBjo2 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-ERhCQ56l2jtmBjo2 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-ERhCQ56l2jtmBjo2 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-ERhCQ56l2jtmBjo2 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-ERhCQ56l2jtmBjo2 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-ERhCQ56l2jtmBjo2 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-ERhCQ56l2jtmBjo2 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-ERhCQ56l2jtmBjo2 .cluster text{fill:#333;}#mermaid-svg-ERhCQ56l2jtmBjo2 .cluster span{color:#333;}#mermaid-svg-ERhCQ56l2jtmBjo2 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-ERhCQ56l2jtmBjo2 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-ERhCQ56l2jtmBjo2 rect.text{fill:none;stroke-width:0;}#mermaid-svg-ERhCQ56l2jtmBjo2 .icon-shape,#mermaid-svg-ERhCQ56l2jtmBjo2 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-ERhCQ56l2jtmBjo2 .icon-shape p,#mermaid-svg-ERhCQ56l2jtmBjo2 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-ERhCQ56l2jtmBjo2 .icon-shape .label rect,#mermaid-svg-ERhCQ56l2jtmBjo2 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-ERhCQ56l2jtmBjo2 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-ERhCQ56l2jtmBjo2 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-ERhCQ56l2jtmBjo2 :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

应用层AI Agent 日志

FilebeatDaemonSet

K8s AuditWebhook

Logstash解析 / 脱敏

Elasticsearch+ ILM 策略

Kibana审计看板

归档存储Cold 快照

4.2 Filebeat：采集层的三个关键参数

Filebeat 作为日志采集入口，三个参数决定了吞吐量和稳定性：

一个常见踩坑：未配置 queue.mem.events（内存队列大小），在日志突发高峰时 Filebeat 直接 OOM 而不是优雅地触发背压。推荐同时设置 queue.mem.events: 4096 和 queue.mem.flush.min_events: 2048，让缓冲区有足够空间吸收峰值流量。

4.3 Logstash 管道：脱敏是审计合规的刚性要求

Logstash 最重要的职责不是解析，而是脱敏。审计日志如果包含明文 Secret 内容，它本身就变成了安全漏洞。

核心配置逻辑：解析 JSON → 提取元数据 → 对敏感资源的请求体做脱敏替换 → 写入 ES。

敏感字段脱敏规则：所有 secrets 和 configmaps 的 requestObject 字段，替换为 [REDACTED]，并记录脱敏操作本身（谁在什么时候访问了什么 Secret，即使内容不可见，访问记录保留）。

4.4 ILM 策略：防止"分片爆炸"的必要防线

这是一个在 3-6 个月内必然触发的灾难： 未配置 ILM 的 ES 集群，每天产生一个新索引带 2-5 个分片，一年后累计 1000+ 分片，集群 Master 节点 CPU 被分片管理耗尽，查询响应时间从毫秒级退化到分钟级。

四个生命周期阶段的核心逻辑：

Hot（0-30 天）：高频查询优先，2 分片/2 副本，按 50GB 或 30 天触发 rollover。注意：不要在 Hot 阶段就降为 1 副本——看似节省资源，但跨天范围查询会触发 Scatter/Gather，30 天的数据要发起 30 次分片请求，查询变慢。

Warm（30-90 天）：合并为 1 分片、1 副本，强制 merge 到 1 个 Segment。这是成本和可用性的平衡点。

Cold（90-180 天）：转为 Searchable Snapshot，数据存在对象存储，只有需要时才加载到内存。存储成本降低 80%，检索延迟略有上升（可接受）。

Delete（>180 天）：自动清理。DORA 要求审计轨迹安全保留 5 年——如果需要更长的合规保留期，在 Cold 阶段前增加 Frozen 阶段，将历史数据迁移到对象存储长期归档。

4.5 Kibana 审计看板：4 个核心视图

五、DORA 合规：2025 年已经在执行的监管新规

5.1 DORA 是什么，为什么你现在就要认真对待

DORA（EU 2022/2554，Digital Operational Resilience Act）2025 年 1 月 17 日起全面生效。它的核心主张用一句话概括：你的 IT 系统不仅要能正常工作，还要能在任何故障中证明自己能继续正常工作。

监管边界比多数人想象的宽：任何为欧盟金融机构提供 ICT 服务的平台都在管辖范围内——包括云基础设施提供商、SaaS 供应商、甚至 K8s 托管平台服务。

2025 年已知执行案例（不是未来预测，是已发生的事）：

某欧盟成员国监管机构对未在 4 月截止日前提交信息登记册（Register of Information）的金融机构发出强制金（Compulsion Payment）——这是日罚款机制，每延误一天累计计算。

某金融机构遭受影响 5 万客户的网络攻击，但未能在 4 小时内完成初步报告。潜在处罚：全球年营业额 1-2%。

某大型投资公司未对关键系统执行威胁主导渗透测试（TLPT），处罚结果：重大财务处罚 + 90 天整改令。

DORA 还引入了高管个人责任：因 ICT 风险管理疏忽导致不合规的高管，面临最高 100 万欧元的个人罚款。这不是公司层面的罚款，是个人层面的。

另一个容易被忽视的主体是第三方 ICT 服务商——如果你运营的 K8s 平台向欧盟金融机构提供服务，你也在 DORA 的管辖范围内。关键 ICT 第三方服务商的罚款上限为 500 万欧元，同时监管机构有权禁止该服务商向金融机构提供服务——对 SaaS 和云服务商来说，这是致命的业务冲击。

5.2 DORA 五支柱与 K8s 技术控制映射

#mermaid-svg-35rdYRnHLx7TeQVY{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-35rdYRnHLx7TeQVY .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-35rdYRnHLx7TeQVY .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-35rdYRnHLx7TeQVY .error-icon{fill:#552222;}#mermaid-svg-35rdYRnHLx7TeQVY .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-35rdYRnHLx7TeQVY .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-35rdYRnHLx7TeQVY .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-35rdYRnHLx7TeQVY .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-35rdYRnHLx7TeQVY .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-35rdYRnHLx7TeQVY .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-35rdYRnHLx7TeQVY .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-35rdYRnHLx7TeQVY .marker{fill:#333333;stroke:#333333;}#mermaid-svg-35rdYRnHLx7TeQVY .marker.cross{stroke:#333333;}#mermaid-svg-35rdYRnHLx7TeQVY svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-35rdYRnHLx7TeQVY p{margin:0;}#mermaid-svg-35rdYRnHLx7TeQVY .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-35rdYRnHLx7TeQVY .cluster-label text{fill:#333;}#mermaid-svg-35rdYRnHLx7TeQVY .cluster-label span{color:#333;}#mermaid-svg-35rdYRnHLx7TeQVY .cluster-label span p{background-color:transparent;}#mermaid-svg-35rdYRnHLx7TeQVY .label text,#mermaid-svg-35rdYRnHLx7TeQVY span{fill:#333;color:#333;}#mermaid-svg-35rdYRnHLx7TeQVY .node rect,#mermaid-svg-35rdYRnHLx7TeQVY .node circle,#mermaid-svg-35rdYRnHLx7TeQVY .node ellipse,#mermaid-svg-35rdYRnHLx7TeQVY .node polygon,#mermaid-svg-35rdYRnHLx7TeQVY .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-35rdYRnHLx7TeQVY .rough-node .label text,#mermaid-svg-35rdYRnHLx7TeQVY .node .label text,#mermaid-svg-35rdYRnHLx7TeQVY .image-shape .label,#mermaid-svg-35rdYRnHLx7TeQVY .icon-shape .label{text-anchor:middle;}#mermaid-svg-35rdYRnHLx7TeQVY .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-35rdYRnHLx7TeQVY .rough-node .label,#mermaid-svg-35rdYRnHLx7TeQVY .node .label,#mermaid-svg-35rdYRnHLx7TeQVY .image-shape .label,#mermaid-svg-35rdYRnHLx7TeQVY .icon-shape .label{text-align:center;}#mermaid-svg-35rdYRnHLx7TeQVY .node.clickable{cursor:pointer;}#mermaid-svg-35rdYRnHLx7TeQVY .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-35rdYRnHLx7TeQVY .arrowheadPath{fill:#333333;}#mermaid-svg-35rdYRnHLx7TeQVY .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-35rdYRnHLx7TeQVY .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-35rdYRnHLx7TeQVY .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-35rdYRnHLx7TeQVY .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-35rdYRnHLx7TeQVY .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-35rdYRnHLx7TeQVY .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-35rdYRnHLx7TeQVY .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-35rdYRnHLx7TeQVY .cluster text{fill:#333;}#mermaid-svg-35rdYRnHLx7TeQVY .cluster span{color:#333;}#mermaid-svg-35rdYRnHLx7TeQVY div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-35rdYRnHLx7TeQVY .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-35rdYRnHLx7TeQVY rect.text{fill:none;stroke-width:0;}#mermaid-svg-35rdYRnHLx7TeQVY .icon-shape,#mermaid-svg-35rdYRnHLx7TeQVY .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-35rdYRnHLx7TeQVY .icon-shape p,#mermaid-svg-35rdYRnHLx7TeQVY .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-35rdYRnHLx7TeQVY .icon-shape .label rect,#mermaid-svg-35rdYRnHLx7TeQVY .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-35rdYRnHLx7TeQVY .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-35rdYRnHLx7TeQVY .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-35rdYRnHLx7TeQVY :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

支柱1ICT风险管理Art.5-14

K8s RBAC+ Audit Policy

支柱2事件报告Art.17-23

ELK 告警4小时报告

支柱3韧性测试Art.24-27

NetworkPolicy+ Falco

支柱4第三方风险Art.28-30

Operator+ SBOM

支柱5信息共享Art.31-34

MISP威胁情报

Article → K8s 技术控制的详细映射（合规审计的核心交付物）：

5.3 DORA 事件报告的时间窗口（最容易触发处罚的条款）

4 小时初步报告是最严格也最常被违反的要求。手动流程在 4 小时内完成报告几乎不可能——必须自动化：

5.4 DORA 合规技术检查清单

□ K8s 审计日志全量启用（混合策略，保留 ≥5 年，满足 DORA 长期要求）
□ RBAC 最小权限原则（定期审计 + OPA 策略门禁）
□ 容器镜像签名验证（cosign，锁定 Digest 而非 Tag）
□ Secret 轮换策略（最短 90 天，自动化 CronJob）
□ NetworkPolicy 零信任（默认拒绝，跨 Namespace 白名单）
□ PDB 配置覆盖所有关键服务
□ 备份恢复演练（每季度至少一次，生成演练报告）
□ 事件响应 Playbook（PodCrashLooping/OOMKilled/NodeNotReady/网络分区）
□ 第三方组件 SBOM 管理（自动生成 + 漏洞扫描）
□ 日志完整性校验（Hash 链或签名，防止事后篡改）
□ 4 小时初步报告自动化（模板 + 触发机制）
□ 高管个人问责文档化（ICT 风险管理责任矩阵）

六、SLSA 供应链安全：从"信任产物"到"信任过程"

DORA 关注运营韧性（系统能不能扛住故障），SLSA 关注供应链安全（代码有没有被篡改）。两者互补，构成"运行时信任 + 构建时信任"的双保险。

6.1 SLSA 等级：理解本质，而不是背标准

L2 是大多数生产环境的最优起点——安全收益最高，实施成本可控。

6.2 SBOM ≠ 供应链安全（价值 100 万的误区）

在展开 L2 实施路径之前，必须先破除这个误区。

**SolarWinds 攻击（2020）**是最好的反例：攻击者不是修改了代码，而是在构建系统本身植入了恶意代码。最终的 SolarWinds.Orion.Core.BusinessLayer.dll 在 SBOM 里是完全合法的组件——因为它确实来自合法的构建产物，只是构建过程被污染了。SBOM 显示一切正常，但系统已经沦陷。

**GhostAction 攻击（2025）**是供应链安全的最新警钟：攻击者通过篡改 GitHub Actions Marketplace 上流行 Action 的 Tag 引用（如 @v1），在不改动代码仓库的情况下向所有使用该 Action（Tag 而非 Commit SHA 引用）的 CI 管道注入了恶意脚本。本质和 SolarWinds 一样——不是改产物，而是污染构建过程。教训很简单：CI/CD 中永远不要用 Tag 引用 Action，必须锁定为 Commit SHA。

正确的分层认知：

SLSA 的核心价值是：把信任从"相信产物"转移到"相信过程"。

6.3 L2 实施路径：三个组件，1-2 天落地

根据行业实测数据，SLSA L2 的托管构建 + 签名验证两大核心要求，大多数已有 CI/CD 管道的团队可在 1-2 个工作日内完成——成本远低于多数人的预期。实现 L2 只需要三个组件：

锁定 Digest 而不是 Tag——这是镜像签名的第一性原理。Tag 可以被覆盖（latest 今天指向 v1.2.3，明天可能指向 v1.2.4），Digest 是内容的 SHA256 哈希，内容变了 Digest 必然变。

# 对镜像签名（集成在 CI/CD 流水线中）
cosign sign –key cosign.key ghcr.io/myorg/app@sha256:abc123...

# 部署前验证（集成在 OPA/Kyverno 准入策略中）
cosign verify –key cosign.pub ghcr.io/myorg/app@sha256:abc123...

组件二：Tekton Chains 自动生成构建证明（Provenance）

证明不是日志，是加密签名的构建元数据。它回答：“这个镜像，是什么人，在什么时间，用什么代码，在什么环境里构建的。”

Tekton Chains 的核心配置是两行：指定存储后端（OCI Registry），指定输出格式（in-toto）。其余都由 Chains 自动完成——每次 TaskRun 完成后，自动生成证明并上传到指定 Registry。

组件三：Witness 自动化证明捕获

Witness 把 CI/CD 的每一步都变成 in-toto Link 元数据，形成一条从代码提交到镜像推送的完整证据链。每个步骤都有加密签名，任何一步被篡改，整条链的签名验证就会失败。

6.4 in-toto 审计证明包：给 AI Agent 操作链盖戳

in-toto 是 SLSA 底层的元数据标准，在 AI Agent 运维场景中有独特价值：

• AI Agent 执行每个 Tool 操作时，生成一个 in-toto Link，记录操作内容、时间戳、审批 ID
• 周期性打包为 Attestation，加密签名
• 作为不可篡改的合规证据，满足 DORA 对"完整且不可篡改审计痕迹"的要求

关键在于不可篡改性：HMAC-SHA256 签名保证了日志写入后无法被修改——这是普通 ES 日志做不到的。如果监管机构要求提供"原始未修改的审计记录"，加密签名的 in-toto 证明包是唯一可信的答案。

一个你可能关心的性能问题： 生成 in-toto 证明的开销是多少？实测数据是平均 0.38 秒，且不随工作负载大小变化。这意味着在每个 Tool 调用后附加一个 in-toto Link 生成，对 AI Agent 的响应延迟影响可以忽略不计。

class AuditAttestationGenerator:
"""生成 in-toto 格式的审计证明"""

def create_link_metadata(self, tool_name, params, result, approval_id=None):
safe_params = self._redact_sensitive(params)

link = {
"_type": "https://in-toto.io/Statement/v1",
"predicateType": "https://slsa.dev/provenance/v1",
"subject": [{
"name": f"audit:{tool_name}",
"digest": {"sha256": hashlib.sha256(
json.dumps(safe_params, sort_keys=True).encode()
).hexdigest()}
}],
"predicate": {
"buildDefinition": {
"buildType": f"ai-agent/tool/{tool_name}",
"externalParameters": safe_params,
"internalParameters": {"approval_id": approval_id}
},
"runDetails": {
"metadata": {
"invocationId": self._generate_audit_id(),
"startedOn": datetime.datetime.utcnow().isoformat() + "Z"
}
}
}
}
link["signature"] = self._sign(link)
return link

def _redact_sensitive(self, params):
SENSITIVE = ["password", "token", "key", "secret"]
return {k: "[REDACTED]" if any(s in k.lower() for s in SENSITIVE) else v
for k, v in params.items()}

def _sign(self, data):
payload = json.dumps(data, sort_keys=True)
return hmac.new(
self.signing_key.encode(), payload.encode(), hashlib.sha256
).hexdigest()

七、合规审计现场还原：从凌晨 3 点的事故回到证据链

让我们回到开篇的场景，用本章构建的审计体系重新走一遍。

监管机构要求提供： 凌晨 3:17 到 3:31，AI Agent 的完整操作记录，含决策依据、操作授权、K8s API 调用链。

有了双层审计架构，你可以这样回答：

第一步：Kibana 查询

audit_id: "aud_20260316_031700_*" AND timestamp: [2026-03-16T03:00:00 TO 2026-03-16T04:00:00]

30 秒内，拿到完整的应用层审计记录：

• 03:17:02 AI Agent 检测到 payment P99 = 8234ms，发起 get_pod_status
• 03:17:05 查询结果：3 个 Pod 中 2 个处于 OOMKilled 状态
• 03:17:08 AI 判断根因为内存不足，触发 restart_deployment，风险等级 P2
• 03:17:08 审批流触发，等待系统自动审批（P2 级别）
• 03:17:12 审批通过（approval_id: apr_20260316_031712），执行重启
• 03:31:45 payment 服务恢复正常，P99 回落至 120ms

第二步：K8s 审计日志关联

用 audit_trail.k8s_audit_ids 在 K8s 审计索引里 JOIN：

• 03:17:12 patch on deployments/payment in namespace production
• 操作账号：serviceaccount/hermes-agent，匹配预期
• 操作节点：所有变更都有对应的 Rollout 事件

第三步：in-toto 证明包验证

拉取 aud_20260316_031712 对应的 Attestation，验证签名。签名有效，证明记录未被修改。

你能回答监管机构的全部问题。这就是审计体系的价值。

八、总结：审计即信任，合规即能力

取舍的本质： 审计和合规是预防性成本——不直接带来业务收益，但不做的代价远大于做的成本。DORA 罚款 2% 年营业额 vs ELK 管道搭建 3 天，这个账一算就清楚了。

最小可行审计（资源有限时的优先顺序）：

这三步覆盖了"有审计能力"的最低要求。DORA/SLSA 的完整合规在这个基础上逐步叠加。

架构演进路径：

#mermaid-svg-QhaC0EktjkJbtVZC{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-QhaC0EktjkJbtVZC .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-QhaC0EktjkJbtVZC .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-QhaC0EktjkJbtVZC .error-icon{fill:#552222;}#mermaid-svg-QhaC0EktjkJbtVZC .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-QhaC0EktjkJbtVZC .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-QhaC0EktjkJbtVZC .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-QhaC0EktjkJbtVZC .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-QhaC0EktjkJbtVZC .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-QhaC0EktjkJbtVZC .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-QhaC0EktjkJbtVZC .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-QhaC0EktjkJbtVZC .marker{fill:#333333;stroke:#333333;}#mermaid-svg-QhaC0EktjkJbtVZC .marker.cross{stroke:#333333;}#mermaid-svg-QhaC0EktjkJbtVZC svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-QhaC0EktjkJbtVZC p{margin:0;}#mermaid-svg-QhaC0EktjkJbtVZC .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-QhaC0EktjkJbtVZC .cluster-label text{fill:#333;}#mermaid-svg-QhaC0EktjkJbtVZC .cluster-label span{color:#333;}#mermaid-svg-QhaC0EktjkJbtVZC .cluster-label span p{background-color:transparent;}#mermaid-svg-QhaC0EktjkJbtVZC .label text,#mermaid-svg-QhaC0EktjkJbtVZC span{fill:#333;color:#333;}#mermaid-svg-QhaC0EktjkJbtVZC .node rect,#mermaid-svg-QhaC0EktjkJbtVZC .node circle,#mermaid-svg-QhaC0EktjkJbtVZC .node ellipse,#mermaid-svg-QhaC0EktjkJbtVZC .node polygon,#mermaid-svg-QhaC0EktjkJbtVZC .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-QhaC0EktjkJbtVZC .rough-node .label text,#mermaid-svg-QhaC0EktjkJbtVZC .node .label text,#mermaid-svg-QhaC0EktjkJbtVZC .image-shape .label,#mermaid-svg-QhaC0EktjkJbtVZC .icon-shape .label{text-anchor:middle;}#mermaid-svg-QhaC0EktjkJbtVZC .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-QhaC0EktjkJbtVZC .rough-node .label,#mermaid-svg-QhaC0EktjkJbtVZC .node .label,#mermaid-svg-QhaC0EktjkJbtVZC .image-shape .label,#mermaid-svg-QhaC0EktjkJbtVZC .icon-shape .label{text-align:center;}#mermaid-svg-QhaC0EktjkJbtVZC .node.clickable{cursor:pointer;}#mermaid-svg-QhaC0EktjkJbtVZC .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-QhaC0EktjkJbtVZC .arrowheadPath{fill:#333333;}#mermaid-svg-QhaC0EktjkJbtVZC .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-QhaC0EktjkJbtVZC .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-QhaC0EktjkJbtVZC .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-QhaC0EktjkJbtVZC .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-QhaC0EktjkJbtVZC .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-QhaC0EktjkJbtVZC .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-QhaC0EktjkJbtVZC .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-QhaC0EktjkJbtVZC .cluster text{fill:#333;}#mermaid-svg-QhaC0EktjkJbtVZC .cluster span{color:#333;}#mermaid-svg-QhaC0EktjkJbtVZC div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-QhaC0EktjkJbtVZC .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-QhaC0EktjkJbtVZC rect.text{fill:none;stroke-width:0;}#mermaid-svg-QhaC0EktjkJbtVZC .icon-shape,#mermaid-svg-QhaC0EktjkJbtVZC .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-QhaC0EktjkJbtVZC .icon-shape p,#mermaid-svg-QhaC0EktjkJbtVZC .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-QhaC0EktjkJbtVZC .icon-shape .label rect,#mermaid-svg-QhaC0EktjkJbtVZC .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-QhaC0EktjkJbtVZC .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-QhaC0EktjkJbtVZC .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-QhaC0EktjkJbtVZC :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

第一周K8s Audit Policy+ Filebeat

第二周ELK 管道+ 应用层审计

第一个月双层关联+ Kibana 看板

第一季度DORA 合规映射+ 自动报告

持续演进SLSA L2+ in-toto 证明

下篇预告： 第 22 章进入第四部分——规模化与成本优化。当 AI Agent 从单集群扩展到多集群，审计日志量从 GB 级增长到 TB 级，需要重新思考"日志采样 vs 全量审计"的取舍，以及跨集群审计关联的架构方案。

💬 加入讨论

你的 K8s 集群开了审计日志吗？用的是 Metadata 级别还是全量 RequestResponse？ILM 分片爆炸的问题有没有遇到过？我在某 200+ 节点集群迁移 ILM 时，因为 Hot 阶段直接设了 1 分片，导致跨天查询慢到无法使用。欢迎分享你踩过的审计日志坑——特别想知道除了 Filebeat 缓冲区溢出和 ES 分片爆炸，还有没有更经典的失败模式。

📌 延伸资源

• Kubernetes 审计官方文档 — 审计策略配置完整参考
• ECK Operator — Elastic Cloud on K8s 官方部署指南
• DORA 法规全文 EU 2022/2554 — 详细条款内容
• SLSA v1.0 完整规范 — 供应链安全等级标准
• Sigstore/cosign — 容器镜像签名工具
• Falco 运行时安全 — 运行时异常检测
• in-toto 规范 — 供应链元数据标准

📋 附录：速查表

审计级别选择：

DORA 不合规处罚上限：

Filebeat 关键参数速查：