KubernetesSRESecurity
场景
一家SRE团队发现开发账号拥有集群管理员权限，可以随意执行kubectl exec进入任意Pod，存在数据泄露和权限提升风险。
症状
- 审计日志中出现非预期的kubectl get secrets或kubectl exec命令
- 开发者报告可以访问超出其职责范围的命名空间
- 安全扫描工具标记出过多的ClusterRoleBinding
诊断
- 使用
kubectl auth can-i --list --as=developer查看特定用户权限。 - 运行
kubectl get clusterrolebindings -o wide查找绑定到Cluster-admin角色的Subject。 - 通过
kubectl describe clusterrolebinding <name>确认绑定详情。 - 检查Pod安全策略：
kubectl get psp，如果无输出表示未启用。
命令示例
# 列出用户权限
kubectl auth can-i --list --as=developer
# 创建受限Pod安全策略
kubectl apply -f restricted-psp.yaml
# 创建只读ClusterRole
kubectl create clusterrole readonly --verb=get,list,watch --resource=pods,services,endpoints
# 绑定到开发组
kubectl create clusterrolebinding dev-readonly --clusterrole=readonly --group=developers
# 回滚：删除策略
kubectl delete -f restricted-psp.yaml
风险控制
- 实施最小权限原则：为每个团队或应用创建专用ServiceAccount和RoleBinding。
- 启用Pod安全准入（PSA）或OPA Gatekeeper进行策略强制执行。
- 开启集群审计日志并集中监控（如ELK或OpsGlobal的SIEM集成）。
- 使用网络策略限制Pod间通信。
回滚方案
- 保存原有ClusterRoleBinding：
kubectl get clusterrolebinding dev-admin -o yaml > backup.yaml - 删除限制性策略：
kubectl delete -f restricted-psp.yaml - 恢复绑定：
kubectl apply -f backup.yaml
验证
- 以开发者身份执行：
kubectl auth can-i delete pods应返回yes（如配置为只读则返回no）。 - 检查审计日志：确保非授权操作被记录。
- 测试受限Pod：尝试创建特权Pod应被拒绝。
何时提交OpsGlobal工单
- 内部团队缺乏Kubernetes安全专业知识。
- 需要24/7监控和即时响应安全事件。
- 紧急情况如发现活跃入侵或配置错误无法快速回滚。
- 定期安全审计和合规要求需要外部专家支持。
适用场景
适合正在处理 Security、Kubernetes, SRE, Security 相关问题的团队，用于快速建立排查路径和交付标准。
问题背景
本文通过真实场景，演示如何诊断和修复Kubernetes集群中权限过大的问题，包括RBAC审计、Pod安全策略实施及回滚步骤，并提供OpsGlobal工单提交流程。
排查步骤
先确认影响范围和最近变更，再收集日志、配置、指标和链路数据，最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名，并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径，避免扩大故障影响。
回滚方案
保留原配置和发布版本；如修复后指标异常，立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题？
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题，可以提交日志和配置文件，我们帮你远程诊断。