Merge pull request #112929 from gwynnemonahan/no-1-12-integration

[NETOBSERV] 1.12 release integration branch

Author: kalexand-rh

_topic_maps/_topic_map.yml

@@ -3331,6 +3331,8 @@ Topics:
     File: network-observability-overview
   - Name: Installing the Network Observability Operator
     File: installing-operators
+  - Name: Scaling network flow collection with Kafka
+    File: network-observability-kafka-operator-scaling-network-flow-collection
   - Name: Understanding Network Observability Operator
     File: understanding-network-observability-operator
   - Name: Configuring the Network Observability Operator
@@ -3345,6 +3347,8 @@ Topics:
     File: observing-network-traffic
   - Name: Network observability health rules
     File: network-observability-health-rules
+  - Name: Monitoring TLS traffic
+    File: network-observability-monitoring-tls-traffic
   - Name: Using metrics with dashboards and alerts
     File: metrics-alerts-dashboards
   - Name: Monitoring the Network Observability Operator

modules/network-observability-analyze-tls-traffic.adoc

@@ -0,0 +1,69 @@
+// Module included in the following assemblies:
+//
+// * observability/network_observability/network-observability-monitoring-tls-traffic.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="network-observability-analyze-tls-traffic_{context}"]
+= Analyze Transport Layer Security traffic data
+
+[role="_abstract"]
+View and filter Transport Layer Security (TLS) metadata to identify deprecated configurations and verify encryption compliance in the cluster.
+
+.Prerequisites
+
+* The Network Observability Operator is installed.
+* TLS tracking is enabled in the `FlowCollector` custom resource (CR).
+* Access to the {product-title} web console.
+
+.Procedure
+
+. Navigate to *Observe* -> *Network Traffic* in the {product-title} web console and click the *Traffic flows* tab.
++
+[NOTE]
+====
+The *TLS Version* column is enabled by default. If the default TLS version column is not visible after enabling TLS tracking, click *Restore default columns* in *Manage columns* to refresh the table.
+====
+
+. Add TLS-specific columns to the traffic table:
+.. Click *Manage columns*.
+.. Select the *TLS Cipher Suite*, *TLS Group*, and *TLS Types* checkboxes.
+.. Click *Save*.
+
+. Filter traffic by message type to view complete TLS metadata:
+.. In the filter bar, select *TLS Types* and choose *ServerHello* from the dropdown menu.
++
+`ServerHello` messages contain negotiated TLS metadata such as cipher suite and cryptographic group information.
+
+. Filter traffic by TLS version to identify deprecated configurations:
+.. In the filter bar, select *TLS Version*.
+.. Select the versions you want to review:
+* *1.0*: Deprecated
+* *1.1*: Deprecated
+* *1.2*: Legacy
+* *1.3*: Current standard
++
+To identify all deprecated connections, filter for TLS versions 1.0 and 1.1.
+
+. Analyze TLS metrics in the overview panel:
+.. Click the *Overview* tab.
+.. Review the default TLS panels, which include *TLS usage (network flows per second)* and *TLS per version (network flows per second)*.
+.. Optional: To view additional TLS metrics, click *Manage panels* to select and display additional panels, such as *TLS per group (network flows per second)* or *TLS per cipher suite (network flows per second)*.
+
+. Identify secure connections in the *Topology* view:
+.. Click the *Topology* tab.
++
+Connections secured with TLS are marked with a lock icon. The color of the lock icon indicates the security level:
++
+* *Red*: Deprecated TLS versions (1.0 or 1.1)
+* *Yellow*: Legacy configurations (TLS 1.2)
+* *Green*: Secure connections (TLS 1.3)
+* *Blue*: Post-Quantum Cryptography (PQC) compliant
++
+Select a connection node to view its specific TLS version and cipher suite details.
+
+. View TLS metrics in the Network Observability dashboard:
+.. Navigate to *Observe* -> *Dashboards*.
+.. Search for *NetObserv* and review the available metrics:
+* *TLS Traffic*: Displays overall TLS traffic metrics.
+* *Flows rate per TLS version*: Displays traffic trends by TLS version over time.
+* *Flows rate per TLS group*: Displays traffic by TLS group over time.

