强化Kubernetes集群的SRE运维实践指南

场景

一家快速成长的初创公司将生产环境部署在Kubernetes集群上，但初始配置使用了默认的RBAC设置和宽松的网络策略。某天，安全团队在审计日志中发现来自外部IP的异常API调用，怀疑存在未授权访问。

症状

• 审计日志显示kubectl get secrets等敏感操作来自非预期用户。
• 部分Pod可以访问其他命名空间的资源。
• 服务账户权限过大，例如默认default服务账户绑定了cluster-admin角色。

诊断

1. 检查RBAC绑定：使用kubectl get clusterrolebindings -o wide和kubectl get rolebindings --all-namespaces -o wide列出所有绑定。
2. 验证权限：kubectl auth can-i --list --as=system:serviceaccount:default:default确认服务账户的权限。
3. 审计网络策略：kubectl get networkpolicies --all-namespaces查看是否存在允许所有流量的策略。
4. 审查Pod安全策略：kubectl get psp检查是否未定义或过于宽松。

加固命令

# 删除危险的cluster-admin绑定
kubectl delete clusterrolebinding default-admin

# 创建最小权限服务账户
kubectl create serviceaccount my-app -n production
kubectl create role my-app-role --verb=get,list,watch --resource=pods,services -n production
kubectl create rolebinding my-app-binding --role=my-app-role --serviceaccount=production:my-app -n production

# 应用默认拒绝网络策略
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF

# 启用审计日志（如果尚未启用）
audit-policy.yaml:
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse

风险控制

• 修改RBAC前备份现有配置：kubectl get clusterrolebindings -o yaml > clusterrolebindings-backup.yaml
• 在非生产集群测试网络策略的影响。
• 逐步收紧权限，避免部分服务中断。

回滚计划

如果加固导致合法请求失败：

kubectl apply -f clusterrolebindings-backup.yaml
kubectl delete networkpolicy default-deny

重新应用宽松策略并记录受影响的服务。

验证

• 重新运行诊断命令，确认敏感操作被拒绝。
• 使用kubectl auth can-i list secrets --as=system:serviceaccount:default:default应返回no。
• 检查审计日志确认未授权调用被记录。

何时提交工单

• 内部团队对RBAC最佳实践不熟悉，需要专家设计最小权限模型。
• 集群已遭到入侵，需进行取证分析和应急响应。
• 需要实施高级安全控制（如OPA/Gatekeeper、kube-bench扫描）但缺乏经验。
• 建议联系OpsGlobal（support@opsglobal.com）以获得7x24小时远程SRE支持。