安全、Ambient 模式与对比

基于 Istio 1.22（Ambient GA）· 核于 2026-08

速查

• 零信任安全模型：Istio 默认假设「网络不可信」，用 mTLS + 授权策略保护所有服务间通信。三大安全能力：①身份（mTLS 双向证书认证，每服务一个 SPIFFE 身份）；②认证（RequestAuthentication 校验客户端 JWT）；③授权（AuthorizationPolicy 控制谁能调谁）。
• mTLS 双向认证：Sidecar 之间自动建立 mTLS——双方都验对方证书（由 istiod CA 签发，SPIFFE 格式身份如 spiffe://cluster.local/ns/default/sa/order-sa），通信全程加密。防窃听（加密）与伪造（双向验证书）。默认 PERMISSIVE 模式（接受加密也接受明文，便于迁移），生产建议 STRICT（只接受加密）。
• PeerAuthentication：控制 mTLS 模式——PERMISSIVE（过渡，加密明文都接受）/ STRICT（只加密）。按命名空间或工作负载粒度配置。
• AuthorizationPolicy：授权（谁能调谁）。声明式 ALLOW/DENY 规则，基于 principals（调用方身份）、namespaces、source IP、方法、路径等匹配。默认全部拒绝，需显式 ALLOW。
• RequestAuthentication：校验客户端请求的 JWT（JSON Web Token），验证签名与受众。常用于外部用户携带 JWT 访问 API。
• Ambient 模式 GA（1.22+）：去 Sidecar 的新架构——ztunnel（节点级 DaemonSet，Rust，L4 mTLS）+ waypoint（按需 Envoy，L7 流量管理）。分层按需：L4 加密人人有（ztunnel 轻量），L7 治理按需加（waypoint）。降低 Sidecar 模式的资源开销。
• ztunnel：每节点一个，Rust 写的轻量 L4 代理，做 mTLS 加密与 L4 路由。替代每 Pod 一个 Envoy 做基础加密。
• waypoint：按命名空间/服务按需部署的 Envoy（L7），需要 VirtualService 金丝雀/熔断等 L7 治理时才挂。不需要 L7 的服务只用 ztunnel。
• Sidecar vs Ambient：Sidecar（每 Pod 一个全功能 Envoy，资源重但功能全，成熟）/ Ambient（节点级 ztunnel + 按需 waypoint，资源轻，1.22 GA，未来方向）。两者在 1.22+ 共存可逐命名空间迁移。
• vs Linkerd：Istio（Envoy/C++，功能全重型，Ambient 降开销）/ Linkerd（自研 Rust 代理，轻量易用，功能少）。重度流量治理选 Istio，极简高性能选 Linkerd。

一、零信任与 mTLS

传统安全模型是「边界信任」——内网默认可信，只在边界（防火墙/网关）做防护。一旦攻击者突破边界（或内网有被 compromise 的服务），内网服务间通信可被窃听与伪造。零信任反其道：「永不信任，持续验证」——内网也不可信，所有通信都要认证与加密。Istio 用 mTLS 实现服务间零信任：

   服务 A 的 Sidecar                 服务 B 的 Sidecar
        │                                  │
        │  1. 双方都出示 istiod 签发的证书    │
        │  （身份 = SPIFFE ID，如            │
        │   spiffe://cluster.local/...       │
        │   /sa/order-sa）                   │
        │  2. 互相验证对方证书（双向）        │
        │  3. 协商对称密钥，建立加密通道       │
        └─────────── mTLS 加密通信 ──────────┘

• SPIFFE 身份：每个服务有唯一身份（SPIFFE ID，基于 ServiceAccount），格式 spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>。证书由 istiod（CA）签发，周期性轮转（默认 24h）。
• 双向认证：A、B 互相验证书（不只是客户端验服务端，服务端也验客户端），防中间人伪造。
• 加密通信：证书协商出对称密钥，后续流量加密，防窃听。
• PERMISSIVE vs STRICT：迁移期用 PERMISSIVE（加密明文都接受，避免一刀切切断旧服务），全迁移后切 STRICT（只加密，拒绝明文）。生产强烈建议 STRICT。

二、PeerAuthentication：mTLS 模式

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production     # 整个 production 命名空间
spec:
  mtls:
    mode: STRICT            # 只接受 mTLS 加密流量

• PERMISSIVE（默认）：加密与明文都接受。用于迁移——旧服务（未注入 Sidecar）仍能访问，新服务享受加密。
• STRICT：只接受 mTLS 加密，拒绝明文。生产目标态，强制全加密。
• 粒度：可命名空间级（metadata.namespace）或工作负载级（selector.matchLabels 选 Pod）。

三、AuthorizationPolicy：授权

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-web-to-order
  namespace: production
