Skip to content

OSDOCS-14366 Additional context about the multi-flow filtering capability, updated yaml #92375

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: no-1.9
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions modules/network-observability-ebpf-rule-flow-filter.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
79 changes: 35 additions & 44 deletions modules/network-observability-filtering-ebpf-rule.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -11,12 +11,11 @@ You can configure the `FlowCollector` to filter eBPF flows using a global rule t
. 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:
+

[%collapsible]
.Filter Kubernetes service traffic to a specific Pod IP endpoint
====
.Example FlowCollector YAML with multiple rules
+
[source, yaml]
----
apiVersion: flows.netobserv.io/v1beta2
Expand All @@ -29,46 +28,38 @@ 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 <6>
destPortRange: 80-100
peerIP: 10.10.10.10
- action: Accept
cidr: 0.0.0.0/0
protocol: TCP
direction: Egress <7>
sourcePort: 100
peerIP: 192.168.127.12 <8>
- action: Accept
cidr: 172.30.0.0/16
pktDrops: true <9>
- 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.
====
<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.
<6> Filters Kubernetes service traffic to a specific Pod IP endpoint.
<7> See flows to any addresses outside the cluster.
<8> See flows after `peerIP` is configured with `192.168.127.12`.
<9> The `PacketDrop` feature requires an `action` parameter.
Original file line number Diff line number Diff line change
Expand Up @@ -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`
Expand All @@ -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::
Expand Down Expand Up @@ -1480,15 +1478,15 @@ Type::

| `input`
| `string`
|
|

| `multiplier`
| `integer`
|
|

| `output`
| `string`
|
|

|===
== .spec.exporters[].openTelemetry.logs
Expand Down