传统的安全模型基于“边界防御”——防火墙保护网络边界内部网络默认是“可信的”。但在微服务架构中服务之间的通信大量发生在内部网络中攻击者一旦突破边界就可以在内部自由横向移动。零信任Zero Trust 模型彻底颠覆了这一假设——它默认“永不信任始终验证”。Istio 通过 mTLS双向 TLS 、PeerAuthentication 和 AuthorizationPolicy将零信任安全能力下沉到基础设施层让服务间通信自动实现加密、认证和细粒度授权无需修改任何业务代码。本文深入讲解 Istio 安全架构的三大核心组件并通过实战配置带你体验从“明文通信”到“零信任安全”的完整升级过程。一、Istio 安全架构概览Istio 的安全体系由三个层次构成这三个层次共同构成了零信任安全的完整闭环加密所有服务间通信默认加密mTLS。身份认证每个服务拥有由 Istio 签发的 SPIFFE 身份证书通信双方互相验证对方身份。授权基于服务身份执行细粒度的访问控制策略。二、mTLS 与 PeerAuthentication服务身份认证mTLS双向 TLS 是零信任安全的基石。它要求通信双方都持有有效的证书在建立连接时互相验证对方身份并协商加密密钥。Istio 为每个工作负载自动签发由 SPIFFE 标准定义的身份证书格式为 spiffe://cluster.local/ns//sa/。2.1 mTLS 的三种模式PeerAuthentication 资源控制 mTLS 的模式默认的 PERMISSIVE 模式是为了让迁移过程平滑——新加入的服务可以逐步开启 mTLS而不影响存量服务。2.2 配置 PeerAuthentication全局启用 STRICT mTLS在 istio-system 命名空间配置apiVersion:security.istio.io/v1beta1kind:PeerAuthenticationmetadata:name:mesh-wide-strictnamespace:istio-systemspec:mtls:mode:STRICT 生产建议完成迁移后建议将全局模式切换为 STRICT确保所有服务间通信都是加密且经过身份认证的。命名空间级别的 mTLS 策略apiVersion:security.istio.io/v1beta1kind:PeerAuthenticationmetadata:name:defaultnamespace:productionspec:mtls:mode:STRICT工作负载级别的 mTLS 策略优先级高于命名空间级别apiVersion:security.istio.io/v1beta1kind:PeerAuthenticationmetadata:name:finance-policynamespace:productionspec:selector:matchLabels:app:financemtls:mode:STRICT生效优先级端口级别 工作负载级别 命名空间级别 全局级别。2.3 验证 mTLS 是否生效方法一检查 Envoy 配置# 查看某个 Pod 的 Envoy 监听器配置istioctl proxy-config listenerpod-name-ojson|grep-itls方法二查看 PeerAuthentication 状态# 检查当前生效的 PeerAuthentication 策略kubectl get peerauthentication-A方法三通过访问日志确认在 Envoy 访问日志中如果 mTLS 生效connection_termination_details 字段会显示 TLS 相关信息。三、AuthorizationPolicy细粒度访问控制如果说 mTLS 是“谁能说话”那么 AuthorizationPolicy 就是“谁能对谁说什么话”。授权策略在 mTLS 身份认证的基础上执行基于身份的访问控制。授权策略支持三种操作类型如果一个请求同时匹配了 DENY 和 ALLOW 规则DENY 会优先生效。3.1 配置 AuthorizationPolicy示例一允许特定服务访问以下策略只允许 sleep 服务使用 cluster.local/ns/default/sa/sleep 身份访问 httpbin 服务apiVersion:security.istio.io/v1beta1kind:AuthorizationPolicymetadata:name:allow-sleep-to-httpbinnamespace:defaultspec:action:ALLOWrules:-from:-source:principals:[cluster.local/ns/default/sa/sleep]to:-operation:methods:[GET]paths:[/info*]关键字段解读source.principals来源的服务身份格式为 cluster.local/ns//sa/。operation.methods / operation.paths允许的 HTTP 方法和路径。示例二拒绝来自特定命名空间的请求以下策略拒绝来自 dev 命名空间的所有 POST 请求apiVersion:security.istio.io/v1beta1kind:AuthorizationPolicymetadata:name:deny-dev-postnamespace:defaultspec:action:DENYrules:-from:-source:namespaces:[dev]to:-operation:methods:[POST]示例三基于 JWT 声明的授权结合 RequestAuthenticationJWT 认证和 AuthorizationPolicy可以实现基于用户身份的访问控制# 1. 启用 JWT 认证apiVersion:security.istio.io/v1beta1kind:RequestAuthenticationmetadata:name:jwt-authnamespace:defaultspec:selector:matchLabels:app:httpbinjwtRules:-issuer:https://accounts.google.comjwksUri:https://www.googleapis.com/oauth2/v3/certs---# 2. 授权策略只允许 admin 用户访问apiVersion:security.istio.io/v1beta1kind:AuthorizationPolicymetadata:name:require-adminnamespace:defaultspec:action:ALLOWrules:-when:-key:request.auth.claims[role]values:[admin]# 只有 JWT 中 roleadmin 的请求通过3.2 默认拒绝策略在 Istio 中如果没有配置任何 ALLOW 策略默认行为是允许所有。要实现“默认拒绝”的效果需要显式配置一个不匹配任何请求的 ALLOW 策略或者配置一个拒绝所有请求的 DENY 策略。实现默认拒绝的策略apiVersion:security.istio.io/v1beta1kind:AuthorizationPolicymetadata:name:deny-allnamespace:defaultspec:action:DENYrules:-from:-source:principals:[*]# 拒绝所有来源然后在需要放行的服务上配置明确的 ALLOW 策略来覆盖。四、安全策略的组合与优先级在 Istio 中安全策略的生效遵循明确的优先级规则CUSTOM DENY ALLOW如果同时存在多种类型的策略按此优先级判断。粒度越精细优先级越高工作负载级别 命名空间级别 全局级别。因此一个典型的“零信任”安全策略组合是全局 PeerAuthentication STRICT强制所有通信加密并验证身份。命名空间级别 AuthorizationPolicy DENY ALL默认拒绝所有访问。工作负载级别 AuthorizationPolicy ALLOW显式放行必要的服务间调用。五、安全策略的排错当授权策略导致请求被拒绝时可以通过以下方式排查查看 Envoy 访问日志中的 RBAC 信息在访问日志中response_flags 字段为 RBAC 表示请求被授权策略拒绝json{“response_code”: 403,“response_flags”: “RBAC”,“trace_id”: “xxx”}2. 开启 RBAC 调试日志在 Pod 注解中开启更详细的调试信息metadata:annotations:sidecar.istio.io/componentLogLevel:rbac:debug3. 检查生效的策略 bash# 查看命名空间下的所有 AuthorizationPolicykubectl get authorizationpolicy-A# 查看特定 Pod 的 Envoy 配置istioctl proxy-config all pod-name六、小结零信任安全模型永不信任始终验证。Istio 通过 mTLS 加密、身份认证和授权策略实现零信任。PeerAuthentication控制 mTLS 模式。PERMISSIVE 用于迁移STRICT 用于生产。SPIFFE 身份每个服务拥有 cluster.local/ns//sa/ 格式的身份标识。AuthorizationPolicy基于服务身份、JWT claims、IP 等条件执行细粒度访问控制。优先级规则CUSTOM DENY ALLOW精细策略覆盖粗粒度策略。