Kubernetes Secrets安全审计实战从etcd到RBAC的纵深防御1. Kubernetes Secrets安全现状与风险全景在云原生环境中Secrets管理一直是安全工程师最头疼的问题之一。根据CNCF 2022年安全调查报告显示超过65%的生产环境事故与凭证泄露有关而Kubernetes集群中的Secrets管理不当是主要原因。Secrets在Kubernetes中本质上只是base64编码的配置项而非真正加密的数据。攻击者一旦突破边界可以通过多种途径获取敏感信息etcd直接访问默认情况下etcd存储未加密的Secrets数据ServiceAccount滥用过度宽松的RBAC配置导致权限提升不当挂载方式将Secrets挂载到容器文件系统可能留下痕迹审计日志泄露不当配置的审计策略可能记录敏感操作# 典型Secrets访问路径示意图 etcd ├── 明文存储风险 ├── 未授权访问风险 └── 备份泄露风险 │ Kubernetes API Server ├── RBAC配置不当 ├── 审计日志缺陷 └── 过度权限ServiceAccount │ Pod ├── 文件挂载残留 ├── 环境变量暴露 └── 日志泄露风险2. etcd裸奔风险与加密方案etcd作为Kubernetes的大脑存储着集群所有状态数据。但默认安装时Secrets在etcd中以明文形式存储这相当于让敏感数据裸奔。2.1 etcd数据直接访问实验通过访问etcd可以轻易获取Secrets内容# 获取etcd中存储的secret ETCDCTL_API3 etcdctl \ --cert/etc/kubernetes/pki/apiserver-etcd-client.crt \ --key/etc/kubernetes/pki/apiserver-etcd-client.key \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ get /registry/secrets/default/mysecret2.2 etcd加密配置方案Kubernetes 1.7支持静态数据加密通过创建EncryptionConfiguration实现# /etc/kubernetes/encrypt-conf.yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: BASE64_ENCODED_32_BYTE_KEY - identity: {} # 允许解密已有数据应用配置后需要重启API Server并执行Secrets轮换kubectl get secrets --all-namespaces -o json | kubectl replace -f -注意加密仅对新创建的Secrets生效已有Secrets需要手动更新3. ServiceAccount滥用与横向移动ServiceAccount是Pod访问API Server的身份凭证不当配置可能导致严重安全问题。3.1 典型攻击路径graph LR A[获取Pod SA令牌] -- B[探测API Server权限] B -- C{高权限?} C --|是| D[获取集群敏感数据] C --|否| E[尝试权限提升]3.2 防御措施实践最小权限RBAC配置示例apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules: - apiGroups: [] resources: [pods] verbs: [get, watch, list] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: default subjects: - kind: ServiceAccount name: default namespace: default roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io关键加固措施禁用默认ServiceAccount的自动挂载为每个工作负载创建专用ServiceAccount遵循最小权限原则配置RBAC定期审计ServiceAccount权限4. 审计日志与监控体系构建完善的审计日志是发现异常行为的关键。Kubernetes审计日志分为三个阶段RequestReceived请求到达API Server时ResponseStarted响应头发送后响应体发送前ResponseComplete响应体发送完成4.1 审计策略配置示例apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Metadata resources: - group: resources: [secrets] - level: RequestResponse userGroups: [system:nodes] - level: None users: [system:apiserver]4.2 Falco实时检测规则- rule: Unexpected K8s Secret Access desc: Detect suspicious access to Kubernetes secrets condition: k8s_audit and ka.verb in (get, list, watch) and ka.target.resourcesecrets and not ka.user.name in (system:apiserver, system:kube-controller-manager) output: Unexpected secret access (user%ka.user.name verb%ka.verb secret%ka.target.name) priority: WARNING5. 纵深防御体系实践方案构建完整的Secrets防护体系需要多层防御5.1 网络层控制apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-metadata-access namespace: metadata-access spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 except: - 192.168.100.21/325.2 运行时防护AppArmor配置文件示例#include tunables/global profile k8s-apparmor flags(attach_disconnected) { # 拒绝敏感目录写入 deny /etc/** w, deny /proc/** w, # 允许必要访问 /usr/bin/curl ix, /tmp/** rw, }5.3 安全配置检查表检查项安全配置检测方法etcd加密启用静态加密检查EncryptionConfigurationRBAC配置最小权限原则kubectl auth can-i --list审计日志关键操作全记录检查审计策略文件网络策略限制元数据访问检查NetworkPolicy镜像安全非root用户运行检查PodSecurityContext6. 红蓝对抗实战演练通过模拟攻击验证防御措施有效性场景一etcd数据泄露攻击直接访问etcd获取Secrets防御启用etcd静态加密场景二ServiceAccount滥用攻击利用高权限SA获取集群权限防御RBAC最小权限配置场景三容器逃逸攻击通过挂载目录获取宿主权限防御AppArmor/SELinux限制# 安全加固检查脚本示例 #!/bin/bash check_etcd_encryption() { kubectl get encryptionconfig -o json | jq .resources[] | select(.resources[]secrets) } check_rbac() { kubectl get clusterrolebindings -o json | jq .items[] | select(.subjects[].kindServiceAccount) } check_audit_log() { ssh master-1 cat /etc/kubernetes/audit/policy.yaml | grep -A5 secrets }7. 持续安全运维建议定期轮换凭证使用外部Secrets管理工具实现自动轮换实时监控告警对敏感操作设置阈值告警自动化扫描将安全检查集成到CI/CD流水线员工培训提高团队安全意识和应急响应能力在DevSecOps实践中安全不是一次性的工作而是需要贯穿整个应用生命周期的持续过程。通过构建从etcd存储到应用层的全方位防护才能确保Kubernetes Secrets的安全管理。