spec:
  selector:
    matchLabels:
      app: order-service           # 作用于 order-service
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/prod/sa/web-sa"]   # 只允许 web 调
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/order/*"]      # 且只能调 /order/* 的 GET/POST

• action：ALLOW（允许匹配的，其他拒绝）/ DENY（拒绝匹配的）/ AUDIT（记录日志）/ CUSTOM（自定义）。
• 默认拒绝：命名空间内若定义了任何 ALLOW 策略，则未显式 ALLOW 的请求都拒绝（白名单模式，最小权限）。
• 匹配维度：from（来源——principals 身份、namespaces、ipBlocks）、to（操作——methods、paths、ports）、when（条件——key=value，如 request.auth.claims[role] == admin）。
• AuthorizationPolicy vs 网络 ACL：基于服务身份（SPIFFE）而非 IP，更稳定（Pod IP 变化不影响），更贴合微服务语义。

四、RequestAuthentication：JWT 校验

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: jwt-validator
  namespace: production
spec:
  selector:
    matchLabels:
      app: api-gateway
  jwtRules:
    - issuer: "https://auth.example.com"
      jwksUri: "https://auth.example.com/.well-known/jwks.json"
      audiences: ["api.example.com"]   # 校验 audience

• Sidecar 拦截请求，校验 Authorization header 的 JWT 签名（用 jwksUri 的公钥）与 issuer/audience。
• 无效 JWT 直接拒绝（401），有效 JWT 的 claims 可在 AuthorizationPolicy 的 when 条件中引用（如 request.auth.claims[role]）做细粒度授权。

五、Ambient 模式 GA：去 Sidecar 的新架构

Sidecar 模式的痛点是「每 Pod 一个 Envoy 的资源开销」——集群数千 Pod 就要跑数千 Envoy，内存 CPU 可观。Ambient 模式（1.22 GA）用两层替代：

   ┌─── 节点 1 ───┐         ┌─── 节点 2 ───┐
   │ Pod A 业务   │         │ Pod B 业务   │
   │ Pod C 业务   │         │ Pod D 业务   │
   │              │         │              │
   │ ztunnel      │         │ ztunnel      │  ← 每节点一个 DaemonSet
   │ （L4 mTLS）  │ ──────→ │ （L4 mTLS）  │     Rust 轻量，做加密
   └──────────────┘         └──────────────┘

   需 L7 治理的服务（如 order 需金丝雀）按需挂 waypoint：
   ┌─── waypoint（Envoy，L7）───┐
   │ 处理 order 的 VirtualService │  ← 金丝雀/熔断等 L7 规则
   │ 路由/熔断等                  │
   └─────────────────────────────┘

• ztunnel：每个节点一个（DaemonSet），Rust 写的轻量 L4 代理。职责：mTLS 加密 + 基本 L4 路由。所有节点流量默认经 ztunnel 加密，享受零信任但无 Sidecar 开销。这是 Ambient 的基础层，人人享有。
• waypoint：按需部署的 Envoy（L7）。需要 L7 治理（VirtualService 金丝雀/AB/熔断/重试）的命名空间或服务才挂 waypoint，把 L7 规则下发给它。不需要 L7 的服务只用 ztunnel（最轻）。
• 分层按需的价值：L4 加密是基础设施（ztunnel 共享，省资源），L7 治理是高级功能（按需 waypoint）。比「每 Pod 一个全功能 Envoy」省大量资源——尤其对只需 mTLS 不需 L7 治理的服务。
• 迁移：Sidecar 与 Ambient 共存（1.22+），可逐命名空间迁移。Ambient 是 Istio 官方力推的未来方向。

六、Istio vs Linkerd

维度	Istio	Linkerd
出品方	Google/IBM/Lyft（CNCF）	Buoyant（CNCF）
数据面代理	Envoy（C++，功能全）	自研 Rust 代理（linkerd2-proxy，轻量）
功能	全（流量/安全/观测/金丝雀/镜像）	较少（基础流量/安全/观测）
复杂度	高（CRD 多，学习陡）	低（极简易用）
性能	中（Envoy 开销）	高（Rust 轻量）
新架构	Ambient（ztunnel+waypoint，去 Sidecar）	多种安装模式（轻量）
生态	CNCF 主流，功能与社区最强	CNCF，轻量易用派
适用	重度流量治理、大集群、需精细控制	追求极简、性能、快速上手

• Envoy vs Rust 代理：Istio 用 Envoy（C++，功能全但重），Linkerd 用自研 Rust 代理（轻量、内存安全、性能好但功能少）。这是两者最核心的技术差异。
• 选型：需要重度流量治理（金丝雀/AB/镜像/复杂熔断）与大集群选 Istio；追求极简部署、高性能、快速上手的中小项目选 Linkerd。Istio 是事实主流（功能与生态占优）。

下一步

理解了安全与 Ambient 后，下一步看参考——CRD 速查、流量模型、安全模型、易错点与 istioctl 命令速查，作为速查手册。