DevOps安全加固：Ops/SRE平台实战指南

场景

某金融客户的生产Kubernetes集群频繁出现未授权资源访问事件。SRE团队需要立即实施安全加固。

症状

• 非管理员用户能列出集群机密
• 发现来自可疑IP的出站网络连接
• kubeconfig文件泄露导致攻击者执行命令

诊断

1. 检查RBAC绑定：kubectl get clusterrolebinding,rolebinding -A -o wide
2. 审计网络策略：kubectl get networkpolicy -A
3. 验证密钥存储：kubectl get secrets -A | grep -v default-token

命令

收紧RBAC

kubectl create clusterrole restrict-secrets --verb=get,list,watch --resource=secrets --resource-name= # 仅允许特定机密
kubectl create clusterrolebinding restrict-secrets-binding --clusterrole=restrict-secrets --user=developer

启用网络策略

# default-deny.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

kubectl apply -f default-deny.yaml

轮换密钥

kubectl delete secret my-app-secret
kubectl create secret generic my-app-secret --from-literal=password=$(openssl rand -base64 32)

风险控制

• 先在小范围金丝雀命名空间测试网络策略
• 创建RBAC角色前导出当前绑定快照：kubectl get clusterrolebinding -o yaml > rbac-backup.yaml
• 密钥轮换期间确保应用程序支持热重载，否则需要协调重启

回滚

kubectl delete clusterrole restrict-secrets
kubectl delete clusterrolebinding restrict-secrets-binding
kubectl delete networkpolicy default-deny-all
kubectl apply -f rbac-backup.yaml

验证

kubectl auth can-i list secrets --as=developer  # 应返回no
kubectl exec test-pod -- curl -I http://evil.com  # 应超时
kubectl get secret my-app-secret -o jsonpath='{.data.password}' | base64 -d | wc -c  # 应为32

何时提交OpsGlobal工单

• 安全漏洞（如CVE）影响运行组件，需紧急热修复
• 内部审计发现严重配置错误，超出团队能力
• 集群在加固后出现大面积服务中断，无法通过回滚恢复
• 需要外部专家进行红蓝对抗演习或合规评审