拓冰网站定制 
Istio Ambient Mesh 中 PeerAuthentication 的实现从 ztunnel 转换机制到 Waypoint 信任边界【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio本文解析 Istio Ambient Mesh 中PeerAuthentication资源的工作原理与 sidecar 模式不同Ambient 工作负载的 mTLS 策略并不直接下发给 ztunnel而是由 istiod 按“网格级 → 命名空间级 → 工作负载级”的优先级规则计算出生效策略再转换为 ztunnel 自定义的AuthorizationxDS 资源进行 L4 层强制执行。读完本文你将掌握 PeerAuthentication 在 ztunnel 与 Waypoint 代理两条链路上的完整转换逻辑、DENY策略的组/规则/匹配语义以及可直接复现验证的测试用例入口。背景Ambient 下 PeerAuthentication 语义为何不同PeerAuthentication资源定义了流量到达某个网格工作负载时是否必须通过 Istio mTLS 加密传输。Sidecar 模式下其语义相对明确但 Ambient 工作负载的架构差异——节点级 L4 代理 ztunnel 取代了容器内 sidecar——决定了策略的执行方式必须相应调整ztunnel 的目标是成为一个最小化 L4 代理其 xDS 配置被刻意精简策略不能在 ztunnel 内部做复杂的继承计算因此计算工作前移到控制面istiod结果是 ztunnel 收到的永远是一份“已经算好”的、按工作负载粒度裁剪的最终策略。PeerAuthentication 与 ztunnelztunnel 只消费两种 xDS 资源ztunnel 仅支持两种自定义xDS 资源WorkloadAuthorization因此 ztunnel不会直接收到PeerAuthentication。当 istiod 检测到一条指向 Ambient 捕获工作负载的PeerAuthentication时它会按mesh-wide → namespace → workload的优先级规则计算该工作负载的生效策略并把该策略发送以Authorization形式给 ztunnel。以文档给出的经典例子这条 PeerAuthentication 要求选中app: a的工作负载整体 STRICT仅 9090 端口例外为 PERMISSIVEapiVersion: security.istio.io/v1 kind: PeerAuthentication metadata: name: strict-and-permissive-mtls spec: selector: matchLabels: app: a mtls: mode: STRICT portLevelMtls: 9090: mode: PERMISSIVE它会被转换成如下的Authorizationaction: DENY groups: - rules: - matches: - notPrincipals: - presence: {} - rules: - matches: - notDestinationPorts: - 9090 name: converted_peer_authentication_strict-and-permissive-mtls scope: WORKLOAD_SELECTOR上述策略的语义是在 ztunnel 处拒绝未认证流量除非其目的地端口是 9090。结合源码理解转换convertPeerAuthentication上面这个转换并非“理论描述”仓库中有一个对应的完整黄金测试文件输入 peer-authn-strict-and-permissive-port-mtls-in.yaml 恰好就是上文那条 STRICT 9090 PERMISSIVE 的策略而期望输出 peer-authn-strict-and-permissive-port-mtls.yaml 与文档给出的Authorization逐字段一致这直接印证了转换行为的确定性。转换的核心实现位于 authorization.go 的convertPeerAuthentication函数从源码结构看其关键设计如下只有“工作负载级 带端口级 mTLS”的策略才会产出转换结果。函数开头就检查如果策略位于根命名空间、没有selector、或者没有任何portLevelMtls直接返回 nil这类策略等价于纯 STRICT 或纯 PERMISSIVE不需要逐端口表达// violates case #1, #2, or #3 if cfg.Namespace rootNamespace || pa.Selector nil || len(pa.PortLevelMtls) 0 { return nil }STRICT 顶层模式 → “无 principal 即拒绝”规则。mode STRICT时转换结果首先加入一条基于notPrincipals: [presence]的匹配——即连接的 TLS 证书中若不存在 principal未认证命中 DENY。非 STRICT 的端口 → 端口豁免规则。对于portLevelMtls中 PERMISSIVE/DISABLE 的端口在顶层为 STRICT 的前提下追加notDestinationPorts: [port]规则——连接目的地不是该端口时拒绝从而把 9090 这类端口豁免出强制 mTLS。多个 STRICT 端口则各自生成独立的 GroupGroup 之间是 OR 关系实现“这些端口同样要求认证”。全 STRICT 策略提前短路。如果顶层是 STRICT 且所有端口级也都是 STRICT函数返回 nil这等价于一条纯 STRICT 策略由 xDS 服务器直接推送静态 STRICT 策略常量istio_converted_static_strict见 authorization.go#L37-L39无需逐端口展开。命名规范转换后的策略命名为converted_peer_authentication_原策略名通过model.GetAmbientPolicyConfigName生成scope固定为WORKLOAD_SELECTORaction固定为DENY。Authorization的匹配语义转换产物的字段语义由 authorization.proto 定义理解它对读懂转换结果至关重要层级逻辑关系说明groups之间OR至少一个 group 命中策略动作生效group.rules之间AND组内所有规则必须同时命中rule.matches之间AND规则内所有条件必须同时成立同一Match中多字段AND多类型字段同时设置时须全部满足同字段多值OR如多个 principal 匹配任一即可Match支持namespaces/principals/source_ips/destination_ips/destination_ports及其not_反义形式字符串匹配支持精确、前缀、后缀与presence存在性四种类型。scope分为GLOBAL、NAMESPACE、WORKLOAD_SELECTOR三级PeerAuthentication 转换结果固定落在WORKLOAD_SELECTOR因为它的 selector 绑定了具体工作负载标签。优先级解析与静态 STRICT 策略“mesh → namespace → workload”的继承计算集中在 authorization.go 的convertedSelectorPeerAuthentications函数中从源码结构看有几个值得注意的规则同级冲突时最旧者获胜getOldestPeerAuthn按CreationTimestamp比较同一层级存在多条无 selector 策略时创建时间最早的生效并有Switch selected mesh policy to ...的 Debug 日志。工作负载策略只在非根命名空间生效位于根系统命名空间且带 selector 的 PeerAuthentication 被忽略。生效策略是 STRICT 时引用静态策略effectivePeerAuthenticationKeys会把istio-system/istio_converted_static_strict加入该工作负载的策略键集合而一旦工作负载策略中出现了需要端口例外的混合模式如 STRICT 9090 PERMISSIVE静态 STRICT 策略会被剔除改发转换后的完整策略——避免“先整体拒绝、再端口豁免”的双重下发。合并merge逻辑当根/命名空间策略为 STRICT、工作负载策略为非 STRICT 顶层但带有 STRICT 端口时转换会把父级的 STRICT 语义合并进工作负载策略shouldMergeStrict分支使下发的单条Authorization自包含全部约束。用测试用例验证转换行为文档指引读者直接阅读TestRBACConvert的测试用例ambientindex_test.go#L1751。该测试遍历 testdata 目录下所有*-in.yaml文件调用convertPeerAuthentication后与同名黄金文件比对。目录中有 20 余组 PeerAuthentication 用例覆盖了完整的模式组合矩阵例如输入文件输入策略覆盖场景peer-authn-strict-in.yaml纯 STRICT 工作负载策略期望输出为空走静态策略peer-authn-strict-and-permissive-port-mtls-in.yamlSTRICT 9090 PERMISSIVE 端口豁免即文档主例peer-authn-strict-and-disable-port-mtls-in.yamlSTRICT DISABLE 端口期望输出与 PERMISSIVE 端口相同peer-authn-strict-and-strict-port-mtls-in.yaml顶层与端口全 STRICT等价短路peer-authn-permissive-port-mtls-strict-in.yaml顶层 PERMISSIVE 下的单个 STRICT 端口peer-authn-permissive-root-strict-namespace-permissive-workload-in.yaml根 STRICT、命名空间 PERMISSIVE、工作负载端口的多级合并这些黄金文件可直接作为“策略 → L4 授权”映射的规范参考。PeerAuthentication 与 Waypoint 代理适用前提原文档的明确标注本节描述的 Waypoint 联动行为在文档写作时尚未完全实现且依赖于 ztunnel hairpinning 的设计讨论。以下内容反映的是该机制的目标设计。关键在于 ztunnel 转发时机ztunnel 先在其 L4 层应用TRANSPORT类策略即Authorization之后才把流量转发给 Waypoint 代理。由此产生两类行为目标工作负载的生效策略达到 STRICT 时未认证流量会在到达 Waypoint 之前就被 ztunnel 拒绝——这正是上文 DENY 策略的落点生效策略为 PERMISSIVE默认值时ztunnel 对 Waypoint 打开一条普通 TLS 的 HBONE 隧道注意这不是mTLS并在不呈递客户端证书的情况下转发流量。这引出 Ambient 安全模型中最重要的一条约束Waypoint 代理绝不能从入站连接中推导任何身份即使该连接来自 ztunnel 的 hairpin 路径。换言之所有走 TLS HBONE 隧道的流量都必须视为不可信此后流量仍经由 ztunnel 返回依然在同一条 TLS HBONE 隧道上并被转发到目的工作负载。PERMISSIVE 策略下未认证流量的路径即源 pod 以明文到 ztunnel 的本地端口ztunnel 在此处应用 L4 策略ztunnel 以 TLS非 mTLS到 waypointwaypoint 返回ztunnel 以明文送达到目的 pod。认证请求到达被捕获目的端的路径认证流量则经由 15008 端口的 HBONE mTLS 隧道直达目标 Waypoint由 Waypoint 应用全部策略包括 L7 策略再经目的端 ztunnel 走宿主网络到达工作负载。与 L4 AuthorizationPolicy 的边界PeerAuthentication 转换只是Authorization资源的一个来源。同一个 convertAuthorizationPolicy 所在的convertAuthorizationPolicy函数还负责把AuthorizationPolicy的 L4 字段IP、端口、principal、命名空间、ServiceAccount 及when条件中的 L4 属性见 l4WhenAttributes转换为Authorization若策略包含 HTTP 层属性istiod 会剥离这些字段并写入“ztunnel 不支持 HTTP 属性需部署 Waypoint 代理执行”的 Status 条件httpRuleFmt等模板。这与本文主题一脉相承Ambient 中 L4 强制在 ztunnel、L7 强制在 WaypointPeerAuthentication 作为纯传输层策略天然完整落在 ztunnel 一侧。小结ztunnel 不消费 PeerAuthenticationistiod 计算生效策略后下发转换好的AuthorizationDENYWORKLOAD_SELECTOR规则是 groups OR、rules AND、matches ANDSTRICT 顶层模式编译为“无 principal 即拒绝”非 STRICT 端口编译为notDestinationPorts豁免全 STRICT 策略短路为静态策略istio_converted_static_strict同级策略冲突以CreationTimestamp最旧者获胜多级继承的合并逻辑与 20 余组黄金文件测试一一对应可通过TestRBACConvert复现验证在 Waypoint 路径上ztunnel 先执行 L4 策略再转发PERMISSIVE 下走的是无客户端证书的普通 TLS HBONE 隧道因此 Waypoint 必须将一切隧道流量视为不可信、绝不推导身份。【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Istio Ambient Mesh 中 PeerAuthentication 的实现：从 ztunnel 转换机制到 Waypoint 信任边界
Istio Ambient Mesh 中 PeerAuthentication 的实现从 ztunnel 转换机制到 Waypoint 信任边界【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio本文解析 Istio Ambient Mesh 中PeerAuthentication资源的工作原理与 sidecar 模式不同Ambient 工作负载的 mTLS 策略并不直接下发给 ztunnel而是由 istiod 按“网格级 → 命名空间级 → 工作负载级”的优先级规则计算出生效策略再转换为 ztunnel 自定义的AuthorizationxDS 资源进行 L4 层强制执行。读完本文你将掌握 PeerAuthentication 在 ztunnel 与 Waypoint 代理两条链路上的完整转换逻辑、DENY策略的组/规则/匹配语义以及可直接复现验证的测试用例入口。背景Ambient 下 PeerAuthentication 语义为何不同PeerAuthentication资源定义了流量到达某个网格工作负载时是否必须通过 Istio mTLS 加密传输。Sidecar 模式下其语义相对明确但 Ambient 工作负载的架构差异——节点级 L4 代理 ztunnel 取代了容器内 sidecar——决定了策略的执行方式必须相应调整ztunnel 的目标是成为一个最小化 L4 代理其 xDS 配置被刻意精简策略不能在 ztunnel 内部做复杂的继承计算因此计算工作前移到控制面istiod结果是 ztunnel 收到的永远是一份“已经算好”的、按工作负载粒度裁剪的最终策略。PeerAuthentication 与 ztunnelztunnel 只消费两种 xDS 资源ztunnel 仅支持两种自定义xDS 资源WorkloadAuthorization因此 ztunnel不会直接收到PeerAuthentication。当 istiod 检测到一条指向 Ambient 捕获工作负载的PeerAuthentication时它会按mesh-wide → namespace → workload的优先级规则计算该工作负载的生效策略并把该策略发送以Authorization形式给 ztunnel。以文档给出的经典例子这条 PeerAuthentication 要求选中app: a的工作负载整体 STRICT仅 9090 端口例外为 PERMISSIVEapiVersion: security.istio.io/v1 kind: PeerAuthentication metadata: name: strict-and-permissive-mtls spec: selector: matchLabels: app: a mtls: mode: STRICT portLevelMtls: 9090: mode: PERMISSIVE它会被转换成如下的Authorizationaction: DENY groups: - rules: - matches: - notPrincipals: - presence: {} - rules: - matches: - notDestinationPorts: - 9090 name: converted_peer_authentication_strict-and-permissive-mtls scope: WORKLOAD_SELECTOR上述策略的语义是在 ztunnel 处拒绝未认证流量除非其目的地端口是 9090。结合源码理解转换convertPeerAuthentication上面这个转换并非“理论描述”仓库中有一个对应的完整黄金测试文件输入 peer-authn-strict-and-permissive-port-mtls-in.yaml 恰好就是上文那条 STRICT 9090 PERMISSIVE 的策略而期望输出 peer-authn-strict-and-permissive-port-mtls.yaml 与文档给出的Authorization逐字段一致这直接印证了转换行为的确定性。转换的核心实现位于 authorization.go 的convertPeerAuthentication函数从源码结构看其关键设计如下只有“工作负载级 带端口级 mTLS”的策略才会产出转换结果。函数开头就检查如果策略位于根命名空间、没有selector、或者没有任何portLevelMtls直接返回 nil这类策略等价于纯 STRICT 或纯 PERMISSIVE不需要逐端口表达// violates case #1, #2, or #3 if cfg.Namespace rootNamespace || pa.Selector nil || len(pa.PortLevelMtls) 0 { return nil }STRICT 顶层模式 → “无 principal 即拒绝”规则。mode STRICT时转换结果首先加入一条基于notPrincipals: [presence]的匹配——即连接的 TLS 证书中若不存在 principal未认证命中 DENY。非 STRICT 的端口 → 端口豁免规则。对于portLevelMtls中 PERMISSIVE/DISABLE 的端口在顶层为 STRICT 的前提下追加notDestinationPorts: [port]规则——连接目的地不是该端口时拒绝从而把 9090 这类端口豁免出强制 mTLS。多个 STRICT 端口则各自生成独立的 GroupGroup 之间是 OR 关系实现“这些端口同样要求认证”。全 STRICT 策略提前短路。如果顶层是 STRICT 且所有端口级也都是 STRICT函数返回 nil这等价于一条纯 STRICT 策略由 xDS 服务器直接推送静态 STRICT 策略常量istio_converted_static_strict见 authorization.go#L37-L39无需逐端口展开。命名规范转换后的策略命名为converted_peer_authentication_原策略名通过model.GetAmbientPolicyConfigName生成scope固定为WORKLOAD_SELECTORaction固定为DENY。Authorization的匹配语义转换产物的字段语义由 authorization.proto 定义理解它对读懂转换结果至关重要层级逻辑关系说明groups之间OR至少一个 group 命中策略动作生效group.rules之间AND组内所有规则必须同时命中rule.matches之间AND规则内所有条件必须同时成立同一Match中多字段AND多类型字段同时设置时须全部满足同字段多值OR如多个 principal 匹配任一即可Match支持namespaces/principals/source_ips/destination_ips/destination_ports及其not_反义形式字符串匹配支持精确、前缀、后缀与presence存在性四种类型。scope分为GLOBAL、NAMESPACE、WORKLOAD_SELECTOR三级PeerAuthentication 转换结果固定落在WORKLOAD_SELECTOR因为它的 selector 绑定了具体工作负载标签。优先级解析与静态 STRICT 策略“mesh → namespace → workload”的继承计算集中在 authorization.go 的convertedSelectorPeerAuthentications函数中从源码结构看有几个值得注意的规则同级冲突时最旧者获胜getOldestPeerAuthn按CreationTimestamp比较同一层级存在多条无 selector 策略时创建时间最早的生效并有Switch selected mesh policy to ...的 Debug 日志。工作负载策略只在非根命名空间生效位于根系统命名空间且带 selector 的 PeerAuthentication 被忽略。生效策略是 STRICT 时引用静态策略effectivePeerAuthenticationKeys会把istio-system/istio_converted_static_strict加入该工作负载的策略键集合而一旦工作负载策略中出现了需要端口例外的混合模式如 STRICT 9090 PERMISSIVE静态 STRICT 策略会被剔除改发转换后的完整策略——避免“先整体拒绝、再端口豁免”的双重下发。合并merge逻辑当根/命名空间策略为 STRICT、工作负载策略为非 STRICT 顶层但带有 STRICT 端口时转换会把父级的 STRICT 语义合并进工作负载策略shouldMergeStrict分支使下发的单条Authorization自包含全部约束。用测试用例验证转换行为文档指引读者直接阅读TestRBACConvert的测试用例ambientindex_test.go#L1751。该测试遍历 testdata 目录下所有*-in.yaml文件调用convertPeerAuthentication后与同名黄金文件比对。目录中有 20 余组 PeerAuthentication 用例覆盖了完整的模式组合矩阵例如输入文件输入策略覆盖场景peer-authn-strict-in.yaml纯 STRICT 工作负载策略期望输出为空走静态策略peer-authn-strict-and-permissive-port-mtls-in.yamlSTRICT 9090 PERMISSIVE 端口豁免即文档主例peer-authn-strict-and-disable-port-mtls-in.yamlSTRICT DISABLE 端口期望输出与 PERMISSIVE 端口相同peer-authn-strict-and-strict-port-mtls-in.yaml顶层与端口全 STRICT等价短路peer-authn-permissive-port-mtls-strict-in.yaml顶层 PERMISSIVE 下的单个 STRICT 端口peer-authn-permissive-root-strict-namespace-permissive-workload-in.yaml根 STRICT、命名空间 PERMISSIVE、工作负载端口的多级合并这些黄金文件可直接作为“策略 → L4 授权”映射的规范参考。PeerAuthentication 与 Waypoint 代理适用前提原文档的明确标注本节描述的 Waypoint 联动行为在文档写作时尚未完全实现且依赖于 ztunnel hairpinning 的设计讨论。以下内容反映的是该机制的目标设计。关键在于 ztunnel 转发时机ztunnel 先在其 L4 层应用TRANSPORT类策略即Authorization之后才把流量转发给 Waypoint 代理。由此产生两类行为目标工作负载的生效策略达到 STRICT 时未认证流量会在到达 Waypoint 之前就被 ztunnel 拒绝——这正是上文 DENY 策略的落点生效策略为 PERMISSIVE默认值时ztunnel 对 Waypoint 打开一条普通 TLS 的 HBONE 隧道注意这不是mTLS并在不呈递客户端证书的情况下转发流量。这引出 Ambient 安全模型中最重要的一条约束Waypoint 代理绝不能从入站连接中推导任何身份即使该连接来自 ztunnel 的 hairpin 路径。换言之所有走 TLS HBONE 隧道的流量都必须视为不可信此后流量仍经由 ztunnel 返回依然在同一条 TLS HBONE 隧道上并被转发到目的工作负载。PERMISSIVE 策略下未认证流量的路径即源 pod 以明文到 ztunnel 的本地端口ztunnel 在此处应用 L4 策略ztunnel 以 TLS非 mTLS到 waypointwaypoint 返回ztunnel 以明文送达到目的 pod。认证请求到达被捕获目的端的路径认证流量则经由 15008 端口的 HBONE mTLS 隧道直达目标 Waypoint由 Waypoint 应用全部策略包括 L7 策略再经目的端 ztunnel 走宿主网络到达工作负载。与 L4 AuthorizationPolicy 的边界PeerAuthentication 转换只是Authorization资源的一个来源。同一个 convertAuthorizationPolicy 所在的convertAuthorizationPolicy函数还负责把AuthorizationPolicy的 L4 字段IP、端口、principal、命名空间、ServiceAccount 及when条件中的 L4 属性见 l4WhenAttributes转换为Authorization若策略包含 HTTP 层属性istiod 会剥离这些字段并写入“ztunnel 不支持 HTTP 属性需部署 Waypoint 代理执行”的 Status 条件httpRuleFmt等模板。这与本文主题一脉相承Ambient 中 L4 强制在 ztunnel、L7 强制在 WaypointPeerAuthentication 作为纯传输层策略天然完整落在 ztunnel 一侧。小结ztunnel 不消费 PeerAuthenticationistiod 计算生效策略后下发转换好的AuthorizationDENYWORKLOAD_SELECTOR规则是 groups OR、rules AND、matches ANDSTRICT 顶层模式编译为“无 principal 即拒绝”非 STRICT 端口编译为notDestinationPorts豁免全 STRICT 策略短路为静态策略istio_converted_static_strict同级策略冲突以CreationTimestamp最旧者获胜多级继承的合并逻辑与 20 余组黄金文件测试一一对应可通过TestRBACConvert复现验证在 Waypoint 路径上ztunnel 先执行 L4 策略再转发PERMISSIVE 下走的是无客户端证书的普通 TLS HBONE 隧道因此 Waypoint 必须将一切隧道流量视为不可信、绝不推导身份。【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考