OpenTelemetry Demo在OpenShift环境中的权限问题分析与解决方案

问题背景

在使用OpenTelemetry Helm Charts部署演示环境时，许多用户在OpenShift平台上遇到了一个典型问题：Grafana仪表板无法显示OpenTelemetry Collector的监控指标数据。经过排查发现，这实际上是一个Kubernetes RBAC权限配置问题。

现象表现

当用户按照官方文档在OpenShift 4.15.3环境中部署后，虽然所有Pod都正常运行，但Prometheus无法成功抓取指标数据。具体表现为：

1. Grafana的OpenTelemetry Collector仪表板没有数据
2. Prometheus的服务发现页面为空
3. Prometheus Pod日志中显示权限拒绝错误，提示服务账号没有权限列出Pod资源

根本原因分析

在OpenShift环境中，默认的安全策略比普通Kubernetes更为严格。当使用自定义服务账号（opentelemetry-demo）部署时，该账号缺少必要的查看(view)角色权限。具体来说：

1. Prometheus需要list和watch Pod的权限来实现服务发现
2. 默认安装时虽然禁用了RBAC创建(prometheus.rbac.create=false)，但没有为现有服务账号授予足够权限
3. OpenShift的Security Context Constraints(SCC)虽然通过anyuid策略解决了容器运行权限问题，但没有解决API访问权限问题

解决方案

经过验证，可以通过以下命令解决问题：

oc policy add-role-to-user view -z opentelemetry-demo

这个命令的作用是：

1. 将OpenShift内置的view角色授予opentelemetry-demo服务账号
2. view角色包含读取集群资源的基本权限，满足Prometheus的服务发现需求
3. -z参数表示操作对象是服务账号

最佳实践建议

对于在OpenShift上部署OpenTelemetry Demo的用户，建议：

1. 在安装前预先创建服务账号并配置权限
2. 对于生产环境，建议创建更精细化的Role和RoleBinding，而不是直接使用view角色
3. 考虑使用以下安装顺序：
   • 创建项目和服务账号
   • 配置SCC策略
   • 授予RBAC权限
   • 最后部署Helm Chart

技术延伸

这个问题反映了OpenShift与普通Kubernetes在安全模型上的差异。OpenShift默认启用了更严格的安全控制，包括：

1. 默认拒绝所有未明确允许的API访问
2. 使用SCC控制Pod级别的安全属性
3. 内置角色的权限范围有所不同

理解这些差异对于在OpenShift上成功部署云原生监控系统至关重要。类似的权限问题也可能出现在其他监控组件如Thanos或VictoriaMetrics的部署过程中。

总结

通过合理配置RBAC权限，可以解决OpenTelemetry Demo在OpenShift环境中的监控数据采集问题。这个案例也提醒我们，在将云原生应用迁移到不同Kubernetes发行版时，需要特别注意平台特定的安全策略差异。