Grafana OnCall API中滚动用户验证机制的缺陷分析

在Grafana OnCall的日常运维中，我们发现了其公开API在处理oncall-shift创建时存在一个值得注意的安全隐患——当通过API创建轮班(shift)时，系统未能正确验证rolling_users字段中提供的用户ID是否真实有效。这一问题可能导致后续调度系统出现不可预期的行为，值得运维团队和开发者高度关注。

问题现象

通过Terraform配置创建OnCall轮班时，即便在rolling_users数组中填入明显无效的用户标识（如"foo"、"bar"等字符串），系统仍然会接受并创建该轮班配置。从返回的JSON数据可以看到，这些无效用户被存储为"{}"空对象，而不是触发验证错误。

技术影响

这种验证缺失会带来几个潜在风险：

1. 调度系统失效：当轮班实际触发时，系统可能无法正确分配值班人员，导致告警无人响应
2. 数据一致性问题：数据库中存储了无效的用户引用，长期积累可能导致数据污染
3. 运维困惑：管理员在界面上看到配置成功，但实际功能异常，增加故障排查难度

底层机制分析

从返回的数据库记录可以看出，系统将无效用户存储为"{}"空对象，这表明：

1. 后端服务在接收API请求时，没有对用户ID进行存在性校验
2. 数据序列化/反序列化过程中，无效用户被转换为空对象而非抛出异常
3. 数据库约束可能过于宽松，允许存储这些无效引用

解决方案建议

对于使用Grafana OnCall的团队，建议采取以下措施：

1. 前端验证：在使用Terraform等工具配置时，自行添加用户存在性检查
2. 监控机制：建立定期检查任务，扫描轮班配置中的无效用户引用
3. 等待官方修复：关注Grafana OnCall的版本更新，该问题已在最新提交中被修复

最佳实践

在实际运维中，对于关键系统如值班调度，建议：

1. 实施配置预检查流程，在应用前验证所有引用完整性
2. 建立配置审计机制，定期检查系统状态的健康度
3. 对于自动化工具生成的配置，增加验证步骤确认资源创建符合预期

该问题的发现提醒我们，在使用API自动化管理关键系统时，不能完全依赖服务端的验证机制，客户端也应建立适当的防御性编程措施，确保系统配置的完整性和可靠性。