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

场景：CI/CD 管道中的隐藏风险

假设你的 SRE 团队管理着一个 Kubernetes 集群，上面运行着 Jenkins、Argo CD 和 Prometheus 等 DevOps 工具。在一次季度安全审计中，你发现多个 Pod 仍在使用默认 ServiceAccount，而该账号拥有 cluster-admin 权限。同时，集群中没有 NetworkPolicy，密钥以明文环境变量的形式注入。这意味着，一旦某个应用被攻破，攻击者就能在短期内窃取云服务商凭据并横向移动。

症状：应该关注什么

• 审计日志中出现大量来自异常 IP 的 API 请求。
• 某些 ServiceAccount 尝试访问未授权资源，被 RBAC 拒绝后反复重试。
• 安全扫描报告显示存在“严重”或“高危”漏洞，尤其是与权限提升相关的 CVE。
• 合规审计（如 PCI-DSS、SOC2）发现控制项缺失。

诊断：找出薄弱点

使用 kubectl 进行系统检查。

# 列出所有角色绑定和集群角色绑定
kubectl get rolebindings,clusterrolebindings -o wide

# 检查特定 ServiceAccount 的实际权限
kubectl auth can-i --list --as=system:serviceaccount:development:jenkins

# 查看命名空间中的 ServiceAccount
kubectl get serviceaccounts -n development

# 找出以特权模式运行的 Pod
kubectl get pods -n development -o json | jq '.items[] | select(.spec.containers[]?.securityContext?.privileged == true) | .metadata.name'

# 验证 NetworkPolicy 是否存在
kubectl get networkpolicies -n development

如果结果为空或显示默认绑定，说明存在明显加固空间。

加固步骤：从理论到命令

1. 最小权限 RBAC

为每个应用创建专用 ServiceAccount，并仅授予所需资源的最小权限。

kubectl create serviceaccount jenkins -n development
kubectl create role jenkins-role --verb=get,list,watch --resource=pods,deployments -n development
kubectl create rolebinding jenkins-rolebinding --serviceaccount=development:jenkins --role=jenkins-role -n development

2. 强制 Pod 安全标准（PSS）

给命名空间打上标签，启用 restricted 模式。

kubectl label namespace development pod-security.kubernetes.io/enforce=restricted

3. 默认拒绝的 NetworkPolicy

先创建一个拒绝所有流量的策略，再添加白名单。

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

kubectl apply -f deny-all.yaml

然后按需放行特定端口和来源。

4. 使用 Secrets Store CSI 驱动

将密钥以卷形式挂载，而不是环境变量。参考 Secrets Store CSI 文档配置。

5. 启用审计日志

在 API Server 启动参数中加入 --audit-log-path 和 --audit-policy-file，并将日志转发至 SIEM。

6. 部署 OPA Gatekeeper

使用 Gatekeeper 强制实施策略，比如禁止镜像标签为 :latest 或禁止挂载 Docker Socket。

风险控制：多层防御

• 修改前备份 etcd： etcdctl snapshot save snapshot.db
• 采用 GitOps 流程，所有变更通过 Git 提交，使用 Argo CD 或 Flux 同步。
• 开启变更审批，重要操作需要双人复核。
• 对镜像进行签名和扫描，确保来源可信。

回滚策略：安全网

• 如果是通过 kubectl 直接应用，保存旧的 YAML，使用 kubectl rollout undo 或重新 apply 旧版本。
• 如果使用 GitOps，则通过 Git revert 回滚到上一个提交，Argo CD 会自动同步。
• 紧急情况下，可以从 etcd 快照恢复集群到加固前状态。

验证：证明它有效

• 运行 CIS 基准测试： kube-bench run
• 使用 kubeaudit 检测错误配置： kubeaudit all
• 模拟攻击：尝试用 jenkins ServiceAccount 删除其他命名空间下的 Pod，确认被拒绝。
• 检查 NetworkPolicy：从外部尝试访问服务，确认被拦截。
• 复查审计日志，确认没有异常条目。

何时提交 OpsGlobal 工单

如果你面临以下情况，建议提交 OpsGlobal 工单：

• 团队缺乏时间或经验进行全面的安全加固。
• 需要满足特定合规认证（如 PCI-DSS、HIPAA），且内部无法快速完成。
• 已经发现疑似入侵事件，需要紧急响应和取证支持。
• 希望获得第三方独立审计，验证加固效果。

OpsGlobal 的远程 DevOps/SRE 专家能够快速执行上述步骤，并在不中断业务的前提下提升安全态势。

安全提示： 所有命令都应先在测试集群中执行，确保不影响生产环境。备份是关键，永远不要在没有备份的情况下修改 RBAC 或网络策略。