无自带Ingress控制器时Linkerd授权策略实现原理咨询

发往Pod的入站流量授权校验不是由Linkerd控制平面实时完成的，核心校验逻辑运行在每个业务Pod旁注入的数据平面sidecar（linkerd2-proxy）上，控制平面仅负责授权规则的分发与管控，不直接处理业务流量。

各组件的具体分工 #

• 控制平面侧
  集群中定义的Server（标识受保护的工作负载端口、服务范围）、ServerAuthorization（定义允许访问对应服务的身份范围）、HTTPRoute（定义七层流量的精细匹配规则）这类授权相关自定义资源，会由控制平面的destination组件统一监听、校验、聚合。它会把这些规则转换成sidecar可识别的轻量化配置，通过长连接实时推送给对应工作负载的sidecar，全程不触碰实际业务请求流量。除此之外控制平面只负责mTLS证书的签发轮换、可观测数据聚合这类管控类工作，完全不参与请求转发、校验的实时流程。
• 数据平面sidecar侧
  所有发往网格内Pod的流量（包括集群内服务间的mTLS流量、从外部Ingress进入的流量），都会先经过目标Pod旁部署的入站sidecar代理，校验动作完全在sidecar本地完成，不需要和控制平面做实时交互：
  1. 对mTLS加密流量，sidecar会先完成TLS握手，验证对端代理的证书合法性，解析出对端负载对应的ServiceAccount身份信息
  2. 从请求中提取端口、源IP、HTTP方法、路径、请求头等用于规则匹配的属性
  3. 对照本地缓存的授权规则做匹配，符合放行规则的请求会被转发给同Pod内的业务容器，不符合规则的请求会被直接拒绝（七层请求返回403状态码，四层流量直接重置连接）

无内置Ingress/反向代理仍可实现授权的原因 #

正是因为授权逻辑完全下沉到Pod侧的sidecar执行，Linkerd不需要自带Ingress控制器或者内置全局反向代理能力，就能实现全链路的授权控制：不管你使用哪种第三方Ingress控制器，只要流量能正确路由到后端Pod，或者给Ingress控制器本身注入Linkerd sidecar将其纳入网格，授权规则就能正常生效，不会被Ingress选型限制。

• 这种设计有两个明显的优势：一是不会因为控制平面故障导致已生效的授权规则失效，只要规则已经推送到sidecar本地，哪怕控制平面暂时不可用，授权校验依然能正常运行；二是校验逻辑在请求到达目标Pod的第一跳就执行，不会额外增加跨节点网络开销，性能损耗极低。

内容的提问来源于stack exchange，提问作者Dharmesh