2. Istio mTLS 基础概念：身份与信任、SPIFFE 标准、Istio 中的身份标识（Service Account）

2.1 身份与信任：mTLS 的基石

在零信任网络模型中，服务间的通信不再依赖网络边界（如 IP 或防火墙），而是基于身份进行认证和授权。mTLS（双向 TLS）正是实现这一目标的核心技术。它要求通信双方在建立 TLS 连接时，不仅要验证服务器的证书，还要验证客户端的证书，从而确保双方的身份都是可信的。

在 Istio 中，mTLS 解决了两个关键问题：

• 身份认证（Authentication）：确保通信的另一方是预期的服务，而非冒牌货。
• 通信加密（Encryption）：确保传输中的数据不会被窃听或篡改。

2.2 SPIFFE 标准：统一的工作负载身份

SPIFFE（Secure Production Identity Framework for Everyone）是一套开源标准，旨在为动态、异构环境中的工作负载提供统一的身份标识。Istio 的身份体系完全遵循 SPIFFE 标准。

SPIFFE 的核心概念包括：

• SPIFFE ID：一个统一资源标识符（URI），用于唯一标识一个工作负载。格式为 spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>。
• SPIFFE Verifiable Identity Document (SVID)：一个用于证明 SPIFFE ID 的凭证，通常是 X.509 证书。
• 信任域（Trust Domain）：标识一个信任的边界，通常对应一个组织或集群。

下表展示了 SPIFFE ID 各组成部分的含义：

2.3 Istio 中的身份标识：Service Account

在 Istio 中，Kubernetes Service Account 是工作负载身份的直接映射。每个部署在 Istio 网格中的 Pod，都会关联一个 Service Account。Istio 的控制面组件 istiod 会为每个 Service Account 签发一个 X.509 证书，该证书的 SAN（Subject Alternative Name）字段中包含了对应的 SPIFFE ID。

Istio 身份管理的核心流程如下：

1. 身份注册：当 Pod 启动时，Envoy 代理（Sidecar）会向 istiod 发送证书签名请求（CSR）。
2. 身份验证：istiod 通过 Kubernetes API Server 验证 Pod 的 Service Account 和所在命名空间。
3. 证书签发：验证通过后，istiod 使用其根证书（CA 证书）为 Envoy 签发一个短期有效的 X.509 证书。
4. 身份使用：Envoy 使用该证书与其他服务建立 mTLS 连接，对方通过验证证书中的 SPIFFE ID 来确认身份。

2.4 身份与 Service Account 的映射关系

Istio 将 Kubernetes Service Account 直接映射为 SPIFFE 身份。这种设计带来了以下优势：

• 原生集成：无需额外创建身份管理系统，直接复用 Kubernetes 的 RBAC 和 Service Account 机制。
• 细粒度控制：可以为不同的 Service Account 配置不同的授权策略（AuthorizationPolicy），实现精细化的访问控制。
• 可迁移性：遵循 SPIFFE 标准，使得 Istio 网格内的身份可以与其他支持 SPIFFE 的系统互认。

下表总结了 Istio 身份体系中的关键组件及其关系：