必须从k8s集群侧启用audit.k8s.io/v1审计策略并配置webhook后端，go程序仅消费经签名验证的审计日志；禁用客户端sdk或roundtripper自行记录，因其无法获取真实用户、rbac决策、authorization头等关键上下文。
怎么让 Go 程序拿到 K8s API 的完整操作日志
不能靠客户端 SDK 自己“记日志”——kubernetes/client-go 默认不透出原始请求/响应体，更不会记录 Authorization 头、真实用户身份、审计策略生效前的原始动词。真要审计，得从 K8s 集群侧统一收口，Go 程序只负责消费这些日志。
实操建议：
- K8s 集群必须启用
audit.k8s.io/v1审计策略（不是v1beta1），且配置policyFile明确指定哪些事件等级（Metadata/Request/RequestResponse）写入后端 - 后端推荐用
webhook模式，把日志推到你自己的 Go 服务（别用log后端，丢日志、无认证、难溯源） - 你的 Go 服务要能验证 webhook 请求签名（K8s 会带
Authorization: Bearer xxx，对应你配在audit-webhook-kubeconfig里的 client cert） - 注意：K8s 不保证日志顺序和实时性，高负载下可能延迟数秒甚至丢条，别拿它做强一致性判断
Go 服务怎么安全接收并解析 K8s audit webhook 日志
收到的不是结构化 JSON，而是 audit.k8s.io/v1.Event 对象序列化后的字节流，但字段含义和权限控制比想象中复杂。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 直接
json.Unmarshal到自定义 struct，结果user.username是空的——因为 K8s 实际填的是user.extra或user.groups，而真实用户名常藏在user.username或annotations["authentication.k8s.io/identity"] - 忽略
level字段，把Metadata级日志当RequestResponse用，导致看不到请求体和响应状态码 - 没校验
requestURI是否被篡改，攻击者可伪造 webhook 请求投毒
实操建议：
- 用官方
auditv1 "k8s.io/apiserver/pkg/apis/audit/v1"包解码，别手写 struct；它会正确处理user、sourceIPs、verb、responseObject等字段 - 必验
event.Level == auditv1.LevelRequestResponse再解析requestBody和responseStatus，否则字段为空或 panic - 校验
event.AuditID唯一性 +event.StageTimestamp时间戳合理性，防重放
为什么不能在 Go 客户端里用 RoundTrip Hook 记录所有 K8s 调用
有人想在 rest.Config.Transport 里塞个自定义 RoundTripper，拦截每个 http.Request——这看似简单，实际漏掉关键上下文，且违反审计可信链。
使用场景局限：
- 只捕获你这个 Go 进程发起的调用，漏掉 kubectl、其他 operator、kubelet、甚至 K8s controller manager 自身的操作
- 拿不到 RBAC 最终决策结果（允许/拒绝）、审计策略匹配的规则名、
impersonate用户链路 - 如果用了
TokenRequest动态 token 或exec插件认证，Authorization头在 transport 层已加密或未生成
性能与兼容性影响：
- 每个请求多一次内存拷贝（body 读两次），QPS 上千时 GC 压力明显
- K8s 1.26+ 引入
Authentication-Info头用于 token 绑定，自定义 transport 很难正确透传 - client-go v0.28+ 默认启用了 HTTP/2，某些 hook 实现会破坏流控逻辑，导致连接复用失效
审计日志里哪些字段真正可信，哪些可能被绕过
不是所有字段都来自 K8s apiserver 的权威判定。有些是客户端传入、未经校验的，直接用于告警或阻断会出问题。
真正可信（apiserver 强制注入/覆盖）：
-
level：由审计策略文件决定，不可被请求篡改 -
stage：如"ResponseComplete"，表示响应已发出，不会因超时或中断丢失 -
user.username和user.groups：经 authenticator 插件验证后的结果，非原始 header -
requestURI：已规范化（去 query 参数、标准化 path），防路径遍历绕过
需谨慎对待（可能为空、被伪造、或依赖客户端配合）：
-
objectRef：对 patch 请求可能为空；对 list 请求可能只含 namespace，不含具体资源名 -
annotations["authorization.k8s.io/decision"]：仅当启用了RBAC且策略明确 deny 时才存在，allow 不写该 annotation -
sourceIPs：若集群走云厂商 NLB 或 Istio ingress，这里可能是 LB IP，不是真实客户端 IP
最后提醒一句：audit webhook 的 TLS 证书必须由 K8s CA 签发，且 Go 服务必须用 rest.InClusterConfig() 或显式加载该 CA，否则中间人攻击下，日志本身就成了攻击面。
