You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can create filters to reduce the number of generated network flows. Filtering network flows can reduce the resource usage of the Network Observability components.
10
+
11
+
You can configure two kinds of filters:
12
+
13
+
* eBPF agent filters
14
+
* Flowlogs-pipeline filters
15
+
16
+
[id="ebpf-agent-filters_{context}"]
17
+
== eBPF agent filters
18
+
19
+
eBPF agent filters maximize performance because they take effect at the earliest stage of the network flows collection process.
20
+
21
+
To configure eBPF agent filters with the Network Observability Operator, see "Filtering eBPF flow data using multiple rules".
22
+
23
+
[id="flowlogs-pipeline-filters_{context}"]
24
+
== Flowlogs-pipeline filters
25
+
26
+
Flowlogs-pipeline filters provide greater control over traffic selection because they take effect later in the network flows collection process. They are primarily used to improve data storage.
27
+
28
+
Flowlogs-pipeline filters use a simple query language to filter network flow, as shown in the following example:
29
+
30
+
[source,terminal]
31
+
----
32
+
(srcnamespace="netobserv" OR (srcnamespace="ingress" AND dstnamespace="netobserv")) AND srckind!="service"
33
+
----
34
+
35
+
The query language uses the following syntax:
36
+
37
+
.Query language syntax
38
+
[cols="1,3", options="header"]
39
+
|===
40
+
| Category
41
+
| Operators
42
+
43
+
| Logical boolean operators (not case-sensitive)
44
+
| `and`, `or`
45
+
46
+
| Comparison operators
47
+
| `=` (equals), +
48
+
`!=` (not equals), +
49
+
`=~` (matches regexp), +
50
+
`!~` (not matches regexp), +
51
+
`<` / `\<=` (less than or equal to), +
52
+
`>` / `>=` (greater than or equal to)
53
+
54
+
| Unary operations
55
+
| `with(field)` (field is present), +
56
+
`without(field)` (field is absent)
57
+
58
+
| Parenthesis-based priority
59
+
|===
60
+
61
+
You can configure flowlogs-pipeline filters in the `spec.processor.filters` section of the `FlowCollector` resource. For example:
62
+
63
+
.Example YAML Flowlogs-pipeline filter
64
+
[source,yaml]
65
+
----
66
+
apiVersion: flows.netobserv.io/v1beta2
67
+
kind: FlowCollector
68
+
metadata:
69
+
name: cluster
70
+
spec:
71
+
namespace: netobserv
72
+
agent:
73
+
processor:
74
+
filters:
75
+
- query: |
76
+
(SrcK8S_Namespace="netobserv" OR (SrcK8S_Namespace="openshift-ingress" AND DstK8S_Namespace="netobserv"))
77
+
outputTarget: Loki <1>
78
+
sampling: 10 <2>
79
+
----
80
+
<1> Sends matching flows to a specific output, such as Loki, Prometheus, or an external system. When omitted, sends to all configured outputs.
81
+
<2> Optional. Applies a sampling ratio to limit the number of matching flows to be stored or exported. For example, `sampling: 10` means 1/10 of the flows are kept.
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.
8
+
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 captured. Then only the packets that match the filter are captured and the rest are dropped.
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.
14
+
Classless Inter-Domain Routing (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.
13
15
14
-
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.
16
+
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.
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.
6
+
= Filtering eBPF flow data using multiple rules
7
+
You can configure the `FlowCollector` custom resource to filter eBPF flows using multiple rules to control the flow of packets cached in the eBPF flow table.
8
+
9
+
[IMPORTANT]
10
+
====
11
+
* You cannot use duplicate CIDRs in filter rules.
12
+
* When an IP address matches multiple filter rules, the rule with the most specific CIDR prefix (longest prefix) takes precedence.
13
+
====
9
14
10
15
.Procedure
11
16
. In the web console, navigate to *Operators*->*Installed Operators*.
12
17
. Under the *Provided APIs* heading for *Network Observability*, select *Flow Collector*.
13
18
. Select *cluster*, then select the *YAML* tab.
14
19
. Configure the `FlowCollector` custom resource, similar to the following sample configurations:
15
-
+
16
20
17
-
[%collapsible]
18
-
.Filter Kubernetes service traffic to a specific Pod IP endpoint
19
-
====
21
+
22
+
.Example YAML to sample all North-South traffic, and 1:50 East-West traffic
23
+
24
+
By default, all other flows are rejected.
25
+
20
26
[source, yaml]
21
27
----
22
28
apiVersion: flows.netobserv.io/v1beta2
@@ -30,22 +36,29 @@ spec:
30
36
type: eBPF
31
37
ebpf:
32
38
flowFilter:
33
-
action: Accept <1>
34
-
cidr: 172.210.150.1/24 <2>
35
-
protocol: SCTP
36
-
direction: Ingress
37
-
destPortRange: 80-100
38
-
peerIP: 10.10.10.10
39
-
enable: true <3>
39
+
enable: true <1>
40
+
rules:
41
+
- action: Accept <2>
42
+
cidr: 0.0.0.0/0 <3>
43
+
sampling: 1 <4>
44
+
- action: Accept
45
+
cidr: 10.128.0.0/14
46
+
peerCIDR: 10.128.0.0/14 <5>
47
+
- action: Accept
48
+
cidr: 172.30.0.0/16
49
+
peerCIDR: 10.128.0.0/14
50
+
sampling: 50
40
51
----
41
-
<1> The required `action` parameter describes the action that is taken for the flow filter rule. Possible values are `Accept` or `Reject`.
42
-
<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.
43
-
<3> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable this feature.
44
-
====
45
-
+
46
-
[%collapsible]
47
-
.See flows to any addresses outside the cluster
48
-
====
52
+
<1> To enable eBPF flow filtering, set `spec.agent.ebpf.flowFilter.enable` to `true`.
53
+
<2> To define the action for the flow filter rule, set the required `action` parameter. Valid values are `Accept` or `Reject`.
54
+
<3> To define the IP address and CIDR mask for the flow filter rule, set the required `cidr` parameter. This parameter supports both IPv4 and IPv6 address formats. To match any IP address, use `0.0.0.0/0` for IPv4 or ``::/0` for IPv6.
55
+
<4> To define the sampling rate for matched flows and override the global sampling setting `spec.agent.ebpf.sampling`, set the `sampling` parameter.
56
+
<5> To filter flows by Peer IP CIDR, set the `peerCIDR` parameter.
57
+
58
+
.Example YAML to filter flows with packet drops
59
+
60
+
By default, all other flows are rejected.
61
+
49
62
[source, yaml]
50
63
----
51
64
apiVersion: flows.netobserv.io/v1beta2
@@ -57,18 +70,19 @@ spec:
57
70
deploymentModel: Direct
58
71
agent:
59
72
type: eBPF
60
-
ebpf:
73
+
ebpf:
74
+
privileged: true <1>
75
+
features:
76
+
- PacketDrop <2>
61
77
flowFilter:
62
-
action: Accept <1>
63
-
cidr: 0.0.0.0/0 <2>
64
-
protocol: TCP
65
-
direction: Egress
66
-
sourcePort: 100
67
-
peerIP: 192.168.127.12 <3>
68
-
enable: true <4>
69
-
----
70
-
<1> You can `Accept` flows based on the criteria in the `flowFilter` specification.
71
-
<2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
72
-
<3> See flows after `peerIP` is configured with `192.168.127.12`.
73
-
<4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
74
-
====
78
+
enable: true <3>
79
+
rules:
80
+
- action: Accept <4>
81
+
cidr: 172.30.0.0/16
82
+
pktDrops: true <5>
83
+
----
84
+
<1> To enable packet drops, set `spec.agent.ebpf.privileged` to `true`.
85
+
<2> To report packet drops for each network flow, add the `PacketDrop` value to the `spec.agent.ebpf.features` list.
86
+
<3> To enable eBPF flow filtering, set `spec.agent.ebpf.flowFilter.enable` to `true`.
87
+
<4> To define the action for the flow filter rule, set the required `action` parameter. Valid values are `Accept` or `Reject`.
88
+
<5> To filter flows containing drops, set `pktDrops` to `true`.
Multi-tenancy in the Network Observability Operator allows and restricts individual user access, or group access, to the flows stored in Loki and or Prometheus. Access is enabled for project administrators. Project administrators who have limited access to some namespaces can access flows for only those namespaces.
8
+
Multi-tenancy in the Network Observability Operator allows and restricts individual user access, or group access, to the flows stored in Loki and or Prometheus. Access is enabled for project administrators. Project administrators who have limited access to some namespaces can access flows for only those namespaces.
9
9
10
10
For Developers, multi-tenancy is available for both Loki and Prometheus but requires different access rights.
11
11
@@ -15,23 +15,23 @@ For Developers, multi-tenancy is available for both Loki and Prometheus but requ
15
15
16
16
.Procedure
17
17
18
-
* For per-tenant access, you must have the `netobserv-reader` cluster role and the `netobserv-metrics-reader` namespace role to use the developer perspective. Run the following commands for this level of access:
18
+
* For per-tenant access, you must have the `netobserv-loki-reader` cluster role and the `netobserv-metrics-reader` namespace role to use the developer perspective. Run the following commands for this level of access:
* For cluster-wide access, non-cluster-administrators must have the `netobserv-reader`, `cluster-monitoring-view`, and `netobserv-metrics-reader` cluster roles. In this scenario, you can use either the admin perspective or the developer perspective. Run the following commands for this level of access:
30
+
* For cluster-wide access, non-cluster-administrators must have the `netobserv-loki-reader`, `cluster-monitoring-view`, and `netobserv-metrics-reader` cluster roles. In this scenario, you can use either the admin perspective or the developer perspective. Run the following commands for this level of access:
0 commit comments