系统设计面试：如何设计 Kubernetes 审计策略与可靠日志管道？
题干与适用场景
一个多租户集群需要回答“谁在何时从哪里修改了什么”，同时控制 API Server 内存、日志成本和 Secret 泄露风险。请设计 audit policy、日志或 webhook 后端、采样与告警、故障处理和取证验证。
面试官考察点
- 是否理解规则按顺序匹配、
None、Metadata、Request、RequestResponse的差异。 - 是否能区分
RequestReceived、ResponseStarted、ResponseComplete等阶段。 - 是否考虑长连接、敏感请求体、后端阻塞和日志完整性。
- 是否把审计目标映射到告警、留存、访问控制和演练。
回答前需要澄清的问题
- 需要审计的高风险资源、动词、租户和主体范围是什么？
- 哪些请求体含 Secret、令牌或个人数据，合规留存多久？
- 选择本地文件、webhook 还是两者，允许多大日志延迟与丢失窗口？
- 取证要求不可抵赖、跨区域复制和谁能读取原始日志吗？
30 秒回答框架
先列出高风险 API 和数据边界，规则按最具体到兜底的顺序匹配。对大多数资源记录 Metadata，对关键变更按需记录 Request，谨慎使用 RequestResponse，避免把 Secret 写入日志。只在确有需要时省略早期阶段，按后端能力选择文件、webhook 或双写。日志管道要有缓冲、限速、加密、完整性校验、访问审计和明确的丢失告警，并用演练验证故障时的行为。
分步骤深入解答
1. 先定义取证问题
把“谁、何时、从哪里、对什么做了什么”拆成字段和查询。高风险对象包括 Secret、RoleBinding、Webhook、节点和租户配额；普通健康检查不必记录完整请求体。审计策略必须服务具体调查问题，而非追求所有字段。
2. 设计有序规则
规则从最具体到兜底排列，第一条匹配决定审计级别。为高风险变更设置 Request 或必要的 RequestResponse，常规读取用 Metadata，明确的噪声用 None，最后用低级别兜底，避免漏记未知资源。
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
- RequestReceived
rules:
- level: Request
resources:
- group: ""
resources: ["secrets"]
- level: Metadata
omitStages: ["RequestReceived"]
resources:
- group: ""
resources: ["pods"]
- level: None
users: ["system:kube-probe"]3. 控制阶段和敏感字段
长连接会产生 ResponseStarted，完成时才有 ResponseComplete；裁剪阶段可能降低重复量，但不能假设每种请求都只有一个事件。对 Secret 和身份材料优先记录元数据、哈希或受控摘要，禁止把原始值发送到普通日志系统。
4. 选择和保护后端
文件后端要轮换、压缩、加密并可靠转发；webhook 后端要有 TLS、认证、队列和背压。日志管道应按租户和风险分区，写入只追加存储，附带 audit ID、策略版本和接收时间。下游消费者不能反向阻塞 API Server。
5. 定义故障语义
明确后端不可达、磁盘满、队列溢出和网络分区时是丢弃、阻塞还是降级。高风险变更可选择 fail-closed，但必须量化对控制面的影响；一般请求可有限缓冲并告警。每种策略都要记录丢失计数和恢复后的补偿扫描范围。
6. 验证与持续改进
用已知用户、ServiceAccount、代理和长连接生成事件，检查规则命中、阶段、租户和字段脱敏。故意制造 webhook 延迟、磁盘满和策略更新，验证告警、恢复和取证查询。定期比较事件量、丢失率、延迟、成本和真实调查覆盖率。
高质量示范回答
我先把调查问题映射到字段和高风险资源，再按最具体到兜底排列规则。常规请求记录 Metadata，Secret 只留受控元数据，关键变更才提升到 Request；对长连接明确阶段裁剪。后端采用加密文件或 TLS webhook，带缓冲、背压、不可篡改存储和访问审计，且不让下游阻塞 API Server。故障时定义有限缓冲、丢失计数和告警，必要时对高风险写入 fail-closed。最后用合成事件、长连接和故障演练验证规则、完整性与恢复。
常见错误
- 所有请求都用
RequestResponse→ 敏感数据泄露和成本爆炸 → 按风险分级。 - 规则顺序随意 → 兜底规则提前吞掉高风险事件 → 由具体到通用排列。
- 只看日志文件存在 → 后端阻塞或丢失未被发现 → 监控队列、延迟和丢失计数。
- 忽略阶段语义 → 长连接调查缺少关键时间点 → 明确各阶段和裁剪原因。
- 让 webhook 下游同步阻塞 API Server → 控制面雪崩 → 缓冲、超时和背压隔离。
追问及应对
为什么不把所有 Secret 请求记录为 RequestResponse？
请求体可能包含 Secret 明文。多数调查只需要主体、对象、动词和结果；若必须深入，应使用脱敏、隔离权限和短期受控留存。
webhook 不可用时应该阻断 API 请求吗？
取决于风险和可用性目标。高风险写入可在量化影响后选择 fail-closed，普通请求则有限缓冲并告警；无论选择哪种，都要记录丢失和恢复范围。
如何证明规则没有漏记未知资源？
保留低级别兜底规则，并用资源发现清单、合成请求和策略版本对照检查事件覆盖；新 API 出现时触发规则评审，而不是依赖人工发现。