📚 课程目录第4章 Istio安全模型

4. Istio 安全模型：双向TLS、身份认证、授权策略、审计日志的核心原理

在 Serverless 控制面中，工作负载的生命周期极短、IP 动态变化、服务间调用频繁。Istio 的安全模型围绕“零信任网络”设计，通过双向 TLS（mTLS）、身份认证、授权策略和审计日志四个核心支柱，为 Serverless 函数提供身份可验证、权限可管控、行为可追溯的安全通信底座。

4.1 双向TLS（mTLS）：服务间通信的加密与身份验证

双向 TLS 是 Istio 安全模型的基石。与单向 TLS 不同，mTLS 要求通信双方都出示并验证证书，确保调用方和被调用方的身份都是可信的。

  核心流程： 每个 Sidecar Proxy（Envoy）从 Istiod 的 CA（证书颁发机构）获取由 SPIRE 或自建 CA 签发的 X.509 证书。当服务 A 调用服务 B 时，双方的 Envoy 代理在 L4 层完成 TLS 握手，交换并验证证书，之后所有流量均被加密传输。

4.2 身份认证：从服务账号到 SPIFFE 身份

Istio 使用 SPIFFE（Secure Production Identity Framework for Everyone） 标准为每个工作负载分配唯一身份。在 Kubernetes 环境中，该身份通常与服务账号（ServiceAccount）绑定。

身份组件	描述	Serverless 场景要点
SPIFFE ID	格式为 `spiffe://cluster.local/ns/<ns>/sa/<sa>`	每个 Serverless 函数应使用独立的 ServiceAccount
X.509 证书	包含 SPIFFE ID 的 SANS，由 Istiod 签发	证书自动轮换，无需函数关心证书过期
JWT	用于请求身份认证（RequestAuthentication）	适用于 Serverless 函数对外暴露 API 时的终端用户认证
信任域	默认 `cluster.local`，可配置为自定义域名	多集群或多租户场景下需统一信任域

最佳实践： 在 Serverless 控制面中，为每个函数或函数组创建独立的 Kubernetes ServiceAccount，并配置对应的 SPIFFE 身份。这为后续的细粒度授权策略提供了清晰的身份边界。

4.3 授权策略：基于身份的细粒度访问控制

授权策略（AuthorizationPolicy）是 Istio 安全模型中最灵活的部分。它基于 ACTION（允许/拒绝）、主体（来源身份）、操作（HTTP 方法/端口） 和 条件（请求头/路径） 四个维度定义规则。

授权策略的评估顺序遵循“拒绝优先”原则：

如果存在匹配的 DENY 策略，请求被拒绝。
如果存在匹配的 ALLOW 策略，请求被允许。
如果没有任何 ALLOW 策略匹配，请求被拒绝（默认拒绝）。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: function-a-policy
  namespace: serverless-func
spec:
  selector:
    matchLabels:
      app: function-a
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/serverless-func/sa/function-b-sa"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/v1/data"]
    when:
    - key: request.headers[version]
      values: ["v2"]

  Serverless 适配： 由于 Serverless 函数的 Pod 可能随时被销毁和重建，授权策略应基于 ServiceAccount 身份 而非固定的 Pod IP 或 Deployment 名称。Istio 的授权策略天然支持这种基于 SPIFFE 身份的匹配。

4.4 审计日志：可观测性与合规性基础

审计日志记录了所有经过 Sidecar Proxy 的请求的元数据，包括来源身份、目标身份、请求方法、响应码和时间戳。在 Serverless 控制面中，审计日志是排查安全事件和满足合规要求的关键数据源。

Istio 通过 Envoy 的访问日志（Access Log） 实现审计功能。日志格式可通过 MeshConfig 或 EnvoyFilter 自定义，以包含安全相关的字段：

日志字段	说明	安全审计价值
`%REQ(X-REQUEST-ID)%`	请求追踪 ID	关联分布式调用链
`%SPIFFE_ID%`	来源工作负载的 SPIFFE 身份	确认调用方身份
`%DOWNSTREAM_PEER_ISSUER%`	客户端证书签发者	验证证书链可信性
`%RESPONSE_CODE%`	HTTP 响应码（如 403）	识别被拒绝的非法请求
`%DURATION%`	请求处理耗时	检测异常延迟（可能为攻击）

注意： 在 Serverless 控制面中，审计日志的采集不应依赖函数实例的本地存储。建议将 Envoy 访问日志直接输出到 stdout，由日志采集 DaemonSet（如 Fluentd、Logstash）统一收集并转发到外部存储系统，确保函数缩容至零时日志不丢失。

4.5 四者协同：构建零信任安全环

双向 TLS、身份认证、授权策略和审计日志并非孤立组件，它们在 Istio 安全模型中形成闭环：

mTLS 提供传输层加密和身份验证，确保通信管道安全。
身份认证 为每个工作负载绑定不可伪造的 SPIFFE 身份。
授权策略 基于身份执行细粒度的访问控制决策。
审计日志 记录所有授权决策和请求元数据，用于事后追溯和异常检测。

在 Serverless 控制面中，这四个组件共同实现了“永不信任，始终验证”的安全模型，使函数在动态、弹性的基础设施中依然能够保持企业级的安全水位。