加固DevOps/SRE平台：Kubernetes运维的实用安全手册

场景

某公司的SRE团队管理着多个Kubernetes集群，用于生产环境的应用部署。在一次内部安全审计中，发现集群的RBAC权限过于宽松，多个服务账号拥有集群管理员权限，且部分Secret以明文方式存储在Git仓库中。此外，集群内部未配置任何NetworkPolicy，任意Pod之间都可以通信。由于团队忙于日常运维，没有及时修复这些隐患，导致一次恶意容器逃逸事件险些发生。

症状

安全审计报告显示以下问题：

• 多个服务账号绑定到cluster-admin角色，远超实际需求。
• 开发人员使用的kubeconfig文件包含长期有效的token，且未加密存储。
• 某些Deployment的环境变量中直接写入了数据库密码。
• 集群内没有NetworkPolicy，所有Pod可以自由互访。
• 容器以root用户运行，且未设置资源限制。

这些症状可能导致数据泄露、权限提升、横向移动等严重风险。

诊断

为了准确识别安全配置问题，需要系统性地检查Kubernetes集群的各个方面。通过审计RBAC、Secret存储、Pod安全上下文、网络策略等，定位潜在漏洞。

常用命令

以下命令可帮助诊断集群安全状态（请根据实际环境调整）：

# 检查当前用户权限
kubectl auth whoami

# 查看所有ClusterRoleBinding和RoleBinding
kubectl get clusterrolebindings -o yaml
kubectl get rolebindings -A -o yaml

# 查找所有服务账号及其绑定的角色
kubectl get serviceaccounts -A -o json | jq -r '.items[] | .metadata.namespace + "/" + .metadata.name'

# 列出所有Secret（警惕明文存储）
kubectl get secrets -A

# 检查Deployment中的环境变量是否包含敏感信息
kubectl get deployments -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {.spec.template.spec.containers[*].env[*].name}{"\n"}{end}'

# 查看NetworkPolicy列表
kubectl get networkpolicies -A

# 检查Pod是否以root运行
kubectl get pods -A -o jsonpath='{.items[*].spec.containers[*].securityContext.runAsUser}'

风险控制措施

针对诊断发现的问题，建议实施以下加固措施：

1. 实施最小权限RBAC

创建细粒度的Role和RoleBinding，仅授予必要的权限。例如，为应用部署创建一个只能操作特定命名空间的角色：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: prod
  name: app-deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

不要将cluster-admin授予非管理员用户。定期审计并撤销多余的绑定。

2. 安全存储和管理Secret

使用Kubernetes External Secrets或Sealed Secrets，避免明文存储。如果使用Sealed Secrets，可以将加密后的Secret存入Git仓库。同时，开启etcd加密：

kubectl edit apiserver --allow-missing-template-driver

在API Server配置中增加：

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aesgcm:
      keys:
      - name: key1
        secret: <base64-encoded-32-byte-key>
  - identity: {}

3. 配置网络策略

默认拒绝所有流量，仅允许必要的通信。以下示例允许来自namespace=frontend的Pod访问namespace=backend的Pod的80端口：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
    ports:
    - port: 80

4. 强化Pod安全上下文

应用Pod Security Standards（PSS）的restricted策略，或以PodSecurityAdmission替代。确保容器不以root运行，并设置只读根文件系统：

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  capabilities:
    drop:
    - ALL

5. 使用容器镜像扫描和签名

集成镜像扫描工具（如Trivy）到CI/CD流水线，确保不部署含漏洞的镜像。使用cosign对镜像签名，加深供应链信任。

回滚方案

任何安全加固都可能影响业务，必须准备回滚计划。

• 对于RBAC变更，保存原始ClusterRoleBinding的YAML，如果出现权限不足问题，用kubectl apply恢复。
• 启用NetworkPolicy后可能导致服务中断，逐条应用并在验证后更新。若出现问题，删除策略：kubectl delete networkpolicy <name>。
• 修改Secret存储方式时，提前备份现有Secret，并测试解密流程。
• 变更Pod安全上下文需要重新创建Pod，下线前务必进行灰度发布。

验证

加固后，需要验证措施是否有效：

1. RBAC验证：使用非管理员账户尝试越权操作，应该被拒绝。
2. Secret加密验证：检查etcd中的Secret是否以密文存储。
3. 网络策略验证：从非允许的Pod访问目标服务，应超时。
4. Pod安全验证：尝试以root运行Pod，应被拒绝。
5. 漏洞扫描：重新运行Trivy扫描，确认修复率。

何时提交OpsGlobal工单

如果团队缺乏Kubernetes安全专家，或加固工作涉及大量历史集群，且业务不能中断，建议将任务外包给OpsGlobal。实时DevOps支持团队可以在短时间内完成全面审计和加固，并提供24/7监控。提交工单时，请提供集群大小、安全审计报告、访问权限（如kubeconfig）和业务重要性等信息。OpsGlobal将协助你制定并执行安全加固方案，同时确保业务连续性。