【Linkerd】策略模型：Server、AuthorizationPolicy 与 policy 容器

第 7 篇 把出站发现钉在 destination.Get 流；但 meshed 连接仍可能在入站被拒——读者常把 403 / connection reset 与「无端点」混谈，或去改 ServiceProfile 而实际卡在 Server 未覆盖端口 / AuthorizationPolicy 不匹配。本篇钉策略轴：Server、AuthorizationPolicy、MeshTLSAuthentication 三类 CRD，以及 destination Pod 内 policy 容器与 destination 控制器的分工。

本篇在系列中的位置

篇目	核心内容
第 7 篇 · 服务发现流	per-target Get、EndpointTranslator
第 8 篇 · 策略模型	Server、AuthorizationPolicy、policy 容器
第 9 篇 · ServiceProfile	L7 路由、sp-validator
系列目录	关键问题、阅读路径

版本锚定：Linkerd 2.20（tag version-2.20）。策略 CRD 在 API 组 policy.linkerd.io；linkerd-policy-validator webhook 与 linkerd-policy ClusterRole 见 charts/linkerd-control-plane/templates/destination-rbac.yaml。无真实集群则不粘贴伪造拒绝日志或 kubectl 全量输出。

一、Server

Server CRD 声明工作负载上 哪些端口以 mesh 语义提供服务——把「这个 Pod 的 8080 是一个可被策略引用的 server」变成显式对象，而不是隐式默认全端口 meshed。

机制要点：

• Server 通过 podSelector / port 等字段匹配目标 Pod 与端口。
• 未被子 Server 覆盖的端口可能不走 mesh 入站策略链，或行为与 opaque 端口注解交互（见 第 3 篇）。
• Server 可将端口标为 opaque，影响 destination 侧 ProtocolHint（endpoint_translator.go 读取 Server 决定的 opaque 协议）。

Server 是后续 AuthorizationPolicy 与 ServerAuthorization（若使用）的锚点：策略「允许谁访问哪个 server」必须先有 server 定义。排障时若策略「永远不生效」，先查目标端口是否有匹配的 Server，再查 policy 资源。

2.20 的 linkerd-policy-validator webhook 在校验 policy.linkerd.io 下 servers 等资源（与 Gateway API 路由资源并列，见 helm 模板 rules）。

二、AuthorizationPolicy

AuthorizationPolicy 定义 谁可以对哪些 Server 发起连接。它是 Linkerd 2.x 策略模型的核心授权对象，替代早期更粗粒度的配置方式。

典型结构（概念层，非样例百科）：

• targetRef 指向 Server（或兼容的 GAPI 路由对象，详 第 11 篇）。
• requiredAuthenticationRefs 引用 MeshTLSAuthentication 或 NetworkAuthentication，声明调用方必须满足的认证方式。
• 未匹配任何 allow 规则的连接在入站侧被拒绝。

求值发生在 数据面入站路径：linkerd2-proxy 通过 inbound API（第 6 篇）获取与端口绑定的策略快照，而非通过 xDS RDS 下发 HTTP 路由。L7 路由（路径/方法匹配）在 ServiceProfile / GAPI HTTPRoute 另一条链（第 9 篇）。

与 Kubernetes NetworkPolicy 的分工：Linkerd 策略在 proxy 入站、mTLS 身份已建立之后 求值，语义是 mesh 身份与 server 绑定，不是 CNI 四层 iptables 规则全集。

三、MeshTLSAuthentication

MeshTLSAuthentication 声明哪些 mesh 身份（ServiceAccount、命名空间等）可被视为「已认证客户端」。它与 第 4 篇 的工作负载证书同一信任域：identity 签发 DNS-like 身份字符串，AuthorizationPolicy 通过 MeshTLSAuthentication 引用允许的身份集合。

对照：

握手失败（证书无效、trust anchor 不匹配）落在 identity 轴；握手成功但身份不在 allow 列表落在 策略轴——第 13 篇 必须分列。

四、policy 容器分工

第 5 篇 述及 destination Pod 四容器。与策略直接相关的是 policy 容器（policy-controller）：

flowchart LR
  k8s["K8s API watches"] --> pol["policy controller"]
  pol -->|"inbound policy"| proxy["linkerd2-proxy inbound"]
  k8s --> dest["destination controller"]
  dest -->|"destination.Get"| proxy

• policy 容器：watch policy.linkerd.io（及 GAPI 路由）CRD，编译入站策略，通过 inbound gRPC 推送给 proxy。RBAC 角色 linkerd-policy 授予对 servers、authorizationpolicies、meshtlsauthentications 等的 get/list/watch。
• destination 容器：负责出站 destination.Get / GetProfile、端点翻译；读 ServiceProfile 做 L7 profile，不替代 policy 容器的入站授权求值。
• sp-validator：只校验 ServiceProfile CRD 语法（第 9 篇），不参与实时连接授权。
• 反身 proxy：让控制面组件间流量也走 mTLS。

故障域分列：policy 容器 OOM 或 watch 中断 → 入站策略可能陈旧或默认拒绝；destination 容器故障 → 出站发现断流，入站策略可能仍可用（组件独立进程）。不要把「重装 destination」当成修复 AuthorizationPolicy 的首选动作。

五、拒绝失败表象

CRD 校验失败（webhook）发生在 写入 API server 时；连接拒绝发生在 运行时 proxy 入站。前者 kubectl apply 即报错，后者 Pod 已 Running 但客户端被拒——证据包必须分列。

policy-validator failurePolicy 跟随 chart webhookFailurePolicy：Fail 时坏策略阻止入库；Ignore 时可能静默放过无效 CRD——运维门，不在本篇展开 Helm 百科。

Gateway API HTTPRoute 与 policy CRD 双轨的冲突判定是开放问题（PLAN.md §六），机制边界见 第 11 篇。

参考资料

规范 / 官方文档 / 源码（A）

• Linkerd Server Policy、AuthorizationPolicy、MeshTLSAuthentication 文档 @ tag version-2.20
• linkerd/linkerd2 version-2.20：charts/linkerd-control-plane/templates/destination-rbac.yaml（policy-validator webhook、linkerd-policy RBAC）
• linkerd2-proxy-api inbound proto（入站策略发现）@ v0.20.0

站内对照（A/B）

• 第 5 篇 · destination 架构
• 第 6 篇 · linkerd2-proxy-api
• architecture/76 · Service Mesh（税地图，不引未测数字）

学术谱系（A）

• Gateway API policy attachment 谱系（GAPI 官方模型；Linkerd 2.20 支持至 1.5.1）

上一篇：服务发现流

下一篇：ServiceProfile