4. etcd 安全审计:加密、TLS、ACL 与备份恢复基线核验
etcd 作为 Kubernetes 集群的“大脑”,存储了所有集群状态、Secret、ConfigMap 等敏感数据。etcd 的安全配置直接决定了集群的机密性、完整性和可用性。本章围绕加密、传输层安全、访问控制以及备份恢复四个维度,建立可量化的基线核验清单。
审计前置条件:执行以下所有核验操作前,请确保已获取 etcd 的
--endpoints、--cacert、--cert、--key 参数,或拥有 etcdctl 命令行工具的完整访问权限。
4.1 etcd 数据加密:静态加密与传输加密
etcd 存储的数据在静态和传输过程中都应加密。Kubernetes 1.13+ 支持 EncryptionConfiguration 资源,用于对 etcd 中的 Secret 等敏感资源进行静态加密。
4.1.1 静态加密基线核验
| 核验项 | 基线要求 | 核验命令/方法 |
|---|---|---|
| EncryptionConfiguration 存在 | 必须配置,且 resources 包含 secrets |
kubectl get encryptionconfig -o yaml |
| 加密提供者 | 至少使用 aescbc 或 kms,禁止仅使用 identity |
检查 providers 列表顺序 |
| 密钥轮换 | 密钥生命周期 ≤ 180 天,或支持自动轮换 | 检查 keys 中的 secret 创建时间 |
| 加密范围 | 必须覆盖 secrets,建议覆盖 configmaps |
查看 resources 列表 |
# 检查当前加密配置
kubectl get encryptionconfig -o yaml
# 验证 Secret 是否已加密(直接读取 etcd 中的原始数据)
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
get /registry/secrets/default/my-secret | strings | head -5
常见违规:部分集群仅配置了
identity 提供者,导致 Secret 以明文存储在 etcd 中。核验时务必确认 providers 列表的第一个有效提供者不是 identity。
4.1.2 传输加密基线核验
etcd 集群内部节点之间以及客户端与 etcd 之间的通信必须使用 TLS。核验以下三项:
- 客户端证书认证:etcd 启动参数中必须包含
--client-cert-auth且设置为true。 - 对等证书认证:etcd 启动参数中必须包含
--peer-client-cert-auth且设置为true。 - 证书有效期:所有 etcd 相关证书(CA、server、peer、client)剩余有效期 ≥ 30 天。
# 检查 etcd 启动参数(通过 Pod 描述或进程查看)
kubectl -n kube-system describe pod etcd-master | grep -E "client-cert-auth|peer-client-cert-auth"
# 检查证书有效期
openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -noout -enddate
4.2 TLS 认证与证书链核验
etcd 的 TLS 认证体系包含 CA 证书、服务端证书、对等证书和客户端证书。基线核验需要覆盖证书链完整性、密钥强度以及吊销状态。
# 核验证书链
openssl verify -CAfile /etc/kubernetes/pki/etcd/ca.crt \
/etc/kubernetes/pki/etcd/server.crt
# 核验密钥强度
openssl rsa -in /etc/kubernetes/pki/etcd/server.key -text -noout | grep "Private-Key"
# 核验证书吊销列表(CRL)
openssl crl -in /etc/kubernetes/pki/etcd/ca.crl -text -noout 2>/dev/null || echo "CRL 未配置"
4.3 访问控制列表(ACL)基线核验
etcd v3 支持基于角色的访问控制(RBAC)。Kubernetes 使用 etcd 时,默认不启用 etcd 自身的 RBAC,而是通过 API Server 的认证授权层进行控制。但作为安全基线,应核验 etcd 是否启用了额外的访问控制。
| 核验项 | 基线要求 | 核验方法 |
|---|---|---|
| etcd RBAC 状态 | 建议启用,至少确认未启用时无匿名访问 | etcdctl auth status |
| root 用户密码 | 如果启用 RBAC,root 密码必须符合复杂度要求 | 检查 etcdctl user list 输出 |
| 匿名访问 | 禁止匿名用户对 /registry 前缀的读/写权限 |
etcdctl role list + etcdctl role get |
| 最小权限原则 | Kubernetes 使用的 etcd 用户仅拥有 /registry 前缀的读写权限 |
检查角色权限定义 |
# 检查 etcd 认证状态
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
auth status
# 列出所有用户和角色
etcdctl user list
etcdctl role list
# 检查特定角色的权限
etcdctl role get root
最佳实践:在 Kubernetes 环境中,etcd 的访问控制主要依赖 API Server 的 TLS 客户端证书认证。建议在 etcd 侧额外启用 RBAC,为每个 API Server 实例创建独立的用户和角色,实现最小权限。
4.4 定期备份与恢复策略基线核验
etcd 备份是集群灾难恢复的最后一道防线。基线核验需要覆盖备份频率、备份完整性、恢复演练以及备份存储安全。
4.4.1 备份策略基线
| 核验项 | 基线要求 | 核验方法 |
|---|---|---|
| 备份频率 | 生产集群 ≥ 每 6 小时一次快照 | 检查 cronjob 或备份脚本执行记录 |
| 备份保留周期 | 至少保留最近 30 天的备份 | 检查备份存储目录的文件时间戳 |
| 备份存储位置 | 必须异地存储,与 etcd 集群物理隔离 | 检查备份目标路径或对象存储桶 |
| 备份加密 | 备份文件必须加密存储 | 检查备份文件是否使用 GPG/AES 加密 |
| 恢复演练 | 每季度至少执行一次恢复演练并记录 | 检查恢复演练报告 |
4.4.2 备份与恢复命令基线
# 创建 etcd 快照备份
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db
# 验证备份文件完整性
etcdctl snapshot status /backup/etcd-snapshot-20250301-120000.db
# 从快照恢复(在停止 etcd 服务后执行)
etcdctl snapshot restore /backup/etcd-snapshot-20250301-120000.db \
--data-dir=/var/lib/etcd-restored \
--initial-cluster=master=https://192.168.1.10:2380 \
--initial-cluster-=etcd-cluster \
--initial-advertise-peer-urls=https://192.168.1.10:2380
4.4.3 备份自动化与监控基线
- 自动化备份:必须使用 CronJob 或 systemd timer 实现自动备份,禁止仅依赖手动操作。
- 备份监控:备份成功/失败事件必须接入集群告警系统(如 Prometheus + Alertmanager)。
- 备份大小监控:备份文件大小异常(突增或突降)应触发告警,可能预示数据损坏或丢失。
- 恢复手册:必须维护最新的 etcd 恢复操作手册,并放置在集群节点本地和文档系统中。
4.5 基线核验清单汇总
以下清单可作为 etcd 安全审计的最终检查表,建议在每次集群变更或定期审计时逐项核验。
| 编号 | 核验项 | 基线标准 | 通过/失败 |
|---|---|---|---|
| ETCD-01 | 静态加密配置 | EncryptionConfiguration 存在且使用 aescbc/kms | ☐ |
| ETCD-02 | 传输加密 | client-cert-auth 和 peer-client-cert-auth 均为 true | ☐ |
| ETCD-03 | 证书有效期 | 所有 etcd 证书剩余有效期 ≥ 30 天 | ☐ |
| ETCD-04 | 证书链完整性 | openssl verify 通过 | ☐ |
| ETCD-05 | 密钥强度 | ≥ 2048 位 RSA 或 ECDSA P-256 | ☐ |
| ETCD-06 | 访问控制 | 无匿名访问,最小权限原则 | ☐ |
| ETCD-07 | 备份频率 | 生产集群 ≤ 6 小时 | ☐ |
| ETCD-08 | 备份保留 | ≥ 30 天 | ☐ |
| ETCD-09 | 备份加密 | 备份文件加密存储 | ☐ |
| ETCD-10 | 恢复演练 | 每季度至少一次,有记录 | ☐ |
审计红线:如果 ETCD-01(静态加密)或 ETCD-02(传输加密)未通过,应立即停止集群变更操作,优先修复加密配置。etcd 数据明文存储是最高风险项,可能导致集群凭据和业务数据泄露。