Kubernetes集群内部的东西向流量长期处于“裸奔”状态，Pod与Pod之间的HTTP、gRPC调用默认不加密，也不校验对方身份。攻击者只要渗透进任意一个容器，就能在内部网络中横向移动，抓取数据库密码、篡改服务响应，甚至伪装成合法服务发起请求。要解决这个问题，单向网络策略（NetworkPolicy）只是第一层隔离，真正的安全底座必须建立在双向TLS（mTLS）之上。mTLS不仅加密传输内容，还强制客户端和服务端互相验证证书，从而实现服务身份的强认证。
零信任网络的核心假设是：网络内部并不比外部更安全，任何一次服务调用都必须经过认证和授权。在Kubernetes中实现mTLS，通常有两种路线：一是使用服务网格（如Istio、Linkerd）自动为每个Pod注入Sidecar代理，由代理完成证书申请、双向验证和流量加密；二是使用SPIRE结合应用程序直接集成，通过SPIFFE标准发放身份。对于大多数团队，服务网格是落地成本最低、迁移最平滑的方案，本文以Istio为例展开实战。
为什么单纯网络策略不够，必须上mTLS
很多团队认为只要配置了NetworkPolicy限制Pod之间的访问，就可以高枕无忧。但NetworkPolicy只控制IP和端口级别的放行，并不关心流量内容是否加密，也不验证对端是否真的是那个Pod。如果攻击者劫持了某个Pod的IP，或者在节点上直接抓包，业务数据仍然会以明文形式暴露。更隐蔽的风险是：攻击者可以伪造被信任的源IP，绕过某些基于IP的ACL。
mTLS则直接解决了身份问题。每个Sidecar代理启动时会向证书颁发机构（CA）申请一份短期证书，证书中包含该服务在SPIFFE体系下的唯一身份标识，例如spiffe://cluster.local/ns/default/sa/my-service。当服务A调用服务B时，双方的Sidecar会互相出示证书，校验证书签名、有效期以及身份是否匹配。只有双向验证通过，TCP连接才会建立，应用层完全感知不到加密细节。
此外，mTLS还能防止中间人攻击和重放攻击。即使攻击者能旁路采集到网络流量，看到的内容也是加密后的密文；即使攻击者拿到了旧证书，短期证书轮换机制也会让旧证书快速失效。从合规角度看，mTLS提供了传输加密和身份认证的双重保障，是金融、医疗等强监管行业的必备能力。
设计证书体系与信任域
mTLS的基础是证书链。在一个Kubernetes集群中，通常需要维护两类CA：根CA和中间CA。根CA只用于签发中间CA，平时离线保存；中间CA负责动态签发每个Sidecar的短期证书。Istio默认内置了一个自签名的根CA和中间CA，也可以对接外部证书系统，比如cert-manager、HashiCorp Vault或AWS Private CA。选择哪种方式取决于团队现有的PKI基础设施。
信任域是另一个关键概念。SPIFFE身份中的cluster.local部分就是信任域。一个信任域内，所有服务共享同一个根CA，因此可以互相验证。如果跨集群通信，需要配置信任域联邦，让集群A的根CA信任集群B的根CA，才能完成跨集群mTLS。在设计阶段就要规划好信任域名称，避免后期改名导致所有身份标识失效。
下面是一个使用cert-manager签发自定义中间CA的YAML示例，它创建了一个Issuer，用于后续签发Pod证书。实际Istio自动注入时并不需要手动创建这些证书，但理解其原理有助于排查证书链问题。
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: istio-intermediate-ca
spec:
ca:
secretName: root-ca-secret
---
apiVersion: v1
kind: Secret
metadata:
name: root-ca-secret
namespace: cert-manager
data:
tls.crt: <base64-encoded-root-ca>
tls.key: <base64-encoded-root-key>
Istio的CA服务运行在istio-system命名空间中，每个Sidecar通过Envoy的SDS（Secret Discovery Service）接口向CA申请证书。默认证书有效期是24小时，Envoy会在到期前自动轮换，整个过程对应用透明。生产环境建议缩短有效期至1小时甚至更短，以降低证书泄露后的风险窗口。
启用自动mTLS：Istio实战配置
首先安装Istio并启用Sidecar注入。以下命令在Kubernetes 1.24以上版本均可执行。安装时使用default配置即可，其中已经包含了自动mTLS所需的组件。
istioctl install --set profile=default -y kubectl label namespace default istio-injection=enabled
部署两个示例服务：frontend和backend。frontend会定期调用backend的HTTP接口。默认情况下，Istio会为这两个Pod注入Envoy Sidecar，并且自动启用mTLS。也就是说，frontend访问backend的流量会被自动升级为双向TLS，而不需要修改任何应用代码。
为了确认mTLS确实生效，可以使用istioctl proxy-config secret命令查看Sidecar获得的证书详情。如果输出中包含ROOTCA和default等条目，说明证书已经成功签发。还可以在backend的访问日志中查看principal字段，它记录了调用方的SPIFFE身份。如果被调用方看到的是spiffe://cluster.local/ns/default/sa/frontend，就证明双向验证通过。
有时我们想强制所有流量都必须使用mTLS，拒绝任何明文回退。这需要通过PeerAuthentication资源来声明策略。下面这个策略应用于整个默认命名空间，要求所有入站流量都必须使用mTLS。
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default-mtls
namespace: default
spec:
mtls:
mode: STRICT
设置为STRICT后，任何未加密的请求都会被直接拒绝，并返回连接失败。如果某些外部系统暂时无法支持mTLS，可以改用PERMISSIVE模式，它会同时接受明文和TLS流量，适合迁移过渡阶段。但零信任目标应该是全面STRICT。
基于身份的访问控制
mTLS验证了“你是谁”，但还没有解决“你能做什么”。零信任要求每个请求都经过授权决策。Istio提供AuthorizationPolicy资源，可以根据SPIFFE身份、命名空间、HTTP路径、方法等维度进行细粒度控制。例如，我们只允许frontend服务调用backend的/data接口，其他服务一律拒绝。
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: backend-policy
namespace: default
spec:
selector:
matchLabels:
app: backend
action: ALLOW
rules:
- from:
- source:
principals:
- spiffe://cluster.local/ns/default/sa/frontend
to:
- operation:
methods: ["GET"]
paths: ["/data"]
这个策略生效后，如果另一个Pod（比如攻击者控制的evil-pod）尝试访问backend，即使它拥有有效的集群内网络路径，也会因为SPIFFE身份不在允许列表中而被Sidecar拒绝。这种基于身份的授权比基于IP的规则可靠得多，因为身份和证书绑定，无法伪造。我们还可以组合命名空间、JWT声明等条件，实现更复杂的访问矩阵。
在生产环境中，建议为每个服务都定义一个最小权限的AuthorizationPolicy，默认拒绝所有流量，只放行必要的调用方。这样做虽然初期配置繁琐，但一旦发生横向渗透，攻击者会被限制在极小的权限范围内，无法任意访问其他服务。配合PeerAuthentication的STRICT模式，可以构成完整的零信任访问控制闭环。
证书轮换与排错思路
Istio默认每24小时自动轮换一次Sidecar证书，而Envoy会在证书到期前主动向CA申请新证书，因此正常情况下应用不会感知到任何中断。但如果CA不可用、时钟不同步或网络分区，证书轮换可能失败，导致服务间调用突然出现TLS错误。排错的第一步是检查Sidecar的日志，在istio-proxy容器中查看是否有certificate expired或handshake failure。
可以使用以下命令查看某个Pod的证书有效期和剩余时间，及时发现异常。
istioctl proxy-config secret <pod-name> -n <namespace> -o json | jq -r '.dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytes' | base64 -d | openssl x509 -noout -dates
该命令会解码证书链中的叶子证书，显示notBefore和notAfter两个时间字段。如果发现证书已经过期，可以重启Pod强制重新申请。若频繁过期，需要检查Istio CA服务是否健康，以及节点时钟是否与NTP同步。时钟偏差是导致TLS握手失败的常见原因，因为证书有效性严重依赖时间判断。
另一个常见问题是策略冲突。例如同时存在多个PeerAuthentication，作用范围重叠时，Istio会采用最严格的模式。如果Pod A设置了PERMISSIVE，而Pod B所在命名空间设置了STRICT，那么A到B的明文流量会被B拒绝。排查时可以用istioctl analyze命令扫描配置错误，它会输出具体资源名称和冲突原因。此外，使用istioctl proxy-status查看所有Sidecar的同步状态，如果某个Pod显示STALE，说明配置尚未下发完成，需要等待或检查Pilot连接。
最后要强调，mTLS只是零信任架构的一部分。还需要结合运行时安全、镜像签名、最小权限RBAC、出口流量过滤等措施，才能构建纵深防御。但mTLS无疑是最基础、最核心的一环，因为它从网络层面解决了身份伪造和数据泄露两大痛点。对于已经运行在Kubernetes上的团队，建议尽快开启Sidecar注入和全局STRICT模式，然后逐步补充授权策略，让内部流量不再“裸奔”。
Kubernetes mTLS零信任网络服务网格修改时间：2026-10-06 21:59:33