Kubernetes Dashboard 通过 Ingress 认证失败的解决方案

在 Kubernetes 集群中部署 Dashboard 时，许多用户会遇到通过 Ingress 访问时的认证问题。本文将深入分析问题根源并提供经过验证的解决方案。

问题现象

当用户尝试通过 Ingress 访问 Kubernetes Dashboard 时，常见会遇到以下错误提示：

Unknown error (200): Http failure during parsing for https://kubernetes-dashboard.svc.internal/#/login

这个错误看似矛盾 - HTTP 状态码 200 表示请求成功，但实际上认证流程却中断了。这种情况通常发生在 Ingress 配置与 Dashboard 服务之间的兼容性问题上。

根本原因分析

经过技术验证，发现主要问题出在以下几个方面：

1. 服务端点选择不当：用户不确定应该使用 kubernetes-dashboard-kong-proxy 还是 kubernetes-dashboard-web 作为后端服务

2. CSRF 保护机制：Dashboard 默认启用的 CSRF 保护可能与某些 Ingress 配置产生冲突

3. Ingress 配置不完整：缺少必要的注解或路径配置

4. 认证流程中断：Token 认证过程在 Ingress 层被截断

推荐解决方案

方案一：使用 Helm Chart 内置 Ingress 配置

这是最可靠的解决方案，配置示例如下：

app:
  ingress:
    enabled: true
    hosts:
    - kubernetes-dashboard.svc.internal
    useDefaultIngressClass: true
    issuer:
      name: <your-cluster-issuer>
      scope: cluster

关键配置说明：

• enabled: true 启用内置 Ingress 支持
• 明确指定访问域名
• 使用集群范围的 Issuer 自动管理 TLS 证书

方案二：手动配置 Ingress 的注意事项

如果必须自定义 Ingress，请注意以下要点：

1. 后端服务选择：应该使用 kubernetes-dashboard-web 服务的 web 端口

2. CSRF 保护：在 Dashboard 启动参数中添加 --disable-csrf-protection=true

3. 路径配置：确保路径规则正确匹配所有前端路由

4. TLS 配置：确保证书由可信 CA 签发，避免浏览器安全警告

最佳实践建议

1. 避免使用 kubectl proxy：生产环境应该通过 Ingress 暴露服务

2. 保持配置简洁：优先使用 Helm Chart 原生支持的功能

3. 安全注意事项：

   • 限制 Ingress 访问源 IP
   • 启用双向 TLS 认证
   • 定期轮换访问令牌

4. 监控配置：设置适当的健康检查和监控端点

总结

Kubernetes Dashboard 通过 Ingress 暴露时，推荐使用 Helm Chart 原生的 Ingress 支持功能。这能确保所有必要的配置项被正确设置，避免认证流程中断。对于高级用户，如果必须自定义 Ingress，则需要特别注意后端服务选择和 CSRF 保护配置。

通过遵循上述建议，用户可以建立稳定可靠的 Dashboard 访问通道，同时满足企业级安全要求。记住，简单的解决方案往往是最可靠的，过度定制化可能会引入不必要的复杂性。