From 40cf9641489404bd1f8ae4397528e85f7563f799 Mon Sep 17 00:00:00 2001 From: Gwynne Monahan Date: Fri, 18 Apr 2025 12:00:19 -0500 Subject: [PATCH 1/3] OSDOCS-14366 Additional context concept about the multi-flow filtering capability --- ...k-observability-ebpf-rule-flow-filter.adoc | 8 +- ...ork-observability-filtering-ebpf-rule.adoc | 75 +++++++------------ ...lity-flowcollector-api-specifications.adoc | 8 +- 3 files changed, 36 insertions(+), 55 deletions(-) diff --git a/modules/network-observability-ebpf-rule-flow-filter.adoc b/modules/network-observability-ebpf-rule-flow-filter.adoc index b20c6a803514..6f50528aecc3 100644 --- a/modules/network-observability-ebpf-rule-flow-filter.adoc +++ b/modules/network-observability-ebpf-rule-flow-filter.adoc @@ -5,13 +5,15 @@ :_mod-docs-content-type: CONCEPT [id="network-observability-ebpf-flow-rule-filter_{context}"] = eBPF flow rule filter -You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. +You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. + +You can apply multiple filter rules, and add a webhook check to prevent CIDR duplication. [id="ingress-and-egress-traffic-filtering_{context}"] == Ingress and egress traffic filtering -CIDR notation efficiently represents IP address ranges by combining the base IP address with a prefix length. For both ingress and egress traffic, the source IP address is first used to match filter rules configured with CIDR notation. If there is a match, then the filtering proceeds. If there is no match, then the destination IP is used to match filter rules configured with CIDR notation. +CIDR notation efficiently represents IP address ranges by combining the base IP address with a prefix length. For both ingress and egress traffic, the source IP address is first used to match filter rules configured with CIDR notation. If there is a match, then the filtering proceeds. If there is no match, then the destination IP is used to match filter rules configured with CIDR notation. -After matching either the source IP or the destination IP CIDR, you can pinpoint specific endpoints using the `peerIP` to differentiate the destination IP address of the packet. Based on the provisioned action, the flow data is either cached in the eBPF flow table or not cached. +After matching either the source IP or the destination IP CIDR, you can pinpoint specific endpoints using the `peerIP` to differentiate the destination IP address of the packet. Based on the provisioned action, the flow data is either cached in the eBPF flow table or not cached. [id="dashboard-and-metrics-integrations_{context}"] == Dashboard and metrics integrations diff --git a/modules/network-observability-filtering-ebpf-rule.adoc b/modules/network-observability-filtering-ebpf-rule.adoc index 85e41e34b28e..bad62b2cbf7f 100644 --- a/modules/network-observability-filtering-ebpf-rule.adoc +++ b/modules/network-observability-filtering-ebpf-rule.adoc @@ -4,19 +4,17 @@ :_mod-docs-content-type: PROCEDURE [id="network-observability-filtering-ebpf-rule_{context}"] -= Filtering eBPF flow data using a global rule -You can configure the `FlowCollector` to filter eBPF flows using a global rule to control the flow of packets cached in the eBPF flow table. += Filtering eBPF flow data +You can configure the `FlowCollector` to filter eBPF flows using multiple rules and features to control the flow of packets cached in the eBPF flow table. .Procedure . In the web console, navigate to *Operators* -> *Installed Operators*. . Under the *Provided APIs* heading for *Network Observability*, select *Flow Collector*. . Select *cluster*, then select the *YAML* tab. -. Configure the `FlowCollector` custom resource, similar to the following sample configurations: +. Configure the `FlowCollector` custom resource, similar to the following sample configuration: ++ +.Example `FlowCollector` YAML with multiple rules + - -[%collapsible] -.Filter Kubernetes service traffic to a specific Pod IP endpoint -==== [source, yaml] ---- apiVersion: flows.netobserv.io/v1beta2 @@ -29,46 +27,29 @@ spec: agent: type: eBPF ebpf: + privileged: true <1> + features: <2> + - PacketDrop + - FlowRTT flowFilter: - action: Accept <1> - cidr: 172.210.150.1/24 <2> - protocol: SCTP - direction: Ingress - destPortRange: 80-100 - peerIP: 10.10.10.10 - enable: true <3> + enable: true <3> + rules: + - action: Accept <4> + cidr: 172.210.150.1/24 <5> + protocol: SCTP + direction: Ingress + destPortRange: 80-100 + peerIP: 10.10.10.10 + - action: Accept + cidr: 172.30.0.0/16 + pktDrops: true <6> + - action: Reject + cidr: 0.0.0.0/0 ---- -<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. -<2> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6. -<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature. -==== + -[%collapsible] -.See flows to any addresses outside the cluster -==== -[source, yaml] ----- -apiVersion: flows.netobserv.io/v1beta2 -kind: FlowCollector -metadata: - name: cluster -spec: - namespace: netobserv - deploymentModel: Direct - agent: - type: eBPF - ebpf: - flowFilter: - action: Accept <1> - cidr: 0.0.0.0/0 <2> - protocol: TCP - direction: Egress - sourcePort: 100 - peerIP: 192.168.127.12 <3> - enable: true <4> ----- -<1> You can `Accept` flows based on the criteria in the `flowFilter` specification. -<2> The `cidr` value of `0.0.0.0/0` matches against any IP address. -<3> See flows after `peerIP` is configured with `192.168.127.12`. -<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature. -==== \ No newline at end of file +<1> The `spec.agent.ebpf.privileged` specification value must be true for packet drop tracking. +<2> List the parameters you want to track in the `spec.agent.ebpf.features` specification list. +<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature. +<4> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. +<5> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6. Duplicate CIDRs are not allowed in filter rules. +<6> The `PacketDrop` feature requires an `action` parameter. \ No newline at end of file diff --git a/modules/network-observability-flowcollector-api-specifications.adoc b/modules/network-observability-flowcollector-api-specifications.adoc index 5764bb9aa881..76fb3ea651d7 100644 --- a/modules/network-observability-flowcollector-api-specifications.adoc +++ b/modules/network-observability-flowcollector-api-specifications.adoc @@ -444,7 +444,6 @@ To filter two ports, use a "port1,port2" in string format. For example, `ports: | `rules` defines a list of filtering rules on the eBPF Agents. When filtering is enabled, by default, flows that don't match any rule are rejected. To change the default, you can define a rule that accepts everything: `{ action: "Accept", cidr: "0.0.0.0/0" }`, and then refine with rejecting rules. -Unsupported *. | `sampling` | `integer` @@ -470,7 +469,6 @@ Description:: `rules` defines a list of filtering rules on the eBPF Agents. When filtering is enabled, by default, flows that don't match any rule are rejected. To change the default, you can define a rule that accepts everything: `{ action: "Accept", cidr: "0.0.0.0/0" }`, and then refine with rejecting rules. -Unsupported *. -- Type:: @@ -1480,15 +1478,15 @@ Type:: | `input` | `string` -| +| | `multiplier` | `integer` -| +| | `output` | `string` -| +| |=== == .spec.exporters[].openTelemetry.logs From d450912b3dab1557f2f58eab463881700f0f9a4f Mon Sep 17 00:00:00 2001 From: Gwynne Monahan Date: Tue, 29 Apr 2025 12:03:58 -0500 Subject: [PATCH 2/3] Update sentence (Squash) --- modules/network-observability-ebpf-rule-flow-filter.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/network-observability-ebpf-rule-flow-filter.adoc b/modules/network-observability-ebpf-rule-flow-filter.adoc index 6f50528aecc3..45158759bf02 100644 --- a/modules/network-observability-ebpf-rule-flow-filter.adoc +++ b/modules/network-observability-ebpf-rule-flow-filter.adoc @@ -7,7 +7,7 @@ = eBPF flow rule filter You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. -You can apply multiple filter rules, and add a webhook check to prevent CIDR duplication. +You can apply multiple features, and multiple filter rules. [id="ingress-and-egress-traffic-filtering_{context}"] == Ingress and egress traffic filtering From fc92312d0eb89b1e58313a363c664acad97b0ea3 Mon Sep 17 00:00:00 2001 From: Gwynne Monahan Date: Tue, 29 Apr 2025 13:46:25 -0500 Subject: [PATCH 3/3] QE changes (Squash) --- ...ork-observability-filtering-ebpf-rule.adoc | 70 ++++++++++++++----- 1 file changed, 52 insertions(+), 18 deletions(-) diff --git a/modules/network-observability-filtering-ebpf-rule.adoc b/modules/network-observability-filtering-ebpf-rule.adoc index bad62b2cbf7f..e31613ef8a1e 100644 --- a/modules/network-observability-filtering-ebpf-rule.adoc +++ b/modules/network-observability-filtering-ebpf-rule.adoc @@ -4,17 +4,24 @@ :_mod-docs-content-type: PROCEDURE [id="network-observability-filtering-ebpf-rule_{context}"] -= Filtering eBPF flow data -You can configure the `FlowCollector` to filter eBPF flows using multiple rules and features to control the flow of packets cached in the eBPF flow table. += Filtering eBPF flow data using multiple rules +You can configure the `FlowCollector` to filter eBPF flows using multiple rules to control the flow of packets cached in the eBPF flow table. .Procedure . In the web console, navigate to *Operators* -> *Installed Operators*. . Under the *Provided APIs* heading for *Network Observability*, select *Flow Collector*. . Select *cluster*, then select the *YAML* tab. . Configure the `FlowCollector` custom resource, similar to the following sample configuration: + +[IMPORTANT] +==== +You cannot use duplicate CIDRs in filter rules +==== + -.Example `FlowCollector` YAML with multiple rules -+ + +[%collapsible] +.Filter Kubernetes service traffic to a specific Pod IP endpoint and service flows with Drops +==== [source, yaml] ---- apiVersion: flows.netobserv.io/v1beta2 @@ -28,28 +35,55 @@ spec: type: eBPF ebpf: privileged: true <1> - features: <2> + features: - PacketDrop - - FlowRTT flowFilter: - enable: true <3> + enable: true <2> rules: - - action: Accept <4> - cidr: 172.210.150.1/24 <5> + - action: Accept <3> + cidr: 172.210.150.1/24 <4> protocol: SCTP direction: Ingress destPortRange: 80-100 peerIP: 10.10.10.10 - action: Accept cidr: 172.30.0.0/16 - pktDrops: true <6> - - action: Reject - cidr: 0.0.0.0/0 + pktDrops: true <5> ---- -+ <1> The `spec.agent.ebpf.privileged` specification value must be true for packet drop tracking. -<2> List the parameters you want to track in the `spec.agent.ebpf.features` specification list. -<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature. -<4> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. -<5> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6. Duplicate CIDRs are not allowed in filter rules. -<6> The `PacketDrop` feature requires an `action` parameter. \ No newline at end of file +<2> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature. +<3> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`. +<4> The required `cidr` parameter provides the IP address and CIDR mask for the flow filter rule and supports IPv4 and IPv6 address formats. If you want to match against any IP address, you can use `0.0.0.0/0` for IPv4 or `::/0` for IPv6. +<5> By default, all other flows are rejected. +==== ++ +[%collapsible] +.See flows to any addresses outside the cluster +==== +[source, yaml] +---- +apiVersion: flows.netobserv.io/v1beta2 +kind: FlowCollector +metadata: + name: cluster +spec: + namespace: netobserv + deploymentModel: Direct + agent: + type: eBPF + ebpf: + flowFilter: + enable: true <1> + rules: + - action: Accept <2> + cidr: 0.0.0.0/0 <3> + protocol: TCP + direction: Egress + sourcePort: 100 + peerIP: 192.168.127.12 <4> +---- +<1> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature. +<2> You can `Accept` flows based on the criteria in the `flowFilter` specification. +<3> The `cidr` value of `0.0.0.0/0` matches against any IP address. +<4> See flows after `peerIP` is configured with `192.168.127.12`. +==== \ No newline at end of file