为SRE团队加固Kubernetes集群：实用安全指南

场景

一家公司的Kubernetes集群因RBAC配置错误和Pod安全策略缺失而被入侵。攻击者利用一个高权限的ServiceAccount创建了恶意Pod，并获取了节点root权限。

症状

• 集群中出现未知Pod，且来源不明。
• kubectl get pods显示异常容器，如crypto-miner。
• 审计日志中出现大量“create pod”事件，但非预期用户。
• 节点负载异常升高。

诊断

1. 检查所有ServiceAccount的RBAC绑定： bash kubectl get rolebindings,clusterrolebindings -A -o wide 识别出拥有cluster-admin权限的绑定。
2. 查看审计日志（若已启用）： bash kubectl logs -n kube-system apiserver | grep -i “user=<suspicious>”
3. 检查PodSecurityPolicy（或Pod Security Admission）配置： bash kubectl get psp # 若已启用
4. 检查NetworkPolicy： bash kubectl get networkpolicies -A 发现无网络隔离策略。

命令与修复

步骤1：最小权限RBAC

• 移除危险绑定： bash kubectl delete clusterrolebinding <binding-name>
• 创建精细角色： bash kubectl create role pod-reader --verb=get,list,watch --resource=pods kubectl create rolebinding dev-pod-reader --role=pod-reader --user=dev-user

步骤2：启用Pod安全标准

• 使用内置Pod Security Admission（K8s v1.23+）： bash kubectl label --overwrite ns <namespace> pod-security.kubernetes.io/enforce=restricted

步骤3：网络策略

• 默认拒绝所有入站流量： ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress spec: podSelector: {} policyTypes:
  • Ingress ```

步骤4：密钥管理

• 停止在ConfigMap中明文存储密钥，使用外部密钥存储（如HashiCorp Vault）或Sealed Secrets。

风险控制

• 在生产环境执行任何操作前，先克隆集群或使用非生产副本测试。
• 更改RBAC时，使用--dry-run=client预览。
• 确保所有更改有回滚计划，例如保留旧RoleBinding的YAML备份。

回滚

• 若新策略导致服务中断： bash kubectl apply -f backup-rbac.yaml kubectl label ns <namespace> pod-security.kubernetes.io/enforce- # 移除标签

验证

• 测试用户权限： bash kubectl auth can-i create pods --as=dev-user # 应返回no
• 尝试部署特权Pod（期望被拒绝）： bash kubectl run test-pod --image=nginx --privileged
• 检查审计日志确认没有未经授权的活动。

何时提交OpsGlobal工单

• 当出现以下情况时，应立即提交工单：
• 集群已受到攻击，需要即时取证和恢复。
• 团队缺乏安全加固经验，需要专家指导。
• 需要实施高级安全控制（如运行时安全、CIS基准扫描）。
• 怀疑存在内部威胁或长期潜伏的恶意活动。

OpsGlobal的SRE专家可以协助快速恢复、部署安全工具并提供持续监控。