Cilium L7 协议可见性用 L7 网络策略与 Hubble 实现 DNS/HTTP 深度流量观测及敏感信息遮蔽【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本篇指南基于 Cilium 官方文档 Layer 7 Protocol Visibility 整理讲解如何通过带有 L7 规则的CiliumNetworkPolicy将 Cilium 对 Pod 流量的观测从默认的 L3/L4 层面上升到 DNS、HTTP 等 L7 协议层面并结合hubble observe实战验证 L7 流详情最后深入源码说明 Hubble 敏感信息遮蔽redact机制的配置项与实现细节帮助读者在集群中安全地落地七层可观测能力。为什么默认只能看到 L3/L4 流量Cilium 的 monitor 机制cilium monitor提供对数据面状态的内省能力但默认情况下只提供 L3/L4 包事件的可见性——也就是你能看到哪个 Pod 向哪个地址的哪个端口发了什么协议的包却看不到包在应用层携带了什么内容例如 DNS 查询的是哪个域名、HTTP 请求的是哪个 URL。要获得 L7 协议可见性前提条件有两个必须启用 L7 Proxy 支持这是官方文档给出的硬性前置要求必须存在匹配该流量的 L7CiliumNetworkPolicy规则。其原理是流量一旦匹配了 Cilium 网络策略中的 L7 规则就会被 Cilium 重定向到 L7 代理进程proxy中解析——正是这一步让 DNS/HTTP 请求的详细内容被提取出来进而通过cilium monitor或hubble observe暴露给最终用户。这一重定向到代理的机制详见 L7 Proxy 文档。需要特别注意的是L7 网络策略不仅是开关它同时也是访问控制。开启 L7 可见性的策略会同时限制流入流出 Pod 的流量未匹配的规则会被丢弃这一点在配置前必须理解清楚。完整实操示例为 DNS 与 HTTP 流量开启 L7 可见性下面的示例策略为default命名空间内的 Pod 开启两类 L7 可见性DNSTCP/UDP 53允许访问kube-system命名空间中标记为kube-dns的端点L7 匹配条件为matchPattern: *通配即允许所有 DNS 查询HTTPTCP 80 与 TCP 8080允许访问default命名空间内的端点L7 规则写作http: [{}]空条件等同于允许所有匹配 L4 部分的请求。策略中 L7 匹配条件被刻意省略或通配效果是放行所有命中每条规则 L4 部分的请求从而让全部相应流量进入代理并被观测apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: l7-visibility spec: endpointSelector: matchLabels: k8s:io.kubernetes.pod.namespace: default egress: - toEndpoints: - matchLabels: k8s:io.kubernetes.pod.namespace: kube-system k8s:k8s-app: kube-dns toPorts: - ports: - port: 53 protocol: ANY rules: dns: - matchPattern: * - toEndpoints: - matchLabels: k8s:io.kubernetes.pod.namespace: default toPorts: - ports: - port: 80 protocol: TCP - port: 8080 protocol: TCP rules: http: [{}]策略生效后的行为链路是Cilium 捕获default命名空间 Pod 发往kube-dns53 端口的 DNS 流量和 80/8080 端口的 HTTP 流量将其重定向到 L7 代理于是cilium monitor或hubble observe的输出中就包含了 L7 流详情。用 hubble observe 验证 L7 流详情在策略部署后执行hubble observe -f -t l7 -o compact典型输出如下default/testapp-5b9cc645cb-4slbs:45240 (ID:26450) - kube-system/coredns-787d4945fb-bdmdq:53 (ID:9313) dns-request proxy FORWARDED (DNS Query web.default.svc.cluster.local. A) default/testapp-5b9cc645cb-4slbs:45240 (ID:26450) - kube-system/coredns-787d4945fb-bdmdq:53 (ID:9313) dns-response proxy FORWARDED (DNS Answer 10.96.118.37 TTL: 30 (Proxy web.default.svc.cluster.local. A)) default/testapp-5b9cc645cb-4slbs:33044 (ID:26450) - default/echo-594485b8dc-fp57l:8080 (ID:32531) http-request FORWARDED (HTTP/1.1 GET http://web/) default/testapp-5b9cc645cb-4slbs:33044 (ID:26450) - default/echo-594485b8dc-fp57l:8080 (ID:32531) http-response FORWARDED (HTTP/1.1 200 4ms (GET http://web/))从输出可以读出几个关键信息每条流都带有L7 动词dns-request/dns-response/http-request/http-response这是流量确实经过 L7 代理解析的证据事件经过代理处理的会带proxy标记FORWARDED表示流最终被转发未被策略丢弃括号内是协议细节DNS 查询的域名与记录类型web.default.svc.cluster.local. A、应答 IP 与 TTLHTTP 的方法、路径、状态码与耗时200 4ms。源码级印证Hubble 的 L7 解析与遮蔽机制从源码结构看上述 L7 流的解析与遮蔽逻辑集中在 Hubble parser 中pkg/hubble/parser/options/options.go 定义了HubbleRedactSettings结构体字段一一对应文档中的遮蔽配置项Enabled是否启用遮蔽、RedactHTTPQuery遮蔽 URL 查询参数、RedactHTTPUserInfo遮蔽 URL 中的用户信息如 Basic Auth 密码以及RedactHttpHeadersHTTP 头的 Allow/Deny 列表内部是map[string]struct{}以实现 O(1) 查找。pkg/hubble/defaults/defaults.go 定义了常量SensitiveValueRedacted HUBBLE_REDACTED——即开启遮蔽后被遮蔽的敏感值在 Hubble 流中统一被替换为字符串HUBBLE_REDACTED这解释了为什么在hubble observe中看到该占位符是符合预期的行为。HTTP 协议的 L7 解析与遮蔽实现位于 pkg/hubble/parser/seven/http.go配套的解析器单元格配置见 pkg/hubble/parser/cell/config.go。可以推断--hubble-redact-*系列 CLI 选项在 agent 启动时被读入上述HubbleRedactSettings随后作为 Option 注入解析器在每个 L7 流事件出栈前完成字段级替换。完整命令行参数参考 cilium-agent 命令参考其中可查到--hubble-redact-enabled等选项的说明。安全影响遮蔽Redact敏感信息监控 L7 流量意味着会接触到潜在的敏感数据用户名、密码、URL 查询参数、API Key 等。官方文档明确警告默认情况下Hubble 不会遮蔽 L7 流中的敏感信息。为了加固安全Cilium 提供以下配置选项选项作用--hubble-redact-enabled总开关启用 Hubble 对 L7 流中敏感信息的遮蔽处理--hubble-redact-http-urlqueryHTTP遮蔽 URL 查询GET参数--hubble-redact-http-userinfoHTTP遮蔽 URL 中的用户信息例如 Basic 认证中使用的密码--hubble-redact-http-headers-allowHTTP 头仅保留该列表内的头遮蔽其余所有头--hubble-redact-http-headers-denyHTTP 头仅遮蔽该列表内指定的头Allow 与 Deny 列表的语义正好互补Allow 是白名单模式默认全遮蔽、仅放行列出的头Deny 是黑名单模式默认全保留、仅遮蔽列出的头对应源码中HttpHeadersList的Allow与Deny两个 map。这些参数属于 Cilium 全局配置配置方法参见 Cilium 配置文档。已知限制在规划 L7 可见性方案时官方文档列出两条明确限制DNS 可见性仅在出方向egress可用——入方向 DNS 流量不会有 L7 详情SNAT 后的 IPv6 流量如 pod-to-world上的 L7 策略依赖一个内核补丁需要打上该修复的稳定内核版本6.14.1、6.12.22、6.6.86、6.1.133、5.15.180、5.10.236上游 issue 编号 #37932。在未达到上述内核版本的环境中此类流量可能无法正常匹配 L7 规则。小结L7 协议可见性在 Cilium 中并不是一个独立的功能开关而是 L7 网络策略的副产物为流量编写 L7 规则流量才会被重定向到代理解析hubble observe/cilium monitor才输出 DNS 域名、HTTP 请求等深度信息。落地时建议按本文示例部署 DNSHTTP 双规则策略验证效果同时在多租户或合规敏感场景中务必开启--hubble-redact-enabled及其配套的 HTTP 遮蔽选项避免密码、查询参数等敏感数据进入可观测链路涉及 pod-to-world 的 IPv6 L7 策略时请优先核对内核版本是否满足限制一节的要求。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cilium L7 协议可见性：用 L7 网络策略与 Hubble 实现 DNS/HTTP 深度流量观测及敏感信息遮蔽
Cilium L7 协议可见性用 L7 网络策略与 Hubble 实现 DNS/HTTP 深度流量观测及敏感信息遮蔽【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本篇指南基于 Cilium 官方文档 Layer 7 Protocol Visibility 整理讲解如何通过带有 L7 规则的CiliumNetworkPolicy将 Cilium 对 Pod 流量的观测从默认的 L3/L4 层面上升到 DNS、HTTP 等 L7 协议层面并结合hubble observe实战验证 L7 流详情最后深入源码说明 Hubble 敏感信息遮蔽redact机制的配置项与实现细节帮助读者在集群中安全地落地七层可观测能力。为什么默认只能看到 L3/L4 流量Cilium 的 monitor 机制cilium monitor提供对数据面状态的内省能力但默认情况下只提供 L3/L4 包事件的可见性——也就是你能看到哪个 Pod 向哪个地址的哪个端口发了什么协议的包却看不到包在应用层携带了什么内容例如 DNS 查询的是哪个域名、HTTP 请求的是哪个 URL。要获得 L7 协议可见性前提条件有两个必须启用 L7 Proxy 支持这是官方文档给出的硬性前置要求必须存在匹配该流量的 L7CiliumNetworkPolicy规则。其原理是流量一旦匹配了 Cilium 网络策略中的 L7 规则就会被 Cilium 重定向到 L7 代理进程proxy中解析——正是这一步让 DNS/HTTP 请求的详细内容被提取出来进而通过cilium monitor或hubble observe暴露给最终用户。这一重定向到代理的机制详见 L7 Proxy 文档。需要特别注意的是L7 网络策略不仅是开关它同时也是访问控制。开启 L7 可见性的策略会同时限制流入流出 Pod 的流量未匹配的规则会被丢弃这一点在配置前必须理解清楚。完整实操示例为 DNS 与 HTTP 流量开启 L7 可见性下面的示例策略为default命名空间内的 Pod 开启两类 L7 可见性DNSTCP/UDP 53允许访问kube-system命名空间中标记为kube-dns的端点L7 匹配条件为matchPattern: *通配即允许所有 DNS 查询HTTPTCP 80 与 TCP 8080允许访问default命名空间内的端点L7 规则写作http: [{}]空条件等同于允许所有匹配 L4 部分的请求。策略中 L7 匹配条件被刻意省略或通配效果是放行所有命中每条规则 L4 部分的请求从而让全部相应流量进入代理并被观测apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: l7-visibility spec: endpointSelector: matchLabels: k8s:io.kubernetes.pod.namespace: default egress: - toEndpoints: - matchLabels: k8s:io.kubernetes.pod.namespace: kube-system k8s:k8s-app: kube-dns toPorts: - ports: - port: 53 protocol: ANY rules: dns: - matchPattern: * - toEndpoints: - matchLabels: k8s:io.kubernetes.pod.namespace: default toPorts: - ports: - port: 80 protocol: TCP - port: 8080 protocol: TCP rules: http: [{}]策略生效后的行为链路是Cilium 捕获default命名空间 Pod 发往kube-dns53 端口的 DNS 流量和 80/8080 端口的 HTTP 流量将其重定向到 L7 代理于是cilium monitor或hubble observe的输出中就包含了 L7 流详情。用 hubble observe 验证 L7 流详情在策略部署后执行hubble observe -f -t l7 -o compact典型输出如下default/testapp-5b9cc645cb-4slbs:45240 (ID:26450) - kube-system/coredns-787d4945fb-bdmdq:53 (ID:9313) dns-request proxy FORWARDED (DNS Query web.default.svc.cluster.local. A) default/testapp-5b9cc645cb-4slbs:45240 (ID:26450) - kube-system/coredns-787d4945fb-bdmdq:53 (ID:9313) dns-response proxy FORWARDED (DNS Answer 10.96.118.37 TTL: 30 (Proxy web.default.svc.cluster.local. A)) default/testapp-5b9cc645cb-4slbs:33044 (ID:26450) - default/echo-594485b8dc-fp57l:8080 (ID:32531) http-request FORWARDED (HTTP/1.1 GET http://web/) default/testapp-5b9cc645cb-4slbs:33044 (ID:26450) - default/echo-594485b8dc-fp57l:8080 (ID:32531) http-response FORWARDED (HTTP/1.1 200 4ms (GET http://web/))从输出可以读出几个关键信息每条流都带有L7 动词dns-request/dns-response/http-request/http-response这是流量确实经过 L7 代理解析的证据事件经过代理处理的会带proxy标记FORWARDED表示流最终被转发未被策略丢弃括号内是协议细节DNS 查询的域名与记录类型web.default.svc.cluster.local. A、应答 IP 与 TTLHTTP 的方法、路径、状态码与耗时200 4ms。源码级印证Hubble 的 L7 解析与遮蔽机制从源码结构看上述 L7 流的解析与遮蔽逻辑集中在 Hubble parser 中pkg/hubble/parser/options/options.go 定义了HubbleRedactSettings结构体字段一一对应文档中的遮蔽配置项Enabled是否启用遮蔽、RedactHTTPQuery遮蔽 URL 查询参数、RedactHTTPUserInfo遮蔽 URL 中的用户信息如 Basic Auth 密码以及RedactHttpHeadersHTTP 头的 Allow/Deny 列表内部是map[string]struct{}以实现 O(1) 查找。pkg/hubble/defaults/defaults.go 定义了常量SensitiveValueRedacted HUBBLE_REDACTED——即开启遮蔽后被遮蔽的敏感值在 Hubble 流中统一被替换为字符串HUBBLE_REDACTED这解释了为什么在hubble observe中看到该占位符是符合预期的行为。HTTP 协议的 L7 解析与遮蔽实现位于 pkg/hubble/parser/seven/http.go配套的解析器单元格配置见 pkg/hubble/parser/cell/config.go。可以推断--hubble-redact-*系列 CLI 选项在 agent 启动时被读入上述HubbleRedactSettings随后作为 Option 注入解析器在每个 L7 流事件出栈前完成字段级替换。完整命令行参数参考 cilium-agent 命令参考其中可查到--hubble-redact-enabled等选项的说明。安全影响遮蔽Redact敏感信息监控 L7 流量意味着会接触到潜在的敏感数据用户名、密码、URL 查询参数、API Key 等。官方文档明确警告默认情况下Hubble 不会遮蔽 L7 流中的敏感信息。为了加固安全Cilium 提供以下配置选项选项作用--hubble-redact-enabled总开关启用 Hubble 对 L7 流中敏感信息的遮蔽处理--hubble-redact-http-urlqueryHTTP遮蔽 URL 查询GET参数--hubble-redact-http-userinfoHTTP遮蔽 URL 中的用户信息例如 Basic 认证中使用的密码--hubble-redact-http-headers-allowHTTP 头仅保留该列表内的头遮蔽其余所有头--hubble-redact-http-headers-denyHTTP 头仅遮蔽该列表内指定的头Allow 与 Deny 列表的语义正好互补Allow 是白名单模式默认全遮蔽、仅放行列出的头Deny 是黑名单模式默认全保留、仅遮蔽列出的头对应源码中HttpHeadersList的Allow与Deny两个 map。这些参数属于 Cilium 全局配置配置方法参见 Cilium 配置文档。已知限制在规划 L7 可见性方案时官方文档列出两条明确限制DNS 可见性仅在出方向egress可用——入方向 DNS 流量不会有 L7 详情SNAT 后的 IPv6 流量如 pod-to-world上的 L7 策略依赖一个内核补丁需要打上该修复的稳定内核版本6.14.1、6.12.22、6.6.86、6.1.133、5.15.180、5.10.236上游 issue 编号 #37932。在未达到上述内核版本的环境中此类流量可能无法正常匹配 L7 规则。小结L7 协议可见性在 Cilium 中并不是一个独立的功能开关而是 L7 网络策略的副产物为流量编写 L7 规则流量才会被重定向到代理解析hubble observe/cilium monitor才输出 DNS 域名、HTTP 请求等深度信息。落地时建议按本文示例部署 DNSHTTP 双规则策略验证效果同时在多租户或合规敏感场景中务必开启--hubble-redact-enabled及其配套的 HTTP 遮蔽选项避免密码、查询参数等敏感数据进入可观测链路涉及 pod-to-world 的 IPv6 L7 策略时请优先核对内核版本是否满足限制一节的要求。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考