modules/network-observability-configuring-kafka-compression.adoc

@@ -0,0 +1,65 @@
+// Module included in the following assemblies:
+//
+// * observability/network_observability/network-observability-kafka-operator-scaling-network-flow-collection.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="network-observability-configuring-kafka-compression_{context}"]
+= Configure Kafka compression
+
+[role="_abstract"]
+Configure the compression algorithm for network flow records exported to Kafka to optimize bandwidth and storage. This helps manage the data footprint of high-volume network telemetry.
+
+.Prerequisites
+
+* The Network Observability Operator is installed.
+* The `FlowCollector` custom resource (CR) is configured to export data to a Kafka topic.
+* You have `cluster-admin` permissions to edit the `FlowCollector` CR.
+
+.Procedure
+
+. Open the `FlowCollector` custom resource for editing by running the following command:
++
+[source,terminal]
+----
+$ oc edit flowcollector cluster
+----
+
+. Navigate to the `spec.kafka` section and add the `compression` parameter:
++
+[source,yaml]
+----
+apiVersion: flows.netobserv.io/v1beta2
+kind: FlowCollector
+metadata:
+  name: cluster
+spec:
+  deploymentModel: Kafka
+  kafka:
+    address: "kafka-cluster-kafka-bootstrap.netobserv:9093"
+    topic: "network-flows"
+    compression: "lz4"
+----
++
+where:
++
+`spec.kafka.compression`:: Specifies the compression algorithm. Accepted values: `gzip`, `snappy`, `lz4`, `zstd`, `none`. Default is `none`.
+
+. Save and apply the changes.
+
+.Verification
+
+. Confirm that the eBPF agent pods are running in the cluster by running the following command:
++
+[source,terminal]
+----
+$ oc get pods -A -l app=netobserv-ebpf-agent
+----
+
+. Verify that Kafka compression is active by running the following command:
++
+[source,terminal]
+----
+$ oc logs -n <namespace> <pod_name> | grep "KafkaCompression"
+----
++
+The output shows the compression configuration attribute in the eBPF agent pod logs.

modules/network-observability-custom-health-rule-configuration.adoc

@@ -3,22 +3,27 @@
 // * network_observability/network-observability-alerts.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="network-observability-custom-health-rule-configuration_{context}"]
-= Custom health rule configuration
+[id="network-observability-configuring-custom-health-rules_{context}"]
+= Configuring custom health rules
 
 [role="_abstract"]
-Use the Prometheus Query Language (`PromQL`) to define a custom `AlertingRule` resource to trigger alerts based on specific network metrics (e.g., traffic surges).
+Create custom health rules by using Prometheus Query Language (PromQL) to define an `AlertingRule` resource. These rules trigger alerts based on specific network metrics, such as traffic surges.
 
 .Prerequisites
 
-* Familiarity with `PromQL`.
-* You have installed {product-title} 4.16 or later.
-* You have access to the cluster as a user with the `cluster-admin` role.
-* You have installed the Network Observability Operator.
+* Access to the cluster with `cluster-admin` privileges.
+* The Network Observability Operator is installed.
+* {product-title} 4.16 or later is installed.
+* Familiarity with PromQL.
+
+[IMPORTANT]
+====
+Custom `PrometheusRule` resources are not owned by the `FlowCollector` resource. Custom rules created in the `netobserv` namespace might be deleted if the Network Observability Operator is uninstalled. To prevent data loss, create custom rules in a different namespace, such as `openshift-monitoring`, and maintain a backup in version control.
+====
 
 .Procedure
 
-. Create a YAML file named `custom-alert.yaml` that contains your `AlertingRule` resource.
+. Define an `AlertingRule` resource in a YAML file, for example, `custom-alert.yaml`.
 . Apply the custom alert rule by running the following command:
 +
 [source,terminal]
@@ -28,13 +33,13 @@ $ oc apply -f custom-alert.yaml
 
 .Verification
 
