Holos项目中基于Istio的多阶段认证架构实践

Holos项目中基于Istio的多阶段认证架构实践

holos Holistic platform manager 项目地址: https://gitcode.com/gh_mirrors/hol/holos

背景介绍

在现代云原生应用开发中，认证授权机制是保障系统安全的重要组成部分。Holos项目采用了一套基于Istio服务网格的多阶段认证架构，通过OAuth2 Proxy与Istio的深度集成，实现了灵活且安全的认证授权方案。

架构设计

该认证系统采用分层设计，主要包含以下几个关键组件：

1. 命名空间隔离：系统为每个环境阶段(prod/dev)创建独立的系统命名空间(如prod-example-system)，同时为每个具体环境(如jeff-example)创建工作负载命名空间。

2. 证书管理：为每个网关配置TLS证书，包括全局证书(example.example.com)和集群特定证书(example.k1.example.com)。

3. 网关配置：在istio-ingress命名空间中为每个阶段配置Gateway资源，处理该阶段所有环境的流量。

4. 服务部署：

   • 每个环境部署httpbin服务用于测试和调试
   • 每个阶段部署oauth2-proxy+redis组合服务

5. 路由设计：采用路径前缀(/holos/oidc)路由到认证服务，回调路径为/holos/oidc/callback。

关键技术实现

认证服务集成

系统通过Istio的ExtAuthzHttp扩展提供者实现外部认证集成。值得注意的是，由于Istio的限制，每个工作负载只能附加一个ExtAuthzHttp提供者，因此阶段提供者需要附加到环境命名空间中的后端工作负载，而非入口网关。

多域名支持

单个oauth2-proxy实例可以处理多个域名的认证请求。通过配置多个VirtualService，将不同域名的认证请求路由到同一认证服务。例如：

• holos.jeff.ois.run
• holos.jeff.k1.ois.run
• holos.jeff.k2.ois.run

对应的认证服务域名为：

• auth.jeff.ois.run
• auth.jeff.k1.ois.run
• auth.jeff.k2.ois.run

域名结构设计

系统采用层次化的域名结构：<env?>.<project>.<stage?>.<cluster?>.<domain>。其中env对于prod阶段或dev阶段的默认环境可省略，stage对于prod阶段可省略，cluster对于全局端点可省略。

安全策略配置

在环境命名空间中配置了多层安全策略：

1. RequestAuthentication规则：验证JWT令牌
2. AuthorizationPolicy CUSTOM规则：自定义授权策略
3. 默认拒绝规则：遵循最小权限原则
4. 组允许规则：基于用户组的访问控制

实现细节与挑战

认证令牌处理

在集成ZITADEL认证系统时，发现其访问令牌不符合JWT标准格式，导致Istio的RequestAuthentication规则验证失败。解决方案是对认证流程进行调整，确保令牌格式兼容。

网关授权策略

系统设计中需要特别注意，入口网关只能有一个CUSTOM AuthorizationPolicy提供者，这需要在架构设计时进行合理规划。

调试支持

为方便问题排查，系统在每个环境的主机名上配置了/dump/request路径路由到httpbin服务。这样既不影响主应用功能，又提供了便捷的调试接口。

总结

Holos项目的这套认证架构通过Istio与OAuth2 Proxy的深度集成，实现了灵活的多阶段、多环境认证方案。其分层设计和清晰的域名结构使得系统既安全可靠，又便于维护扩展。在实践中遇到的技术挑战，如令牌格式兼容性和网关授权策略限制，都通过合理的设计决策得到了解决。这套架构为类似规模的云原生应用提供了可借鉴的认证授权实现方案。

holos Holistic platform manager 项目地址: https://gitcode.com/gh_mirrors/hol/holos