场景：集群中出现未经身份验证的 API 调用

您的 SIEM 系统发出关于 Kubernetes API 服务器可疑 API 调用的警报。审计日志显示来自 system:anonymous 的请求，对部署和命名空间执行了 delete 和 update 等操作。更糟糕的是，有未知 IP 正在拉取机密信息。

症状

• kubectl get events --all-namespaces 显示未经授权的修改。
• 审计日志（如果启用）显示匿名请求获得成功响应。
• 一些生产环境的部署已被更改。
• 您的安全团队怀疑发生了数据泄露。

诊断

首先，确认 API 服务器的授权模式和匿名设置：

kubectl get --raw /api/v1/namespaces/kube-system/configmaps | grep -i anonymous

如果无法获取审计日志，请检查绑定：

kubectl get clusterrolebindings,rolebindings -A -o yaml | grep -B2 -A10 "system:anonymous"

检查匿名用户可以执行哪些操作：

kubectl auth can-i --list --as system:anonymous

审计和加固命令

列出所有关联了匿名用户的绑定：

kubectl get clusterrolebinding,rolebinding -A -o json | jq '.items[] | select(.subjects[]?.name=="system:anonymous")'

删除危险的绑定（替换 <binding-name>）：

kubectl delete clusterrolebinding <binding-name> --dry-run=client -o yaml > backup.yaml
kubectl delete clusterrolebinding <binding-name>

应用额外的加固措施：

# 启用 Pod 安全准入（示例：强制执行 baseline/默认策略）
kubectl label --overwrite ns --all pod-security.kubernetes.io/enforce=baseline

风险控制

• 执行最小权限 RBAC：移除匿名和过宽的绑定；使用用户组和服务账户。
• 启用审计日志：转发到 SIEM。
• 使用网络策略：限制 Pod 之间的通信和出口流量。
• 禁用匿名访问：如果不需要未认证的健康检查端点，可设置 --anonymous-auth=false。
• 轮换所有凭据：如果怀疑已被入侵。

回滚

如果删除绑定导致某些功能异常（例如监控代理失去访问权限），可从备份重新应用：

kubectl apply -f backup.yaml

回滚后测试连通性。

验证

确认匿名用户无法读取机密：

kubectl auth can-i --list --as system:anonymous | grep -i secret
# 应该显示无法 get/list secrets，或显示 "no"

模拟匿名请求：

curl -ks https://$(kubectl get svc kubernetes -n default -o jsonpath='{.spec.clusterIP}'):443/api/v1/secrets
# 预期返回：403 Forbidden

何时提交 OpsGlobal 工单

如果您缺乏时间或专业知识进行全面安全审计，无法识别所有受影响的路径，或需要取证分析，请提交工单。OpsGlobal 的 SRE 安全专家可以帮助您加固平台、实施最佳实践的 RBAC，并建立持续的安全监控。