-. Verify that the `PrometheusRule` resource was created in the `netobserv` namespace by running the following command:
+. Confirm the `PrometheusRule` resource was created in the target namespace by running the following command:
 +
 [source,terminal]
 ----
-$ oc get prometheusrules -n netobserv -oyaml
+$ oc get prometheusrules -n <namespace> -o yaml
 ----
-+
-The output should include the `netobserv-alerts` rule you just created, confirming that the resource was generated correctly.
 
-. Confirm the rule is active by checking the *Network Health* dashboard in the {product-title} web console → *Observe*.
+. Confirm the rule is active in the {product-title} web console:
+.. Navigate to *Observe* → *Alerting* to see the firing status.
+.. Navigate to *Observe* → *Network Health* to view the dashboard integration.

modules/network-observability-disable-predefined-rules.adoc

@@ -4,9 +4,11 @@
 
 :_mod-docs-content-type: REFERENCE
 [id="network-observability-disable-predefined-rules_{context}"]
-= Disable predefined rules
+= Disabling default rules
 
 [role="_abstract"]
 Rule templates can be disabled in the `spec.processor.metrics.disableAlerts` field of the `FlowCollector` custom resource (CR). This setting accepts a list of rule template names. For a list of alert template names, see "List of default rules".
 
-If a template is disabled and overridden in the `spec.processor.metrics.healthRules` field, the disable setting takes precedence and the alert rule is not created.
+If a rule template is included in the `disableAlerts` list, it is not created, even if a custom override exists in the `spec.processor.metrics.healthRules` field. The `disableAlerts` configuration takes precedence over all other health rule settings.
+
+For a list of alert template names, see "List of default rules".

modules/network-observability-enable-tls-tracking.adoc

@@ -0,0 +1,84 @@
+// Module included in the following assemblies:
+//
+// * observability/network_observability/network-observability-monitoring-tls-traffic.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="network-observability-enable-tls-tracking_{context}"]
+= Enable Transport Layer Security tracking
+
+[role="_abstract"]
+Enable Transport Layer Security (TLS) tracking to monitor encryption protocols and identify security risks in the cluster.
+
+[NOTE]
+====
+TLS fields only appear in flows for connections that perform a TLS handshake after the feature is enabled.
+====
+
+.Prerequisites
+
+* The Network Observability Operator is installed.
+* The `FlowCollector` custom resource (CR) is configured with `spec.agent.type: eBPF`.
+* Access to the cluster with `cluster-admin` privileges.
+
+.Procedure
+
+. Edit the `FlowCollector` CR by running the following command:
++
+[source,terminal]
+----
+$ oc edit flowcollector cluster
+----
+
+. Add `TLSTracking` to the `spec.agent.ebpf.features` list:
++
+[source,yaml]
+----
+apiVersion: flows.netobserv.io/v1beta2
+kind: FlowCollector
+metadata:
+  name: cluster
+spec:
+  agent:
+    type: eBPF
+    ebpf:
+      features:
+      - TLSTracking
+# ...
+----
++
+where:
++
+`spec.agent.ebpf.features`:: Specifies the list of eBPF agent features to enable. Add `TLSTracking` to this array to enable TLS metadata capture from handshake messages.
+
+. Save and exit your editor.
+
+.Verification
+
+. Confirm that the eBPF agent pods have restarted by running the following command:
++
+[source,terminal]
+----
+$ oc get pods -n netobserv-privileged
+----
++
+.Example output
+[source,terminal]
+----
+NAME                                    READY   STATUS    RESTARTS   AGE
+netobserv-ebpf-agent-abc12              1/1     Running   0          2m
+----
+
+. Verify the TLS tracking feature is active by running the following command:
++
+[source,terminal]
+----
+$ oc logs -n netobserv-privileged ds/netobserv-ebpf-agent | grep "EnableTLSTracking"
+----
++
+.Example output
+[source,terminal]
+----
+EnableTLSTracking:true
+----
++
+The output confirms that the TLS tracking feature has been initialized in the eBPF agent.