3. etcd 策略评审概述：策略评审的目标、范围、频率与角色职责
etcd 作为分布式系统的“控制面”与“元数据中心”，其策略配置直接决定了集群的可靠性、安全性与可运维性。策略评审（Policy Review）是一项周期性、结构化的审计活动，旨在确保 etcd 集群的访问控制、配额、压缩、快照、TLS 等策略始终与业务需求、安全基线及最佳实践保持一致。
3.1 策略评审的核心目标
策略评审并非一次性的“合规检查”，而是持续改进集群治理的关键手段。其核心目标包括：
- 安全性加固： 验证 RBAC 角色权限、TLS 证书有效期、客户端证书认证策略是否满足最小权限原则，防止权限滥用或未授权访问。
- 稳定性保障： 检查存储配额（quota）、后端快照策略、自动压缩（auto-compaction）参数是否合理，避免因空间耗尽或历史数据堆积导致集群抖动。
- 合规性对齐： 确保策略符合企业内部安全基线、行业标准（如 PCI-DSS、SOC2）或监管要求。
- 风险暴露收敛： 识别并移除过期、冗余或过于宽松的策略条目，降低攻击面。
实践建议： 将策略评审与变更窗口（Change Window）解耦。评审发现的风险项应记录为工单，在计划维护窗口内统一修复，避免“边评审边变更”导致状态混乱。
3.2 评审范围：五大策略域
etcd 策略评审覆盖以下五个核心域，每个域对应一组可审计的策略参数：
| 策略域 | 审计对象 | 典型风险项 |
|---|---|---|
| 访问控制 | RBAC 角色、用户、权限绑定 | root 角色长期未轮换、通配符权限滥用、幽灵用户 |
| TLS 与证书 | CA 证书、服务端/客户端证书、证书吊销列表 | 证书即将过期、弱签名算法、未启用双向 TLS |
| 存储与配额 | --quota-backend-bytes、--auto-compaction-retention |
配额设置过高导致 OOM、压缩策略未开启、快照频率过低 |
| 集群操作 | 成员管理、端点配置、选举超时 | 成员端点未更新、选举超时与网络延迟不匹配 |
| 审计与日志 | 审计日志开关、日志级别、日志轮转 | 审计日志未开启、日志级别过低淹没关键告警 |
常见误区： 很多团队只评审 RBAC 和证书，忽略了存储配额与压缩策略。实际上，配额耗尽导致的集群只读故障，是生产环境中最常见的 etcd 严重事故之一。
3.3 评审频率：分层节奏
不同策略域的风险等级与变更频率不同，建议采用分层评审频率：
- 月度评审（高风险域）： 访问控制（RBAC）、TLS 证书有效期。这两类策略一旦失效，会直接导致安全事件或集群不可用。
- 季度评审（中风险域）： 存储配额、自动压缩、快照策略。这些参数通常随业务容量规划调整，季度评审可及时发现容量瓶颈。
- 半年度评审（低风险域）： 集群操作参数（如选举超时）、审计日志配置。除非集群架构发生重大变化，否则这些参数相对稳定。
3.4 角色与职责矩阵
有效的策略评审需要明确 RACI（负责、批准、咨询、知悉）矩阵，避免责任真空或重复劳动：
| 角色 | 职责 | 参与环节 |
|---|---|---|
| SRE 运维工程师 | 执行策略采集、生成评审报告、标记风险项 | 评审前准备、评审中汇报 |
| SRE 技术负责人 | 审核风险项、决策策略变更方案、审批变更 | 评审中决策、变更审批 |
| 安全工程师 | 提供安全基线、验证合规性、参与高危项评审 | 评审中咨询、合规验证 |
| 业务方代表 | 确认业务对策略变更的容忍度、提供容量预期 | 评审前咨询、变更确认 |
| 变更经理 | 协调变更窗口、记录评审结论、跟踪闭环 | 评审后跟踪、变更调度 |
评审流程速览：
1. SRE 运维工程师使用
2. 生成策略基线对比报告，标记与上次评审的差异项。
3. 召开评审会议（或异步评审），逐项确认风险等级与处置方案。
4. 高风险项立即创建变更工单，中低风险项纳入下一维护窗口。
5. 评审记录归档，作为下一次评审的基线。
1. SRE 运维工程师使用
etcdctl role list、etcdctl user list、etcdctl endpoint status 等命令采集当前策略快照。2. 生成策略基线对比报告，标记与上次评审的差异项。
3. 召开评审会议（或异步评审），逐项确认风险等级与处置方案。
4. 高风险项立即创建变更工单，中低风险项纳入下一维护窗口。
5. 评审记录归档，作为下一次评审的基线。
3.5 评审输出与闭环
每次策略评审必须输出以下三项产物，缺一不可：
- 策略快照文件： 包含评审时刻所有策略的完整导出（建议使用
etcdctl role get和etcdctl user get逐条导出，或通过 etcd 的/v3/auth/role/listAPI 批量获取）。 - 风险清单： 按 P0~P3 分级，P0 为立即修复项（如 root 角色密码为空），P3 为观察项（如日志级别可优化）。
- 变更跟踪表： 记录每项风险的修复责任人、计划修复日期、实际修复状态。
关键提醒： 策略评审不是“一次性作业”。如果评审后没有跟踪闭环，风险项会持续累积，最终在下一次故障中集中爆发。建议将评审跟踪表与工单系统（如 Jira、ServiceNow）联动，自动触发到期提醒。