Kiali项目中Cypress测试在FIPS集群上的PodSecurity问题解析

在Kiali项目的最新版本测试过程中，开发团队发现了一个与OpenShift 4.18 EC2 FIPS集群相关的重要兼容性问题。这个问题直接影响了Kiali的核心测试流程，特别是Cypress端到端测试和部分集成测试功能的正常执行。

问题现象

当在启用了FIPS的OpenShift 4.18 EC2集群上运行Kiali测试套件时，系统会抛出PodSecurity策略违规警告。具体表现为：

1. Cypress测试启动失败：测试所需的sleep应用无法进入就绪状态，因为traffic-generator容器违反了多项PodSecurity限制
2. 集成测试失败：TestDiscoverWorkload测试用例中的bookinfo应用部署被拒绝，details和reviews服务容器同样违反了PodSecurity策略

系统给出的详细错误信息指出了四个关键的安全策略违规点：

• 未禁用特权升级(allowPrivilegeEscalation未设置为false)
• 未限制容器能力(未设置capabilities.drop=["ALL"])
• 未以非root用户运行(未设置runAsNonRoot=true)
• 未配置seccomp安全策略(未设置seccompProfile.type)

技术背景

这个问题本质上源于OpenShift 4.18对PodSecurity标准的严格实施。PodSecurity是Kubernetes提供的一种安全准入控制机制，它定义了三个安全级别：

1. 特权级(Privileged)：无限制，提供最大范围的权限
2. 基线级(Baseline)：防止已知的特权升级，同时保持应用兼容性
3. 严格级(Strict)：遵循当前Pod安全的最佳实践

OpenShift 4.18 FIPS集群默认实施了最严格的"strict:latest"策略，而Kiali测试中使用的部分容器镜像(如traffic-generator和bookinfo组件)缺乏必要的安全上下文配置，导致部署被拒绝。

解决方案

开发团队针对这个问题实施了多层次的修复方案：

1. 为测试容器添加完整的安全上下文：在所有测试相关的Pod定义中，显式配置了：

   • allowPrivilegeEscalation: false
   • capabilities.drop: ["ALL"]
   • runAsNonRoot: true
   • seccompProfile.type: RuntimeDefault

2. 多版本兼容性处理：修复被同时应用到多个Kiali版本分支：

   • 主分支(main)
   • 1.73稳定版分支
   • 1.65稳定版分支

3. 上游Istio安装流程适配：同步修复了通过istioctl安装Istio时Grafana/Prometheus组件的SCC(安全上下文约束)问题

实施效果

通过这些修复，Kiali测试套件现在可以：

• 在FIPS强化的OpenShift 4.18集群上顺利运行
• 满足最严格的PodSecurity严格级要求
• 保持与不同版本OpenShift的兼容性
• 不影响原有测试功能和覆盖范围

这一改进不仅解决了当前的测试问题，还提升了Kiali在安全敏感环境中的部署能力，为产品在特定行业中的采用扫清了技术障碍。