Kiali项目增强：支持通过Secrets配置认证用户名和自定义仪表盘认证

在Kiali项目的最新更新中，团队实现了对认证用户名和自定义仪表盘认证信息通过Kubernetes Secrets进行配置的支持。这一改进显著提升了Kiali的安全性和灵活性，使管理员能够更好地管理敏感凭证。

背景与动机

在分布式系统监控领域，Kiali作为Istio服务网格的可视化工具，需要与多种后端服务（如Prometheus、Grafana和Tracing系统）进行交互。这些交互通常需要认证信息，包括用户名和密码等敏感数据。

过去版本中，Kiali已经支持将密码、令牌和签名密钥等敏感信息存储在Kubernetes Secrets中，但用户名仍需要明文配置在Kiali CR（Custom Resource）中。虽然用户名本身不如密码敏感，但对于安全要求严格的环境，任何形式的明文凭证都可能成为安全隐患。

新增功能特性

本次更新主要扩展了Kiali的Secret支持范围，新增了以下配置项：

1. 外部服务认证用户名支持：

   • Grafana认证用户名
   • Prometheus认证用户名
   • Tracing系统认证用户名

2. 自定义仪表盘认证全面支持：

   • Prometheus用户名
   • Prometheus密码
   • Prometheus令牌

这些新增功能使得Kiali的认证配置更加完整和安全，管理员现在可以将所有认证相关的敏感信息都存储在Kubernetes Secrets中，实现统一的凭证管理策略。

技术实现细节

在底层实现上，Kiali团队对配置解析逻辑进行了扩展，使其能够从指定的Secret中读取用户名等新增支持的字段。这一改动保持了与现有Secret集成机制的一致性，确保配置方式的统一和直观。

对于自定义仪表盘的Prometheus认证，现在支持完整的认证信息配置，包括：

• 基础认证（用户名+密码）
• Bearer令牌认证
• 自定义CA证书（通过现有机制）

安全最佳实践

随着这一功能的加入，我们建议Kiali管理员采用以下安全实践：

1. 最小权限原则：确保用于存储认证信息的Secrets只对必要的服务账户开放访问权限。

2. 定期轮换：建立定期轮换存储在Secrets中的凭证的流程，包括用户名（当用户名也作为认证因素时）。

3. 审计跟踪：监控和记录对包含Kiali认证信息的Secrets的访问。

4. 分层防御：结合Kubernetes RBAC、网络策略和其他安全机制，构建多层次的防护体系。

升级与兼容性

这一改进完全向后兼容。现有配置无需修改，新功能是可选的。管理员可以选择继续使用明文配置用户名，或者迁移到更安全的Secret存储方式。

对于希望升级到Secret存储的管理员，迁移过程简单直接：

1. 创建包含用户名的Secret
2. 更新Kiali CR引用该Secret
3. 删除CR中的明文用户名

未来展望

Kiali团队持续关注安全领域的实践发展，未来可能会进一步扩展Secret支持的范围，包括：

• 更多外部服务的认证选项
• 动态凭证获取机制
• 与云原生Secret管理解决方案的深度集成

这一更新体现了Kiali项目对安全性的持续承诺，为服务网格可视化工具设立了更高的安全标准。通过将更多认证因素纳入Secret管理，Kiali为运行在敏感环境中的服务网格提供了更强的安全保障。