一、当你在Kubernetes里开盲盒时，审计日志正在帮你记录一切
想象一下你的Kubernetes集群是一栋摩天大楼，API Server就是门禁系统——所有人员进出必须刷卡。如果有人试图撬锁或者用假卡混进去呢？这时候审计日志就是全天候的监控摄像头，记录每一笔操作的时间、人物、动作甚至失败原因。
集群被攻击时，90%的安全事件其实都有迹可循。比如某天运维同事突然发现生产环境的Pod被批量删除，翻遍操作记录却找不到元凶——这时候如果启用了审计日志，真相可能就在一行日志里。
二、API Server审计配置的"灵魂三问"
2.1 问题一：你记录哪些操作？
通过审计策略（Audit Policy）控制日志范围。以下是一个典型策略文件（Kubernetes v1.24+适用）：
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# 记录所有Namespace的删除操作（级别：Metadata）
- level: Metadata
verbs: ["delete"]
resources:
- group: "" # core API group
resources: ["pods", "deployments"]
# 记录对Secrets的读写请求（级别：Request）
- level: Request
resources:
- group: ""
resources: ["secrets"]
# 忽略查看ConfigMap的请求（级别：None）
- level: None
resources:
- group: ""
resources: ["configmaps"]
verbs: ["get", "list"]
# 默认记录所有请求的元数据（级别：Metadata）
- level: Metadata
omitStages: ["RequestReceived"]
注释说明：
level定义了四种日志详细程度：None（不记录）、Metadata（记录操作对象）、Request（记录请求体）、RequestResponse（包含响应体）omitStages可过滤请求阶段（RequestReceived/ResponseStarted/ResponseComplete）
2.2 问题二：日志存在哪儿？
修改kube-apiserver启动参数（以静态日志文件为例）：
# /etc/kubernetes/manifests/kube-apiserver.yaml 片段
spec:
containers:
- command:
- kube-apiserver
- --audit-policy-file=/etc/kubernetes/audit/audit-policy.yaml
- --audit-log-path=/var/log/kubernetes/audit/audit.log
- --audit-log-maxsize=100 # 每个日志文件最大100MB
- --audit-log-maxbackup=5 # 保留5个历史文件
2.3 问题三：如何不被日志淹没？
某电商平台的真实案例：开启全量审计日志后，API Server内存使用量从2GB飙升至8GB。最终通过以下策略优化：
- 对高频只读操作（如GET /healthz）设置
level: None - 将日志输出改为Webhook后端，由外部服务处理
- 使用
kubectl top pod定期监控apiserver资源消耗
三、安全事件分析实战：黑客的三次入侵尝试
场景还原
某日凌晨，监控系统发出Pod异常告警。通过审计日志排查发现：
// audit.log 片段
{
"kind": "Event",
"apiVersion": "audit.k8s.io/v1",
"stage": "ResponseComplete",
"requestURI": "/api/v1/namespaces/prod/pods?timeout=10s",
"verb": "delete",
"user": {
"username": "system:serviceaccount:default:hacker",
"groups": ["system:serviceaccounts"]
},
"responseStatus": {
"code": 403
},
"annotations": {
"authorization.k8s.io/decision": "forbid",
"reason": "RBAC: not permitted"
}
}
日志解密：
- 攻击者使用default命名空间的hacker账号尝试删除Pod
- 因RBAC权限不足被拒绝（HTTP 403）
- 通过
responseStatus可追溯失败原因
追踪技巧：
# 搜索特定用户的操作记录
grep '"user":{"username":"system:serviceaccount:default:hacker"' audit.log
# 分析过去1小时内删除Pod的操作
jq 'select(.verb == "delete" and .requestURI | contains("/pods"))' audit.log
四、技术选型的"红黑榜"
4.1 优点
- 溯源利器：某金融客户曾通过审计日志发现内部员工违规操作证书
- 合规刚需：满足GDPR/HIPAA等法规的安全审计要求
- 故障排查：当etcd出现数据不一致时，可回放关键操作
4.2 挑战
- 性能影响：日志级别设置为RequestResponse时，API Server延迟可能增加15%~30%
- 存储成本：日均千节点的集群可能产生100GB+日志（需配合日志轮转）
- 敏感信息泄露风险：若日志中包含Secret的base64值，需额外脱敏处理
五、你必须绕过的五个大坑
- 权限泄露：确保审计日志文件只能被master节点访问（建议权限640）
- 时间不同步：所有节点的NTP服务必须启用，否则时间戳混乱
- 日志覆盖：使用
logrotate定期切割文件，避免单个文件过大 - 正则表达式陷阱：jq查询时注意转义特殊字符，如
.requestURI | contains("?token=") - 版本兼容性：v1.22之后废弃的audit.k8s.io/v1beta1需及时迁移
六、总结
就像飞机上的黑匣子，Kubernetes审计日志平时看似安静，但在关键时刻就是拯救集群的诺亚方舟。通过精细的策略配置、合理的存储方案、持续的监控分析，你可以将安全防护从"被动挨打"变成"主动出击"。记住，真正的高手不是永远不犯错，而是能在犯错后快速找到问题根源。
Comments