需配置Kubernetes Audit Policy以精准捕获高危特权变更，包括Secret/ConfigMap修改、RBAC绕过等行为；确保日志落盘可靠、不可篡改且含完整请求响应体；并对接SIEM实现端到端可溯源流水线。
要配置集群的 Audit Policy 审计策略，实现对全网高危特权越权变更（如 Secret/ConfigMap 修改、非授权用户提权、RBAC 绕过、ClusterRole 绑定等）的物理流水线级捕获与留存，关键在于三点：
✅ 策略精准覆盖高危行为类型
✅ 日志落盘可靠、不可篡改、带完整上下文（含请求体+响应体）
✅ 流水线可对接 SIEM 或日志平台，支持溯源回放
以下是实操要点，不绕弯、不堆概念：
一、定义高危资源与操作的审计规则
Audit Policy 不是“开全量日志”，而是用最小必要原则聚焦高危路径。以下规则应写入 `/etc/kubernetes/audit-policy.yaml`（必须挂载进 kube-apiserver）：-
level: RequestResponse
resources:- group: ""
resources: ["secrets", "configmaps"]
verbs: ["create", "update", "patch", "delete"]
→ 捕获敏感配置的完整请求+响应体，含明文字段值（如数据库密码）
- group: ""
-
level: RequestResponse
resources:- group: "rbac.authorization.k8s.io"
resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]
verbs: ["create", "update", "patch"]
→ 记录所有权限提升类变更，包括谁绑定了 cluster-admin
- group: "rbac.authorization.k8s.io"
level: Metadata
userGroups: ["system:unauthenticated", "system:anonymous"]
→ 标记未认证访问尝试，常为爆破或Token泄露入口-
level: Request
verbs: ["impersonate"]
resources:- group: ""
resources: [""]
→ 所有伪装行为（如 kubectl --as=system:admin）必须留痕
- group: ""
level: None
users: ["kube-controller-manager", "kube-scheduler", "system:kube-proxy"]
→ 排除系统组件自身调用，减少噪音，但保留其被冒用的可能（靠上一条 impersoante 规则兜底）
二、确保审计日志物理留存可靠
仅配 Policy 不够，必须保证日志能落地、防删改、可归档：启动参数中强制启用审计日志输出：
--audit-log-path=/var/log/kubernetes/audit.log--audit-policy-file=/etc/kubernetes/audit-policy.yaml--audit-log-maxsize=200（单位 MB，防单文件过大）--audit-log-maxbackup=10（保留最近 10 个轮转文件）--audit-log-maxage=30（日志至少存 30 天）将
/var/log/kubernetes/挂载为只读宿主机目录或使用 hostPath + subPath 显式绑定，避免容器重启丢失启用日志服务（如 SLS/ELK）的日志采集器直采 audit.log 文件，跳过中间转发（避免缓冲区丢失或重排序）
若用阿里云 ACK，开启「集群审计」功能时，务必选择独立 SLS Project，并确认该 Project 已开启「日志投递到 OSS」——这是满足等保/合规要求的物理留存底线
三、构建可回溯的流水线闭环
“物理流水线”不是指硬件链路，而是指从事件发生 → 落盘 → 采集 → 存储 → 查询 → 告警的端到端不可绕过路径：- 日志采集器（如 Logtail）需以 root 权限运行，且配置
file_mode: "0600"，防止非 root 进程篡改或清空 audit.log - 在日志服务中建立固定索引字段：
user.username,user.groups,requestURI,verb,resourceName,responseObject.data（Secret 内容脱敏后可存 hash 或长度） - 设置告警规则示例（SLS 查询语法）：
level: "RequestResponse" and (resourceName:"admin" or resourceName:"cluster-admin") and verb:"create"
→ 触发企业微信/钉钉实时告警，并自动关联该用户近期所有操作时间线 - 每月导出一次完整 audit.log 归档包（含 SHA256 校验码），存入离线 WORM 存储（如阿里云 OSS 归档 + 合规保留策略）
四、验证与兜底机制
策略上线后必须验证是否真能捕获越权行为：- 手动测试：用普通用户执行
kubectl patch clusterrolebinding default-admin -p '{"subjects":[{"kind":"User","name":"hacker"}]}'
查看 audit.log 是否记录了该用户、原始请求体、拒绝/成功状态及 responseStatus.code - 开启
--audit-webhook-config-file作为双写备份（可选），将关键事件同步推送到安全审计中心 - 配置巡检任务定期检查：
kubectl get auditpolicy.audit.k8s.io -A是否存在ps aux | grep audit-log-path是否生效/var/log/kubernetes/audit.log*文件权限与更新时间是否正常
不复杂但容易忽略：真正决定审计效力的，从来不是策略有多全，而是日志有没有真实落到磁盘、有没有被第三方系统不可抵赖地收走、有没有人在变更后第一时间看到它。
